Reg.ru: домены и хостинг
Крупнейший регистратор и хостинг-провайдер в России.
Более 2 миллионов доменных имен на обслуживании.
Продвижение, почта для домена, решения для бизнеса.
Более 700 тыс. клиентов по всему миру уже сделали свой выбор.
Бесплатный Курс "Практика HTML5 и CSS3"
Освойте бесплатно пошаговый видеокурс
по основам адаптивной верстки
на HTML5 и CSS3 с полного нуля.
Фреймворк Bootstrap: быстрая адаптивная вёрстка
Пошаговый видеокурс по основам адаптивной верстки в фреймворке Bootstrap.
Научитесь верстать просто, быстро и качественно, используя мощный и практичный инструмент.
Верстайте на заказ и получайте деньги.
Бесплатный курс "Сайт на WordPress"
Хотите освоить CMS WordPress?
Получите уроки по дизайну и верстке сайта на WordPress.
Научитесь работать с темами и нарезать макет.
Бесплатный видеокурс по рисованию дизайна сайта, его верстке и установке на CMS WordPress!
*Наведите курсор мыши для приостановки прокрутки.
Почему Вы плохой PHP-программист?
У всех нас есть плохие привычки. В этой статье мы пройдемся по плохим практикам, которые стоит рассмотреть, переосмыслить и исправить как можно скорее.
Кого, черт подери, ты из себя возомнил?
"Каждый раз, когда я открываю проект, созданный не мной, это сопровождается оттенком страха. Это словно зайти в Храм Судьбы, наполненный хитроумными ловушками, закрытыми дверями и секретными кодами, когда изменение одной строки кода неожиданно обрушивает все приложение (и, вероятно, посылает гигантский валун, мчащийся на меня по узкому коридору)."
Когда ты ошибаешься, и все выглядит хорошо за исключением некоторых мелочей (из серии "А я бы сделал вот так!"), то можно вздохнуть с облегчением и погрузиться в проект.
Но когда твои опасения оправдываются... Что ж, это совсем другая история.
Наша первая мысль при виде этого нечестивого беспорядка обычно бывает типа: "Кого, черт подери, ты из себя возомнил?" И это справедливо. Какой программист по своей воле будет создавать из проекта такой хаос?
Ответ может Вас удивить
"Ужасный код - это результат накопления многочисленных сокращений и уступок".
Ваше первое ощущение будет говорить Вам, что парень, создавший этот проект - новичок, а то и попросту идиот. Но это далеко не всегда так.
Я считаю, что плохой код - результат накопления многочисленных мелких сокращений и уступок - точно так же, как и результат неопытности или глупости.
Это делает Храм Судьбы приложения еще более пугающим, потому что тот, кто построил его, может быть столь же умен, сообразителен и начитан, как и Вы. Разве только этот кто-то был слишком ленив или строил все в спешке, в результате чего все эти невинные мелкие детали складываются в сущий кошмар, свалившийся на Вашу голову.
И что еще страшнее - кому-то может достаться Ваш проект, который доведет другого человека до нервного срыва.
Вы ведь можете лучше!
Никогда не поздно изучить свои текущие привычки и убедиться, что Ваши плохие практики не приводят к потере сна другими людьми.
Давайте потратим несколько минут и взглянем на некоторые распространенные сокращения, уступки и другие нехорошие практики, чтобы быть уверенными в том, что наши проекты не вселяют ужас в нежные сердца добропорядочных граждан.
У Вас нет плана перед началом кодинга
"Перед тем, как Вы напишете хотя бы одну строку кода, Вам нужно иметь четкий план всей атаки".
Это поможет Вам не сходить с верного пути и избежать блуждающего кода, который будет позже смущать даже Вас самих, не говоря уже о других бедных душах.
Один из подходов, который сохранил мне уйму времени - как в разработке, так и в комментировании - это написание плана в комментариях:
<?php
// Подключаем необходимую информацию
// Устанавливаем соединение с базой данных
// Подключаем разметку хэдера
// Определяем переменные страницы из массива POST
// Загружаем нужную информацию из базы, используя переменные страницы
// Проходим циклом по загруженным строкам
// Форматируем картинки для вывода
// Создаем ссылку
// Форматируем запись для вывода
// Добавляем отформатированную запись в массив записей
// Преобразуем массив с записями в готовую разметку для страницы
// Выводим записи
// Подключаем разметку футера
Как Вы видите, не написав еще и строки кода, я уже точно знаю, что будет написано в файле. Более того, Вы можете спланировать так все приложение, и если Вы дойдете до точки, где одна функция требует функциональной перестройки другой, все, что Вам нужно будет сделать - это изменить комментарий.
Да, это требует пересмотра вашего подхода к веб-разработке, но это выведет организацию Ваших проектов на принципиально новый уровень.
"Примечание: Некоторые из этих комментариев окажутся не нужны, другие нужно будет изменить, а еще какие-то - добавить. Это предсказуемо. Это как составление общего плана действий. Он нужен просто для того, чтобы Вы не отвлекались по сторонам и шли по верной дороге."
Вы ничего не комментируете
"Самая большая проблема с кодом - это плохое комментирование, либо полное его отсутствие".
Грустно, что нужно об этом писать. Учитывая простоту и очевидность такого действия, как комментирование, не должно быть так, чтобы мы напоминали об этом друг другу.
Это не только значительно увеличивает временные затраты при знакомстве с проектом, но и гарантирует то, что я буду ломать голову, столкнувшись с применением нетипичного приема для решения какой-либо задачи.
Затем, когда я закончу с рефакторингом, случайно выяснится, что я нарушил работу всего приложения, т.к. не учел где-то особенности работы некоего неочевидного приема.
И весь этот процесс может занять от безобидных 10 минут до ужасающих 6-7 часов времени (И Вы это уже сделали. Я знаю, где Вы живете. Я к Вам приду:).
Поэтому прямо сейчас скажите громко:
"Я, [Ваше имя], клянусь писать комментарии всякий раз, когда значение написанного мной кода не самоочевидно."
Критерий "самоочевидности" применяется, конечно, только к коду, который не является "говорящим" сам по себе (в этом случае писать комментарии было бы нелогично) и тому коду, который не является предельно простым. Думайте об этом в таком ключе: если Вам требуется больше нескольких секунд для того, чтобы понять, что Вы написали, то есть смысл добавить для этого кода комментарий.
Чтобы проиллюстрировать свою точку зрения, я покажу Вам такой пример:
$pieces = explode('.', $image_name);
$extension = array_pop($pieces);
Что здесь происходит? Вам понадобилось время, чтобы осознать это? Вам все еще не ясно, что хранится в переменной $extension?
Посмотрите на этот код снова, но с одной строкой комментария:
// Получение расширения из имени файла
$pieces = explode('.', $image_name);
$extension = array_pop($pieces);
Сейчас даже беглый взгляд на этот код не требует включениям мозговой активности: Вы видите комментарий, видите код, и у Вас не возникает вопросов относительно того, что здесь происходит. Это может сэкономить, скажем, 5 секунд времени, но если у Вас большое приложение, да и код посложнее, то это сэкономит вам уйму времени.
Поэтому хватит оправданий. Пишите чертовы комментарии.
Вы жертвуете ясностью ради краткости
Отличным примером жертвования понятностью кода в угоду его краткости является использование бессмысленных имен переменных и опускание фигурных скобок.
Похоже, это общая беда - вечное желание сделать что-то, написав как можно меньше символов, но это стремление сродни соблазну иметь один комплект нижнего белья на все случаи жизни. Конечно, Вы можете его быстро постирать, но будьте уверены, что такой подход принесет Вам больше неудобств, чем преимуществ.
Как я уже упомянул, краткость обычно достигается использованием коротких и непонятных имен переменных (к примеру, $a; и что же у нас хранит эта переменная $a?) и опускание фигурных скобок.
Пропуск фигурных скобок в управляющих конструкциях - это для меня большое место. Если Вам не нравятся фигурные скобки, то пишите на Python. В PHP же очень просто потерять смысл при их отсутствии.
К примеру, взгляните на эти вложенные конструкции if-else без фигурных скобок:
<?php
$foo = 8;
if( $foo<10 )
if( $foo>5 )
echo "Больше 5!";
else
echo "Меньше 5!";
else
echo "Больше или равно 10!";
echo "<br />Другая заметка.";
При беглом взгляде кажется, что последняя строка выполнится лишь в случае, если значение переменной $foo больше или равно 10.
Но что же произойдет на самом деле? Последняя строка выполнится в любом случае, вне зависимости от того, что находится в переменной $foo. Мы все равно получим вывод строки "Другая заметка".
Вы смогли бы это заметить, если бы посмотрели на код чуть дольше и внимательнее, зная, что условия if и else без фигурных скобок оказывают влияние лишь на строку, следующую непосредственно за ними? Безусловно.
Но неужели понимание этого стоит Вашего времени и энергии? Абсолютно нет.
Применение фигурных скобок добавляет всего несколько дополнительных строк, даже если Вы пишете каждую из них на новой строке, однако значительно повышает читабельность кода:
<?php
$foo = 8;
if( $foo<10 )
{
if( $foo>5 )
{
echo "Больше 5!";
}
else
{
echo "Меньше 5!";
}
}
else
{
echo "Больше или равно 10!";
}
echo "<br />Другая заметка.";
Да, Ваш код должен быть кратким, но не в ущерб его ясности. Лучше написать несколько дополнительных строк но быть уверенным, что ни Вам, ни кому-либо другому не придется потом биться головой о клавиатуру, пытаясь его понять.
Вы не следуете стандартам кодирования
"Выберите стандарт и придерживайтесь его"
Красивое форматирование может, конечно, удовлетворить Ваши художественные потребности, но по отношению к другим людям все не так однозначно. Выберите стандарт (я рекомендую стандарт PEAR) и придерживайтесь его. И все будут Вам благодарны (в итоге, включая Вас самих).
Поверьте мне. Я был таким парнем - я хотел иметь свой "фирменный почерк" и проводил часы, занимаясь переформатированием своего кода. Воистину, есть время для того, чтобы отличаться от других, и для того, чтобы быть как все.
Когда дело доходит до программирования, думайте о нем, как о языке, на котором Вы говорите. Грамматика и пунктуация существуют не просто так: они позволяют нам понимать друг друга без лишних вопросов.
Подумайте о стандартах в таком ключе: следование им показывает Ваше уважение к другим людям и желание, чтобы они смогли понять Ваш код, а не то, что Вы являетесь скучным снобом.
Вы дублируете код
Это неправильно.
Постарайтесь взглянуть на каждый кусочек Вашего приложения и представьте, что нужно что-то изменить. Придется ли Вам при этом производить изменения более чем в одном файле? Если это так, то Вам стоит пересмотреть свой подход к написанию кода.
Если у Вас есть код, который делает одно и то же, но расположен он в разных частях приложения, то Вы что-то делаете не так.
Вы не следуете паттерну разработки
"Когда Вы кодируете, у Вас всегда должна быть структура"
Я говорю здесь не о том, что нужно следовать паттерну MVC или еще чему-то в этом роде (хотя это тоже следует делать), а о том, что Вы должны знать, как классифицировать компоненты приложения, и где они должны находиться.
Следуя логическому паттерну разработки, многие решения становятся автоматическими и кто-то, кто будет работать с Вашим кодом, не будет ломать голову над тем, где же в Вашем коде "упрятан" некий функционал.
Это занимает немного времени, но это действительно сделает Ваши приложения намного понятнее.
Вы слишком умны для Вашего же блага
"Самое простое решение, как правило, является самым подходящим"
Всегда существует очень тонкая грань между изящным и чересчур запутанным решением.
Часто очень хочется попробовать в деле какой-то новый только что усвоенный "трюк", но нужно удержаться от соблазна использовать сложные решения там, где достаточно более простых.
На базовом уровне простое решение обычно является и наиболее эффективным. Вы можете, конечно, добираться из пункта A в пункт Б не по прямой, а в объезд, но это будет всего лишь интересно (забавно, поучительно, восхитительно - подставьте нужное слово), но не практично.
К тому же, Ваши супер-пупер элегантные решения могут создать настоящие проблемы для другого человека, который не видел подобных решений, и он просто запутается. И это произойдет не потому, что он не так умен и сообразителен, как Вы, а просто потому, что он не привык к такому подходу и не пытается использовать концепцию "квадрата" для решения "круглой" проблемы.
Не ограничивайте себя очень сильно, но избегайте усложнения ради усложнения.
Вы - "Эксперт"
"Не надо всеми силами стремиться сделать свой код непонятным для других"
Когда я только начинал в веб-разработке, я работал с одним парнем, который сам себя величал "Экспертом". Когда бы у меня ни возникал вопрос концептуального плана, я никогда не получал от него прямого ответа. Чтобы получить ответ, мне приходилось ответить на ряд предварительных вопросов, чтобы он мог убедиться, что я "действительно понимаю, о чем идет речь".
Этот парень был очень хорош в написании кода, который был больше похож на криптографическое послание и, в целом, только вводил всех в заблуждение.
Файлы, написанные им - это продукт такого типа программистов, которые убеждены, что код нужно сделать практически нечитаемым только для того, чтобы "отсеять идиотов".
Общий посыл, который скрывается за таким подходом, очень прост: "Если Вы не достаточно умны (сообразительны, догадливы и т.п.), чтобы понять этот код, то Вам не место в веб-программировании".
Это глубоко ошибочный и антисоциальный подход к программированию. Это очень элитарный способ смотреть на вещи, он показывает, что человек потерял связь со своими корнями и забыл период своего становления, когда он сам нуждался в помощи.
Поэтому всеми силами избегайте того, чтобы Ваш код был сложным для понимания. Это не сделает Вас "Крутым" или умным, равно как и не добавит уважения к Вам. Это сделает Вас тем самым "Экспертом".
Чувак, ты о чем?
Если Вы перестанете учиться, то проекты, над которыми Вы работаете, застрянут, когда бы Вы ни решили "заземлиться".
Технологии особо не меняются, т.к. люди устали, и нам проще делать "ремонт"; большинство новых технологий просто позволяют решать те же проблемы, что и раньше более эффективно и легко. Поэтому, если Вы будете игнорировать прогресс, это приведет к медленной маргинализации Вашего набора навыков.
Вот некоторые вещи, которые все мы можем прекратить делать для того, чтобы убедиться, что наши навыки актуальны.
Вы все пытаетесь делать сами
"Найдите несколько программистов с подходом, похожим на Ваш, и пусть они будут для Вас новостными ориентирами"
Вы не можете взаимодействовать со всем сообществом. Любой, кто пытался уследить за 200 подписками на технические блоги, скажет Вам, что это просто невозможно по объективным причинам.
К счастью, в сообществе всегда есть люди, которые мониторят движение технического прогресса и делятся с другими своими находками. Ваша задача - найти для себя именно таких людей.
Слежение за 2-5 такими людьми может быть гораздо эффективнее, чем подписка на каждый блог по разработке, который Вам попадется на просторах сети, по нескольким причинам:
- Если Вы доверяете их мнению, то они могут быть для Вас "открывателями" новых технологий;
- Если некая технология описывается сразу несколькими людьми, то это знак для Вас. Вероятно, она популярна, и следует к ней присмотреться.
- Часто на блогах таких людей Вы сможете найти короткие обзоры, позволяющие Вам не ломать голову и быстро освоить азы новой технологии.
Вы не за пределами своей Зоны Комфорта
"Я просто имею в виду, что Вы будете чувствовать себя более состоявшимся и наполненным как программист, будете видеть свой прогресс все больше, если всегда будете стремиться к более высокому уровню программирования".
Если Вы не беретесь за то, что бросает Вам вызов, то здесь что-то не то. Поиск новых вызовов при работе над проектами - вот что делает программирование приятным (или, по крайней мере, должно делать).
Попробуйте задавать себе такие вопросы перед началом нового проекта:
- Могу ли я применить здесь новую, интересную мне технологию?
- Научился ли я делать вещи лучше с тех пор, как я делал проект, подобный этому?
- Есть ли какая-то лучшая практика, которую мне следует применить при работе над этим проектом?
Помните: Я сейчас не говорю о том, что Вам нужно что-то усложнять. Это может быть что-то простое, вроде грамотного комментирования проекта, или сложное, вроде добавления совместимости с XMLRPC.
Просто старайтесь не "консервироваться" и не убеждайте себя в том, что Вы уже все знаете. Это приведет к тому, что Вы потеряете всякий интерес к делу.
Вы не делитесь
"Всегда обсуждайте Ваш код с единомышлениками"
Это лучший способ развития. Можно делать это разными способами. Если Вы чувствуете в себе силы, то можете написать свой учебник или руководство, создать проект с открытым исходным кодом.
Если это для Вас сложновато, то можете, к примеру, поместить объявления на тематических форумах о том, что Вы готовы помочь новичкам.
"Как помощь новичкам поспособствует моему развитию?" - спросите Вы. Обычно, когда Вы публикуете некое решение для новичков, то его можно еще оптимизировать, и другие более опытные программисты подключатся к вопросу и усовершенствуют код.
Таким образом, этот подход имеет два плюса: Вы не только помогаете освоиться новичкам, но и оттачиваете собственное мастерство, позволяя другим дорабатывать и улучшать Ваш код.
Вы не ведете никакие сторонние проекты
Если Вы хотите разобраться с чем-то достаточно сложным, что Вы пока не можете внедрить в разрабатываемый проект, то одно из лучших решений - создать сторонний проект, использующий неизвестную или сложную для Вас технологию.
Так Вы сможете развиваться в своем собственном темпе в свободное время и не рискуете опоздать со сдачей реального проекта или сделать его неправильно.
Мы все виновны
Если сейчас мы делаем что-то правильно, то нам стоит улучшаться и дальше. И логика говорит нам, что если мы лучше сейчас, то раньше мы были хуже. И если мы пойдем дальше по этой линии, то придем к моменту, когда мы были ужасны.
Я вижу это, когда смотрю назад, на код, написанный в прошлом, и прихожу в ужас.
Поэтому... хватит.
Мы никогда не будем идеальными. Но мы можем сделать все, чтобы всегда приближаться к этому.
Автор: Jason Lengstorf
Источник: net.tutsplus.com
P.S. Хотите двигаться дальше в освоении PHP? Обратите внимание на премиум-уроки по различным аспектам сайтостроения, включая программирование на PHP, а также на бесплатный курс по созданию своей CMS-системы на PHP с нуля. Все это поможет вам быстрее и проще освоить этот мощный язык веб-разработки:
Понравился материал и хотите отблагодарить?
Просто поделитесь с друзьями и коллегами!
Смотрите также:
