Написание кода иногда может быть самой сложной частью любого процесса разработки программного обеспечения. Если вы не организуете все с самого начала — особенно для больших проектов — процессы кодирования и управления кодом впоследствии могут оказаться не только трудоемкими, но и большой головной болью.
Хороший код является обслуживаемым, многоразовым и тестируемым. Следующие советы касаются того, как вы и / или ваша команда разработчиков можете решать различные задачи по написанию кода и как сохранить все как можно более аккуратным. Я познакомлю вас с некоторыми «лучшими практиками», которые помогут вам написать лучший код и сделают вас и вашу команду счастливыми и эффективными.
1. Используйте стандарт кодирования
Писать плохой неорганизованный код легко, но трудно поддерживать такой код. Хороший код обычно следует некоторому стандарту для соглашений об именах, форматировании и т. Д. Такие стандарты хороши тем, что они делают вещи детерминированными для тех, кто читает ваш код впоследствии, включая вас самих.
Вы можете создать свой собственный стандарт кодирования, но лучше придерживаться более широкого признания. Публично поддерживаемые стандарты, такие как Zend Framework Coding Standard или скоро станут PSR-1 Руководство по стилю кодирования, вместо этого другим будет легче адаптироваться.
2. Напишите полезные комментарии
Комментарии имеют решающее значение. Вы не оцените их, пока не оставите свой сценарий из тысячи строк на пару дней и вернетесь к нему, чтобы попытаться разобраться в нем. Полезные комментарии облегчают жизнь вам и тем, кто нуждается в поддержке вашего кода.
Напишите значимые однострочные комментарии для нечетких строк; написать полное описание параметров и функциональности для функций и методов; для сложных логических блоков опишите логику в словах перед ней, если это необходимо. И не забывайте, всегда обновляйте свои комментарии!
3. Рефакторинг
Рефакторинг кода — восьмая привычка высокоэффективных разработчиков. Хотите верьте, хотите нет, но вы должны ежедневно проводить рефакторинг своего кода, иначе ваш код не в порядке! Рефакторинг сохраняет ваш код здоровым, но что вы должны рефакторинг и как?
Вы должны рефакторинг всего, от вашей архитектуры до ваших методов и функций, имен переменных, количества аргументов, которые получает метод, и т. Д.
Как рефакторинг — это больше искусство, чем наука, но есть несколько практических правил, которые могут пролить свет на это:
- Если ваша функция или метод содержит более 20-25 строк, более вероятно, что вы включили в них слишком много логики, и вы, вероятно, можете разделить их на две или более меньшие функции / методы.
- Если имя вашего метода / функции превышает 20 символов, вам следует либо переосмыслить имя, либо переосмыслить всю функцию / метод, просмотрев первое правило.
- Если у вас много вложенных циклов, вы можете выполнять ресурсоемкую обработку, не осознавая этого. В общем, вам следует переосмыслить логику, если вы вкладываете более 2 циклов. Три вложенных цикла это просто ужасно!
- Подумайте, есть ли подходящие шаблоны проектирования, которым может следовать ваш код. Вы не должны использовать шаблоны только для использования шаблонов, но шаблоны предлагают проверенные и готовые решения, которые могут быть применимы.
4. Избегайте глобального кода
Глобальные переменные и циклы беспорядок и могут оказаться проблематичными, когда ваше приложение увеличивается до миллионов строк кода (что большинство делает!). Они могут повлиять на код в другом месте, которое трудно различить, или вызвать шумные конфликты имен. Подумайте дважды, прежде чем загрязнять глобальное пространство имен переменными, функциями, циклами и т. Д.
В идеальном случае у вас не должно быть блоков, определенных глобально. То есть. все операторы switch, try-catch, foreach, while-loop и т. д. должны быть записаны внутри метода или функции. Методы должны быть написаны внутри определений классов, а определения классов и функций должны находиться в пространствах имен.
5. Используйте значимые имена
Никогда не используйте имена, такие как $k , $m и $test для своих переменных. Как вы ожидаете прочитать такой код в будущем? Хороший код должен иметь смысл с точки зрения имен переменных, имен функций / методов и имен классов. Вот несколько хороших примеров значимых имен: $request , $dbResult и $tempFile (в зависимости от ваших рекомендаций по стилю кодирования в них могут использоваться подчеркивания, camelCase или PascalCase).
6. Используйте значимые структуры
Структурирование вашего приложения очень важно; не используйте сложные структуры, всегда придерживайтесь простоты. При именовании каталогов и файлов используйте соглашение об именах, которое вы согласовали со своей командой, или соглашение, связанное с вашим стандартом кодирования. Всегда разделяйте четыре части любого типичного приложения PHP отдельно друг от друга — CSS, HTML-шаблоны / макеты, JavaScript, PHP-код — и для каждой попытки отделите библиотеки от бизнес-логики. Это также хорошая идея, чтобы сохранить иерархию каталогов как можно более мелкой, чтобы было легче ориентироваться и находить код, который вы ищете.
7. Используйте ПО для контроля версий
В старые времена хорошие команды разработчиков полагались на CVS и патчи diff для контроля версий. Однако в настоящее время у нас есть множество доступных решений. Управление изменениями и ревизиями должно быть простым, но эффективным, поэтому выбирайте любое программное обеспечение для контроля версий, которое будет наилучшим образом работать с рабочим процессом вашей команды разработчиков. Я предпочитаю использовать распределенный инструмент контроля версий, такой как Git или Mercurial; оба являются свободными программами / с открытым исходным кодом и очень мощными.
Если вы не знаете, что такое программное обеспечение для контроля версий, я бы порекомендовал прочесть сериал Шона Хадгстона « Введение в Git» .
8. Используйте инструменты автоматической сборки
Попробуйте использовать такие инструменты, как Ant или Phing, чтобы подготовить, сжать и развернуть исходный код. Сборка всего приложения с помощью одной команды — это прекрасный способ предотвратить ошибки и упущения, которые присущи при выполнении повторяющихся задач, и, как правило, является основным предварительным условием для стратегий автоматического тестирования. Я рекомендую использовать Phing, это хорошо поддерживаемый инструмент для сборки PHP, написанный для имитации Ant; если вы не знакомы с ним, ознакомьтесь со статьей Shammer C Using Phing , PHP Build Tool и статьей Vito Tardia « Развертывание и выпуск приложения с Phing» .
9. Используйте Code Documenters
Для больших приложений, охватывающих несколько классов и пространств имен, вы должны автоматически создать документацию по API. Это очень полезно и позволяет команде разработчиков знать «что к чему». И если вы работаете над несколькими проектами одновременно, вы найдете такую документацию благословением, поскольку вы можете забыть о структурах, переключающихся между проектами. Одним из таких документов, который вы могли бы рассмотреть, является DocBlox .
10. Используйте Тестирование
Я действительно ценю множество инструментов, но, безусловно, больше всего ценю те, которые помогают автоматизировать процесс тестирования. Тестирование (особенно систематическое тестирование) имеет решающее значение для каждой части вашего приложения на миллион долларов. Хорошими инструментами тестирования являются PHPUnit и SimpleTest для модульного тестирования ваших классов PHP. Для тестирования GUI я рекомендую инструменты SeleniumHQ .
Резюме
В этой статье вы увидели обзор некоторых из лучших практик написания лучшего кода, в том числе использование стандарта кодирования для унификации форматирования кода для всей команды, важность рефакторинга и способы его использования, а также использование профессиональных инструментов, таких как среды тестирования, документирование кода и контроль версий для управления базой кода. Если вы еще не следуете этим советам, стоит принять их и привести свою команду в нужное русло.
Изображение через DJTaylor / Shutterstock