У всех нас есть вредные привычки. В этой статье мы рассмотрим список плохих практик, которые стоит немедленно изучить, переоценить и исправить.
Каждые несколько недель мы пересматриваем некоторые из любимых постов нашего читателя на протяжении всей истории сайта. Этот учебник был впервые опубликован в феврале 2011 года.
Кто, черт возьми, ты думаешь, что ты?
Каждый раз, когда я открываю проект, который мне не принадлежит, он сопровождается легким страхом, что я вхожу в какой-то сценарий Храма Судьбы, наполненный ловушками, секретными кодами и той одной строкой кода, которая на изменение, сбивает все приложение (и, возможно, отправляет гигантский валун, несущийся ко мне по узкому коридору).
Когда мы ошибаемся, и все хорошо, за исключением незначительных различий в том, «как бы я это сделал», мы вздыхаем с облегчением, закатываем рукава и погружаемся в проект.
Но когда мы правы … Ну, это совсем другая история.
Наша первая мысль, увидев этот нечестивый беспорядок, обычно звучит так: «Кто, черт возьми, этот парень думает, что он такой?» И по праву так; какой программист охотно создал бы такой безобразный беспорядок в проекте?
Ответ может удивить вас
Ужасный код — это накопление нескольких маленьких ярлыков или уступок.
Ваш первый инстинкт может состоять в том, чтобы предположить, что парень, который создал проект, является новичком, или, возможно, он просто идиот. Но это не всегда так.
Моя теория заключается в том, что ужасный код — это накопление множества маленьких ярлыков или уступок — так же часто, как и результат неопытности или глупости. Это делает приложение Temple of Doom гораздо более пугающим, потому что тот, кто его создал, может быть таким же умным, опытным и начитанным, как и вы. Они просто ленились или собирали вещи в спешке, и каждый из этих маленьких ярлыков складывался в извилистый кошмар, который просто упал вам на колени.
Еще страшнее, это может означать, что в какой-то момент кто-то унаследовал ваш код и сразу заплакал.
Ты лучше, чем это, детка!
Это никогда не повредит пересмотреть ваши текущие практики и убедиться, что вы не используете ярлыки, которые могут способствовать потере сна другого человека.
Давайте потратим несколько минут и рассмотрим некоторые общие ярлыки, уступки и другие плохие методы, чтобы убедиться, что наши проекты не вселяют страх в сердца жителей деревни.
Вы не планируете, прежде чем начать кодирование
Прежде чем написать одну строку кода, у вас должен быть четкий план атаки.
Прежде чем написать одну строку кода, у вас должен быть четкий план атаки. Это помогает вам не сбиться с пути и избежать блуждания кода, который позже запутает вас, не говоря уже о какой-то другой бедной душе.
Один из подходов, который сэкономил мне время — как при разработке, так и при комментировании, — это сначала написать набросок в комментариях:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
<?php
// Include necessary data
// Initialize the database connection
// Include the common header markup
// Determine the page variables from the POST data
// Load the proper database info using the page vairiables
// Loop through the loaded rows
// Format the images for display
// Create a permalink
// Format the entry for display
// Add the formatted entry to the entry array
// Collapse the entry array into page-ready markup
// Output the entries
// Include the common footer markup
|
Как видите, не написав ни одной строки кода, я уже почти точно знаю, как будет выглядеть файл. Лучше всего, вы можете спланировать все приложение таким образом, и если вы дойдете до точки, где одна функция требует настройки функциональности другой, все, что вам нужно сделать, это изменить комментарий.
Это требует изменения в подходе к разработке, но это заставит ваши навыки организации проекта пройти крышу.
ПРИМЕЧАНИЕ: некоторые из этих комментариев не являются необходимыми; некоторые из них изменятся; другие должны быть добавлены — это ожидается. Это похоже на написание наброска для бумаги или написание списка покупок: он просто держит вас на правильном пути, когда вы идете, чтобы закончить работу.
Вы ничего не комментируете
И все же единственная наихудшая проблема с большинством кода, с которым я сталкиваюсь, заключается в том, что он плохо прокомментирован или вообще не прокомментирован.
Мне грустно, что я должен это записать. Когда что-то так просто, как комментировать, мы не должны напоминать друг другу о чем-то.
И все же единственная наихудшая проблема с большинством кода, с которым я сталкиваюсь, заключается в том, что он плохо прокомментирован или вообще не прокомментирован. Это не только добавляет хороший промежуток времени к моему первоначальному ознакомлению с проектом, но и в значительной степени гарантирует, что исправление, сделанное с использованием нетрадиционного метода по необходимости, приведет меня в замешательство. Затем, если я в конечном итоге сделаю какой-либо рефакторинг, я случайно сломаю приложение, потому что я не столкнулся с смягчающими обстоятельствами, которые требовали исправления.
Этот процесс может занять от 10 минут до 6 часов. (И ты сделал это со мной, я знаю, где ты живешь. Я иду за тобой.)
Так скажи это вслух:
Я, [укажите ваше имя] , настоящим клянусь комментировать в любой ситуации, когда цель написанного мной кода не сразу очевидна.
«Сразу видно» относится к коду, который не может быть самодокументируемым (потому что это было бы неразумно) и / или не выполняет непростую задачу. Подумайте об этом так: если вам пришлось остановиться и подумать о своем решении дольше нескольких секунд, оно, вероятно, заслуживает быстрого объяснения.
Чтобы проиллюстрировать свою точку зрения, я собираюсь использовать пример из статьи, которую я недавно написал для начинающих . Учтите следующее:
|
1
2
|
$pieces = explode(‘.’, $image_name);
$extension = array_pop($pieces);
|
Что это делает? Вы должны были остановиться и подумать об этом? Вы до сих пор не знаете наверняка, что хранится в $ extension ?
Посмотрите на этот фрагмент еще раз, но с одним быстрым комментарием:
|
1
2
3
|
// Get the extension off the image filename
$pieces = explode(‘.’, $image_name);
$extension = array_pop($pieces);
|
Пять секунд за один раз будут складываться с размахом.
Теперь, взглянув на этот код, не требуется никаких дополнительных умственных способностей: вы видите комментарий, видите код и никогда не должны подвергать сомнению его намерения.
Это может сэкономить вам только пять секунд созерцания, но если у вас есть сложное приложение, пять секунд за один раз будут складываться по-крупному.
Так что перестань оправдываться. Напишите проклятый комментарий.
Вы жертвуете ясностью ради краткости
Хорошие примеры жертвенности ясностью для краткости включают неясные имена переменных и удаление фигурных скобок.
Это универсальное искушение сделать что-то за минимально возможное количество символов, но это искушение похоже на искушение иметь только одну пару нижнего белья: конечно, стирка выполняется быстро, но проблемы, возникающие из-за вашего выбора, значительно перевешивают выгоды.
Хорошие примеры жертвенности ясностью для краткости включают короткие неясные имена переменных (например, $a — что такое $a store?) И удаление фигурных скобок.
Снятие фигурных скобок с контрольных структур — моя любимая мозоль. Если вам не нравятся фигурные скобки, переключитесь на Python . В PHP слишком легко потерять смысл без них.
Например, посмотрите на этот набор вложенных операторов if-else без фигурных скобок:
|
01
02
03
04
05
06
07
08
09
10
11
12
|
<?php
$foo = 8;
if( $foo<10 )
if( $foo>5 )
echo «Greater than 5!»;
else
echo «Less than 5!»;
else
echo «Greater than 10!»;
echo «<br />Another note.»;
|
На первый взгляд кажется, что последняя строка должна срабатывать только в том случае, если значение $foo больше 10. Но на самом деле происходит неправильный отступ; последнее эхо-заявление сработает независимо от того, что
$foo магазины.
Можете ли вы понять это, если вы посмотрите на нее несколько секунд и знаете, что операторы if-else без фигурных скобок влияют только на следующую строку? Конечно.
Стоит ли тратить энергию, чтобы понять это? Точно нет.
Добавление фигурных скобок добавляет несколько строк, но оно очень сильно разъясняет утверждение, даже с нечетным отступом:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
|
<?php
$foo = 8;
if( $foo<10 )
{
if( $foo>5 )
{
echo «Greater than 5!»;
}
else
{
echo «Less than 5!»;
}
}
else
{
echo «Greater than 10!»;
}
echo «<br />Another note.»;
|
Да, хорошо, чтобы ваш код был кратким, но не за счет ясности. Это стоит дополнительных строк, чтобы никто не ударился головой о клавиатуру, пытаясь просеять ваш код.
Вы не следуете стандарту кодирования
Выберите стандарт и придерживайтесь его.
Получение симпатичного с вашим форматированием могло бы удовлетворить ваши артистические убеждения, но это никому не приносит пользы. Выберите стандарт (я рекомендую стандарт кодирования PEAR ) и придерживайтесь его. Все будут вам благодарны. (Включая себя, когда-нибудь.)
Доверьтесь мне. Я был этим парнем однажды — я хотел иметь «фирменный стиль» — и я потратил впустую много часов, исправляя свое отвратительное форматирование позже. Есть время быть другим и время делать это, как все.
Когда дело доходит до программирования, думайте об этом как о разговорном языке. Грамматика и пунктуация существуют по определенной причине: поэтому мы можем четко понимать друг друга, когда записываем вещи. Подумайте о стандартах кодирования, как о вызывающей версии «Элементов стиля» Strunk & White — следование рекомендациям означает, что люди понимают, что вы пытаетесь сказать, а не то, что вы скучный человек.
Вы дублируете код
Ты делаешь это неправильно.
Старайтесь смотреть на каждую часть вашего приложения как на то, что нужно будет изменить в какой-то момент. Если это произойдет, придется ли вам обновлять более одного файла? Если вы ответили «да», пришло время пересмотреть то, как вы пишете код.
Если у вас есть код, делающий одну и ту же вещь в нескольких местах вашего приложения, вы делаете это неправильно.
Вы не следуете шаблону развития
У вас всегда должна быть структура при кодировании.
У вас всегда должна быть структура при кодировании. Я не имею в виду, что вы должны следовать шаблону MVC или чему-то столь же жесткому, но я имею в виду, что вы должны знать, как классифицировать компоненты и куда они должны идти.
Следуя логическому шаблону разработки, многие решения становятся автоматическими, и кто-то, входящий в ваш код, не должен много догадываться, когда ищет определенную функциональность в вашей кодовой базе.
Это не займет много времени, и это действительно прояснит ваши приложения.
Ты слишком умён для твоего же блага
Самое простое решение обычно является наиболее подходящим
Существует тонкая грань между хитрым решением и слишком сложным.
Всегда заманчиво попробовать какой-нибудь приятный новый трюк, который вы выучили, но мы должны сопротивляться желанию заставить сложное решение попасть в пространство, где достаточно простого.
На базовом уровне простейшее решение обычно является наиболее подходящим. Вы пытаетесь добраться из пункта А в пункт Б — проходить через точку Awesome — это весело, но на самом деле не приносит никаких преимуществ.
Однако ваше сверхсладкое решение создает проблему, в которой кто-то другой, возможно, не видел этого конкретного решения и просто потеряется. Это не потому, что они не такие умные, как вы; вероятно, потому что они не видели эту конкретную статью или не пытались навязать квадратную концепцию в круглую проблему.
Не падайте духом, но помните, чтобы не усложнять вещи «просто потому что».
Ты Ван
Избегайте активного усложнения понимания кода любой ценой.
Когда я только начинал заниматься разработкой, я работал с парнем, который был самопровозглашенным «опытным» программистом. Всякий раз, когда у меня возникал вопрос о концепции, он никогда не давал мне прямого ответа; чтобы получить ответ на мой первоначальный вопрос, мне пришлось ответить на пару предварительных вопросов, чтобы «доказать, что вы справитесь с ответом».
Этот парень был также действительно хорош в написании кода, который был загадочным, запутанным и просто сбивал с толку.
Такие файлы, как его, являются результатом работы программистов, которые думают, что им нужно усложнить чтение своего кода, чтобы «не пускать идиотов».
Общая философия, стоящая за этим, обычно звучит так: «Если вы недостаточно умны, чтобы понимать этот код, вы не должны быть в нем в первую очередь».
Это глубоко ошибочный и антисоциальный подход к программированию. Это очень элитарный взгляд на вещи, и он показывает, что программист потерял связь со своими корнями новичка, когда сам нуждался в помощи.
Избегайте активного усложнения понимания кода любой ценой. Это не делает вас круче или умнее, и это не способствует уважению. Это просто делает тебя ван.
Чувак, о чем ты говоришь?
Если вы перестанете учиться, то проекты, над которыми вы работаете, застрянут в любой период времени, который вы решили решить.
В дополнение к указанным выше ярлыкам и общей лени, еще одна вещь, которая может вас сдерживать, — это отсутствие постоянного обучения и продвижения вперед.
Технология не меняется, потому что сообществу в целом скучно, и мы решили сделать ремонт; большинство новых технологий появляются для более эффективного и простого решения существующих проблем. Выбор игнорировать прогресс — это выбор медленного процесса маргинализации вашего набора навыков.
Вот несколько вещей, которые мы все можем прекратить делать, чтобы быть уверенными в том, что наши навыки соответствуют современным требованиям, и все это без необходимости выходных.
Вы пытаетесь сделать все сами
Узнайте, кто из этих программистов имеет подобный подход, и пусть они сообщат вам о важных новостях.
Вы не можете идти в ногу со всем сообществом. Как скажет любой, кто когда-либо пытался не отставать от подписки на 200+ технических блогов, это просто невозможно сделать в разумные сроки.
К счастью, в сообществе есть люди, которые посвящают свое время наблюдению за развитием технологий и сообщают о своих выводах. Если вы потратите время, чтобы выяснить, кто из этих программистов имеет схожий подход и стиль, вы можете позволить им рассказать вам о важных новостях.
Наблюдение за 2-5 из этих блоггеров типа «раннего последователя» может быть более выгодным, чем подписка на каждый технический блог, с которым вы сталкиваетесь, по нескольким причинам:
- Если вы доверяете их мнению, они будут проверять технологии для вас.
- Если технология появляется в более чем одном из этих блогов, вы знаете, что вам нужно хотя бы несколько минут, чтобы узнать о ней больше, потому что она, очевидно, популярна.
- Зачастую в этих блогах содержится краткое вводное руководство, которое поможет вам избавиться от головной боли, начиная с нуля с новой технологией.
Среди блогеров PHP, которым я доверяю, — Дэвид Уолш и Крис Шифлетт .
Вы не вне своей зоны комфорта
Я просто хочу сказать, что вы, как программист, будете чувствовать себя более удовлетворенным и будете видеть, как ваши таланты развиваются все больше и больше, если вы решите всегда смотреть на следующий уровень программирования.
Если вы не делаете что-то, что бросает вам вызов, что-то не так. Поиск новых задач в проектах — это то, что делает программирование полезным (или, по крайней мере, так и должно быть).
Попробуйте задать себе следующие вопросы, когда начнете смотреть на новые проекты:
- Есть ли интересующая меня новая технология, которая применима здесь?
- Узнал ли я о лучшем способе сделать это с тех пор, как в последний раз принимался за такой проект?
- Есть ли передовой опыт, который мне нужен, чтобы обеспечить соблюдение этого проекта?
Имейте в виду: я не говорю о выполнении чего-то чрезвычайно сложного здесь.
Это может быть так же просто, как забыть добавить Docblocks к вашим объектам, или так же сложно, как сделать ваше приложение совместимым с XMLRPC, чтобы пользователям было легче публиковать обновления.
Просто постарайтесь не соглашаться и убедить себя, что вы узнали все, что вы собираетесь изучать. Вот тогда это станет уродливым для вас.
Вы не делитесь
Всегда обсуждайте свой код с другими программистами.
Лучший способ улучшить это — обсудить ваш код с другими программистами. Это можно сделать несколькими способами: если вы чувствуете себя особенно общительным, напишите учебник или выпустите проект с открытым исходным кодом; если вы не чувствуете что-то такого масштаба, возможно, вы могли бы потусоваться на форуме сообщества и предложить помощь новичкам.
«Как помощь нубам помогает мне прогрессировать?» ты спрашиваешь. Обычно, если вы публикуете решение, которое могло бы быть оптимизировано, другие опытные программисты присоединятся и предложат настройки. Таким образом, этот подход представляет собой нечто удивительное: вы не только помогаете прогрессировать сообществу, предлагая свои знания новичкам, но и оттачиваете свой собственный набор навыков, вывешивая свои навыки, чтобы все могли видеть и помогать вам развиваться.
У вас нет побочных проектов
Если вы хотите заняться чем-то новым и крутым, что слишком сложно для реального проекта, лучший способ научиться — начать сторонний проект, использующий эту технику.
Таким образом, вы можете прогрессировать в своем собственном темпе, в свободное время и никогда не рискуете пропустить крайний срок или «сделать это неправильно».
Мы все виноваты
Если мы делаем это правильно, мы всегда должны улучшаться. И логика говорит нам, что если мы сейчас лучше, то раньше мы были хуже. И если мы будем следовать этой линии рассуждений достаточно далеко, был момент, когда мы были ужасны.
Я знаю, что когда я оглядываюсь назад на часть кода, который я написал в прошлом, я в ужасе.
Так что … прекрати это.
Мы никогда не будем идеальными. Но мы можем сделать все от нас зависящее, чтобы убедиться, что мы приближаемся как можно ближе.
Каковы ваши любимые мозги при работе с кодом других разработчиков? Дай мне знать в комментариях!