[Перевод] Принципы хорошего программирования


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

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

DRY (Don’t repeat yourself) Не делайте одну и ту же работу дважды

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

Принцип абстракции (Abstraction Principle)

Относящийся к DRY принцип абстракции: «Каждый значительный кусок функциональности в программе должны быть реализован в одном месте исходного кода».

KISS (Keep it simple, stupid!) Не усложняй, тупица


Упрощение (и избежание сложности) всегда должно быть ключевой целью. Простой код занимает меньше времени чтобы его написать, имеет меньше ошибок, и его легче изменить.

YAGNI (You aren’t going to need it) Вам это не понадобится

Вам стоит пытаться не добавлять функциональности пока она вам не нужна. Только потратите время на разработку, отладку, поддержку и будет постоянно мешаться.

Делай сразу простейшую вещь, которая скорее всего заработает (Do the simplest thing that could possibly work)

Когда программируете сразу задайте себе вопрос: «Что является простейшей вещью, которая могла бы вот сразу заработать?». Это помогает удерживать нас на пути к простоте дизайна.

Не заставляйте меня напрягаться и думать (Don’t make me think)


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

Принцип Открытости/закрытости (Open/Closed Principle)

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

Пишите код для сопровождающего (Write Code for the Maintainer)


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

Программируй так, как если бы человек, который будет поддерживать твой код, будет брутальным психопатом и будет знать, где ты живёшь. © Martin Golding

Принцип наименьшего удивления (Principle of least astonishment) POLA


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

Принцип единственной ответственности (Single Responsibility Principle)

Компонент кода (т.е. класс или функция) должен выполнять единственную хорошо определённую задачу.

Слабая связанность (Minimize Coupling)

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

Максимальное сцепление (Maximize Cohesion)

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

Скрытие деталей реализации (Hide Implementation Details)

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

Закон Деметры (Law of Demeter)

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

Избегайте преждевременной оптимизации (Avoid Premature Optimization)

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

Мы должны забыть про небольшие улучшения эффективности, скажем на протяжении 97% времени: преждевременная оптимизация — это корень всех бед. © Дональд Кнут

От переводчика:

Преждевременная оптимизация хуже преждевременной эякуляции. © namezys

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

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

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

Также профайлеры позволяют выполнить анализ покрытия кода (Code Coverage) — процесс выявления неиспользуемых участков кода при помощи, например, многократного запуска программы.

Повторное использование это хорошо (Code Reuse is Good)

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

Разделение ответственности (Separation of Concerns, SoC)

Различные области функциональности должны управляться различными и минимально перекрывающимися модулями кода.

Обними изменения (Embrace Change)


Это заголовок книги Кента Бека, в которой рассматривается принципы экстремального программирования (XP) и методологии гибкой разработки (Agile) в целом. Многие другие принципы основаны на концепции, что вы должны ожидать и приветствовать изменения. На самом деле очень старые принципы разработки, вроде минимизации связанности, непосредственно предназначаются для более лёгкого изменения кода. Даже если вы не приверженец экстремального программирования этот подход к написанию кода не теряет смысла.

От переводчика: и ещё один очень важный принцип не упомянутый автором

В объектно-ориентированом дизайне обязателен SOLID: аббревиатура из первых букв названий приниципов, часть которых уже описана в этой статье:

Single responsibility principle Принцип единой разделения ответственности
Open/closed principle Принцип открытости/закрытости
Liskov Substitution Principle Принцип подстановки Лисков
Interface segregation principle Принцип изоляции интерфейса
Dependency Inversion Principle Принцип инверсии зависимостей

© Christopher Diggins

UPD
Посмотрите ещё на отличные мотиваторы с этими приницпами для программистов.

Реклама

One comment

  1. Уведомление: Отчёт о тренинге по TDD в Java | #kranonit Клуб анонимных айтишников в Кривом Роге

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s