Почему вы - неважный PHP программист?

У каждого из нас есть свои вредные привычки. В этом уроке, мы будем с ними бороться, а именно: рассматривать, оценивать и искоренять.

Да кто вы такой?

Каждый раз, когда я открываю проект, написанный другим человеком, мне становится не по себе, потому что я словно вхожу в какой-то тёмный храм со своими потайными ходами, тайными дверьми, секретным кодом и прочими вещами…(и возможно вскоре я попаду в капкан, которых напихано видимо невидимо).

Первое желание, которое как правило возникает – переписать проект под себя. Как правило так и происходит – мы вздыхаем, засучиваем рукава и начинаем кодить.

Когда мы начинаем распутывать чужой код, первое что приходит в голову, так это мысль, “Да что этот (дальше следует ненормативная лексика) о себе возомнил?” И это вполне нормально. Какой нормальный программист создаст такой хаос внутри проекта?

Ответ, возможно, вас удивит

Если начать мыслить здраво, то первый вывод к которому можно прийти, это то, что человек, которой писал этот код либо новичок, либо идиот. Но это не всегда так.

Моя теория заключается в том, что ужасный код это результат добавления его по мелким, непродуманным кусочкам — и чаще всего результат отсутствия навыков или опыта в программировании. На этих основах и строится всё приложение, понятное только одному автору. Часто ужасный код показывает степень лени автора.

Самое страшное заключается в том, что подобное можно увидеть сплошь и рядом. Многие люди думают что так и надо – и это настоящая трагедия.

Вы лучше, чем новичок!

Никогда не поздно пересмотреть некоторые свои техники, для того чтобы никогда не давать повод другим людям плеваться на ваше творение.

Теперь, я предлагаю вам уделить несколько минут техникам, которые мешают разработчикам стать профессионалами своего дела.

Вы не планируете приложение, перед тем как начать его делать

Перед тем как написать строку кода, у вас в голове должен быть сформирован план действий.

<?php
// Инклудим необходимые данные
// Инициализируем подключение к базе
// Подключаем шапку
// Получаем данные от POST
// Загружаем данные из БД
// Проходимся по результатам
// Готовим фотографии
// Создаём ссылки
// Выводим данные
// Подключаем футтер

Как вы видите без единой строчки кода, я точно знаю какие операции будут выполняться в этом файле – как он будет выглядеть. Таким образом вы можете распланировать всё ваше приложение, просто на просто, меняя комментарии.

Для того чтобы мочь планировать свой код, надо вырабатывать в себе новые навыки, которые несомненно пригодятся вам в менеджменте проекта.

Заметьте:Некоторые из этих комментариев не так уж необходимы. Другие будут меняться — это нормально. Всё это очень смахивает на написание содержания к вашей книге или списка покупок. Такая техника поможет вам быстро ориентироваться в вашем коде.

Вы ничего не комментируете

Одна и самых распространённых проблем это то, что ваш код не содержит описывающих его комментариев.

Мне бесконечно неудобно писать об этом. Многие разработчики не могут написать даже самое простое, что есть в любом языке программирования - комментарий.

Подавляющее количество кода, который я когда-либо видел, содержит незначительное количество комментариев. Для того чтобы написать хороший комментарий уходит достаточно времени, но оно окупается когда вам необходимо что-то изменить в функционале. Так же в случае рефакторинга, отсутствие описания кода может привести к его недееспособности.

Сам процесс комментирования может занять от 10 минут до 6 часов.

Скажите это во весь голос:

Я, [имя, фамилия], торжественно клянусь писать комментарии к своему коду в любой ситуации.

Специально для того, чтобы сэкономить время, умные люди придумали само документируемый код (очень распространённая вещь). Но в небольших приложениях, хватит и простых, небольших комментариев, которые разъяснят всю ситуацию.

Продемонстрирую идею на примере:

    $pieces = explode('.', $image_name);
    $extension = array_pop($pieces);

И что это такое? Остановитесь и подумайте? Что хранится в переменной $extension?

Взгляните на это кусок кода ещё раз, но только с комментарием:

    // Получаем расширение изображения
    $pieces = explode('.', $image_name);
    $extension = array_pop($pieces);

Теперь для того чтобы понять, что делает этот код с первого взгляда не надо сильно напрягать мозги: у вас перед глазами комментарий, код, и нет никаких вопросов.

В этом примере понимание пришло за несколько секунд, но в больших проектах комментарии значительно сэкономят вам время понимания кода.

Так что хватит оправдываться. Просто пишите комментарии.

Вы жертвуете читабельностью ради краткости

Хороший пример данной ошибки это ни о чём не говорящие имена переменных и отсутствие скобок.

О!! Это огромный соблазн – назвать переменную несколькими буквами. Точнее, это можно сказать вредная привычка больше 70% начинающих разработчиков. Вред такой техники придёт со временем и несомненно перевесит все выгоды.

Одни из самых распространённых примеров это сокращённые имена переменных (например, $a — что содержит переменная $a?) и отсутствие скобок.

Честно говоря я сам болел этими болезнями. Особенно пренебрегал скобками в простых условных выражениях. Если вам не нравятся эти скобки переходите на Python. В PHP это очень важный аспект, без которого очень легко потеряться в коде.

В качестве примера рассмотрим простое if-else выражение без скобок:

<?php
$foo = 8;
if( $foo<10 )
    if( $foo>5 )
        echo "Greater than 5!";
    else
        echo "Less than 5!";
else
    echo "Greater than 10!";
    echo "
Another note.";

Неопытный разработчик при первом взгляде на этот код скажет, что последняя строка выведется только тогда, когда $foo больше 10. Но на самом деле последняя строка выведется пользователю в любом случае, не зависимо от того, что содержится в переменной $foo.

Наверняка вы не будете оспаривать мысль о том, что отсутствие скобок усложняет понимание кода. С этим не поспоришь.

Нужно ли тратить усилия на понимание данного кода? Конечно же нет.

Ну и что? Появится парочка лишних строк в вашем коде… зато читабельность значительно увеличится:

<?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.";

Да, конечно же нужно стараться писать код как можно компактнее, однако это не должно влиять на читабельность. Никто не будет ругаться на лишние строки кода, предназначенные для скобок.

Вы не следуете стандартам написания кода

Выберите себе стандарт написания кода, которому будете следовать всегда.

Собственный стиль написания кода это конечно прекрасный повод показать свои умения и старания. Однако никому кроме вас это не будет полезно. Выберите стандарт (Я рекомендую стандарт кодирования Zend) и следуйте ему всё время. Все будут вам только благодарны. (Включая и вас самих)

Поверьте мне. Когда-то я бредил одной мыслью — Я хотел иметь “собственный стиль” — но в последствии, потратил очень много времени на форматирование кода. Есть моменты, где можно отличиться, но есть и те, где следует поступать как все.

Не даром языки программирования называются ЯЗЫКАМИ программирования. Грамматику и пунктуацию никто не отменял: так что, просто следуя правилам мы значительно упростим читабельность.

Вы дублируете код

Это неправильно.

Постарайтесь взглянуть на каждый сегмент кода как на то, что не является совершенным и нуждается в корректировке. Если это так, то чтобы исправить ситуацию вам необходимо переписать несколько файлов – это значит, что вам нужно пересмотреть ваш способ написания кода.

Если в вашем коде есть одинаковые фрагменты или фрагменты для одних и тех же целей, то вы действуете в неверном направлении.

Вы не придерживаетесь никакой модели

Когда вы пишите приложения, вы точно должны иметь представление о его структуре.

Вы всегда должны прекрасно понимать и придерживаться какой-то структуры. Сейчас я не имею в виду MVC или другие модели. Я говорю о том, что вы должны прекрасно понимать и уметь классифицировать все ваши компоненты, чтобы не допустить хаоса.

Если вы придерживаетесь какой-то структуре, многие решения, которые вам необходимо принять, не будут долго себя ждать. Если кто-то будет смотреть структуру вашего проекта, то он должен с лёгкостью понимать что и откуда берётся.

Это не займёт много времени, однако значительно увеличит ясность вашего приложения.

Вы слишком много умничаете

Самое лучшее решение – самое лёгкое решение

Есть огромная разница между профессиональными и сложными решениями проблем.

Всегда очень хочется чем-то выделиться, попробовать какие-то новые трюки, но мы не должны поддаваться этому желанию в тех случаях, где есть более искусное и простое решение задачи.

Самое простое решение это самое лучшее решение. Вам надо попасть из точки A в точку B — для этого не надо искать никакие обходные пути – нужно идти по прямой!

Если вы нашли чужое решение своей задачи, которое отличается простотой по сравнению с вашим, это не значит, что автор не такой умный как вы. Возможно он просто не видел смысла делать этот так, как сделали это вы. Возможно для кого-то это будет новость: не надо изобретать велосипед – он уже давно изобретён.

Однако вам не следует опускать руки – вы всё ещё можете отличиться. Вот только не следует усложнять вещи, которые можно легко реализовать.

Вы не правы

Любыми способами избегайте усложнения своего кода.

Когда я был ещё начинающим разработчиком, я работал с парнем, который считал себя супер экспертом в программировании. Когда я его спрашивал о принципе работы того или иного кода, он никогда не мог однозначно ответить; он часто уходил в какую-то другую степь, так что, для того, чтобы добиться ответа, мне приходилось задавать много дополнительных вопросов.

Этот парень был экспертом в написании кода, который мог запутать так, что мало не покажется.

Файлы, которые он писал это прекрасный пример того, что их автор придерживается мнения – «Чем труднее, тем лучше». Ну, для того, чтобы нюбы и не пытались что-то понять.

Есть очень распространённое мнение о том что, “Если ты не понимаешь, как работает этот код, то тебе стоит задуматься твоё ли это дело”.

Это мнение абсолютно не выдерживает никакой критики, когда речь идёт о командных проектах, да и не только. Люди, которые придерживаются такого же мнения, как и мой знакомый, забыли, что и они когда-то были новичками. Технологии развиваются, и им когда-то тоже потребуется помощь, чтобы в чём-то разобраться. Они не правы.

Старайтесь писать свой код понятным до безобразия – во всех смыслах. Трудный код не делает вас крутыми или более сообразительными. Вы в этом не правы.

Чувак, ты вообще о чём?

Если вы не продолжаете приобретать новые навыки, то ваши проекты не будут развиваться…

В добавок к лени и прочим левым качествам характера – многие разработчики перестают приобретать дополнительные навыки.

Технологии не меняются до того момента, пока не приходит время сделать «ремонт». Большинство новых технологий это не только свежие навыки, но и решение существующих проблем без особых умственных и временных затрат. Если разработчик перестаёт развиваться – это значит, что он начинает медленно деградировать.

Вот несколько вещей, которые нам необходимо прекратить делать, чтобы всегда быть в колее.

Вы стараетесь делать всё сами

Найдите людей, которые мыслят и пишут приложения точно так же как вы и учитесь…

Вы можете участвовать в развитиях целых сообществ. Кто-нибудь пробовал подписаться более, чем на 200 блогов по web-разработке? Те, кто это делал, скажут, что ничего кроме потери времени в этом нет.

Всё что вам нужно сделать, так это выбрать несколько источников, где вы всегда будете находить представление новых, продвинутых технологий, включая уроки статьи и прочие материалы.

Подписка на 2-5 источников, которые создают качественные материалы будет значительно эффективнее, чем подписка на всевозможные IT-блоги. Причин этому несколько:

• Если вы доверяете их мнению, то со временем вы будете больше понимать в вашей сфере деятельности.
• Если на одном из этих источников публикуется материал по новой супертехнологии, вы знаете, что, потратив не более часа, сможете быть в курсе последних тенденций. Всё потому что сайт, на который вы подписаны, популярен благодаря качеству своих материалов.
• Часто такой блог выпускает очень полезные мини-уроки, которые позволят вам достигнуть всех основ и не морочить себе голову, в поисках подобных материалов.

Вы не вылезаете из вашего панциря

Главная мысль в том, что вы будете чувствовать себя лучше как программист, если будете достигать всё новые и новые дерзкие, модные, амбициозные тенденции в сфере программирования.

Если вы не испытываете себя, то значит что-то с вами не так. Поиск решения новых задач это как раз то, что делает программиста искусным профессионалом (по крайней мере должно).

Старайтесь задать себе хотя бы один из следующих вопросов когда вы приступаете к работе над новым проектом:

• Есть ли какая-то новая технология, которую я бы мог применить в этом проекте?
• Есть ли у меня какие-то новые навыки, которые я приобрёл в своём прошлом проекте. Если да, то какие именно и как я смогу их применить в новом?
• Есть ли уже какие-то готовые решения для моих задач? Если да, то каковы они, какие у них плюсы и минусы?

Помните: Простота, простота и ещё раз простота. В этом нет ничего сложного.

Просто постарайтесь понять, что-то, что вы знаете – этого всегда будет недостаточно. Если вы это поняли, и будете следовать советам, изложенным в этой статье – вас ждёт блестящее будущее.

Вы - жадина

Всегда обсуждайте свой код с другими программистами.

Лучший способ приобретения новых навыков – это обсуждение вашего кода с другими программистами. Это можно сделать несколькими способами: написать своё учебное пособие или создать приложение с открытым исходным кодом. Если вы ещё не доросли до такого уровня, тогда наверняка вам следует открыть форум, где будете помогать новичкам приобретать новые навыки, а заодно развиваться сами.

Вы спросите, - “Как помощь другим может пойти мне на пользу?”. Обычно, если вы выкладываете решение задач, которое могут быть оптимизированы, опытные программисты включиться в игру и предложить несколько решений. Выгода уже должна быть вам понятна. Вы не только предлагаете новичкам ваши знания, вы так же точите свои собственные навыки, путём обсуждения вашего кода с опытными программистами. Такой подход поможет вам развиваться в нужном направлении.

У вас нет промежуточных проектов

Если вы хотите получить новые знания и навыки, то лучший способ, - это начать создавать какой-то проект, применяя то, что уже знаете + внедряя то, что вам предстоит узнать. Поверьте мне, лучшая теория - это практика, практика и ещё раз практика…

Таким образом вы можете прогрессировать, когда вам угодно – в любое свободное время, и никогда не нарушите сроки выполнения проекта. :)

Вы виновны

Если мы хотим всегда быть правы – то должны без остановки работать над собой. Если мы стали лучше, то это значит, что навыки были хуже. Это же логично! Если мы когда-либо остановимся, то грош нам цена. Такую уж мы выбрали профессию.

Это относится ко всем, и ко мне в том числе. Я с ужасом смотрю на код, который когда-то давно написал.

Так что… пора перезагрузиться

Нам никогда не достичь совершенства. Но мы всегда в силах сделать всё возможное, чтобы приблизиться к нему.

Что вы думаете по этому поводу? Какие грабли лежат у вас в огороде? Пишите! Ждём ваших комментариев!

• Комментарии