10 Советов для Лучшего Кодинга

1342298616_Web_Design

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

Хороший код является хорошо сопровождаемым, многократно используемым и тестируемым. Следующие шаги покажут вам и/или вашей команде разработчиков, как справиться с разными программными задачами и держать все в хорошем состоянии насколько возможно. Я ознакомлю вас с  “лучшими практиками”, которые помогут вам писать хороший код и помогут сделать вас и вашу команду счастливой и эффективной.

1. Используйте стандарты кодинга

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

Вы можете создать свои собственные стандарты оформления кода, но лучше использовать один широко-используемый. Используя Стандарт Кодинга Zend Framework , или PSR-1 Стиль Кодинга, остальным будет проще адаптироваться.

2. Используйте комментарии

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

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

3. Занимайтесь рефакторингом

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

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

Рефакторинг — больше искусство ежели наука, но существует несколько хороших правил которые могут пролить свет на это:

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

4. Избегайте глобального кода

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

В идеале, вам не стоит определять какие либо блоки глобально. Выражения switch, try-catch, foreach-циклы, while-циклы и тому подобное должны быть описаны внутри метода или функции. Методы  должны быть описаны внутри классов, а классы и функции внутри пространств имен.

5. Используйте имена со смыслом

Никогда не используйте имена подобные $k$m и $test для ваших переменных. Как можно прочесть такой код в будущем? В хорошем коде имена переменных, методов/функций, классов; должны нести смысловую нагрузку. Несколько хороших имен для переменных: $request$dbResult и $tempFile (Зависит от вашего стиля кодинга).

6. Используйте структуры со смыслом

Структуризация вашего приложения является важной; не используйте сложных структур, всегда придерживайтесь простоты. Когда даете имена директориям и фалам, используйте принцип именование о котором вы договорились с командой, или который отвечает стандартам кодинга. Всегда отделяйте четыре части PHP приложения друг от друга – CSS, HTML Шаблоны, JavaScript, PHP код – и для каждого попробуйте отделить библиотеки от бизнес-логики. Также хорошей идеей является сохранять сохранять иерархию директорий настолько малой насколько возможно, тогда вам будет легче искать части кода и ориентироваться в структуре.

7. Используйте системы контроля версий

Раньше, хорошие группы разработчиков доверяли CVS. Теперь, мы имеем вариацию доступных решений. Управление изменениями и ревизиями должны быть простыми но эффективными, так что выбирайте любую систему контроля версий, которая будет работать лучше всего с потоком вашей команды разработчиков. Я предпочитаю использовать распределённую систему контроля версиями, как Git, или Mercurial; оба бесплатные/с открытым исходным кодом и очень мощные. Если вы не знаете что такое система контроля версий, я рекомендую вам ознакомится с серией статей Шона Гадгстона Introduction to Git.

8. Используйте инструменты автоматического построения

Пробуйте использовать инструменты похожие на Ant, или Phing чтобы подготовить, сжать и задеплоить ваш исходный код. Построение вашего приложения при помощи простой команды — превосходный путь избежать ошибок и недосмотров, которые неизбежны при выполнении периодических задач и в основном рождаются при преждевременном тестировании. Я рекомендую вам использовать Phing, это хороший инструмент для построения PHP. Если вы незнакомы с ним, взгляните на статью Шаммера Using Phing, the PHP Build Tool и статья Вито Тардира Deploy and Release Your Application with Phing.

9. Используйте документаторы кода

Для больших приложений охватывающих несколько классов и пространств имен, вам стоит иметь автоматически сгенерированую API документацию. Это очень полезно и все в команде будут знать «что есть что». И если вы работаете над несколькими проектами одновременно, вы сочтете эту документацию благодатью, ведь вы наверняка забудете особенности структуры и прочие отличия между проектами. Один из таких документаторов который вы можете рассмотреть это DocBlox.

10. Используйте Тестирование

Существует множество инструментов, которые я очень ценю, но один, который я явно ценю — фреймворки которые помогают автоматизировать процесс тестирования. Тестирование (а именно систематичное тестирование) важно для каждой части вашего приложения на миллион долларов. Хорошие инструменты для тестирования — PHPUnit и SimpleTest для юнит тестирования ваших PHP Классов. Для тестирования GUI, я рекомендую SeleniumHQ tools.

Итог

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

Оригинал: Здесь.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>