Принципы Хорошего Программирования (Рейтинг: +39)

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

DRY - Don't repeat yourself (Не повторяйтесь) – Это, наверное, самый фундаментальный принцип в программировании, необходимо избегать повторений. Многие программные конструкции существуют исключительно для этих целей
(т.е. циклы, функции, классы и другое). Как только Вы начинаете повторяться (например, длинные выражения, ряд одинаковых условий, похожие сущности), создавайте новые абстракции
http://en.wikipedia.org/wiki/Don't_repeat_yourself

Abstraction Principle (Принцип абстракции) – Относится к DRY принцип абстракции: “Каждый значительный кусок функционала в программе должен быть реализован только в одном месте исходного кода”
http://en.wikipedia.org/wiki/Abstraction_principle_(programming)

KISS (Keep it simple, stupid!) (Не усложняй, тупица) – Простота (и избежание сложности) всегда должно быть ключевой целью. Простой код требует меньше времени чтобы его написать, имеет меньше ошибок, и его легче изменить.
http://en.wikipedia.org/wiki/KISS_principle

Avoid Creating a YAGNI (You aren't going to need it) (Вам это не пригодится) –
Не создавайте функционал в котором вы сейчас не нуждаетесь
http://en.wikipedia.org/wiki/YAGNI

Do the simplest thing that could possibly work (Ищите самое простое решение, которое может сработать) – Когда программируете, то сразу задайте задайте себе вопрос: "Какова самая простая вещь, которая могла бы сразу заработать?” Это помогает удерживать нас на пути к простоте разработки
http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html

Don’t make me think (Не заставляйте меня думать) – На самом деле это название книги Стива Круга о веб-юзабилити, которое имеет прямое отношение к программированию
Дело в том, что код должен легко читаться и восприниматься с минимумом усилий. Если код вызывает затруднения чтобы его понять, то вероятно его стоит упростить.
http://www.sensible.com/dmmt.html

Open/Closed Principle (Принцип Открытости/закрытости) – Программные сущности (классы, модули, функции) должны быть открыты для расширения, но закрыты для модификаций. Другими словами, не следует писать классы, которые люди будут изменять, создавайте классы, которые люди смогут расширять
http://en.wikipedia.org/wiki/Open_Closed_Principle

Write Code for the Maintainer (Пишите код для сопровождающего) –
Практически любой код, который вы пишете, предстоит поддерживать в будущем вам или кому-то другому. В будущем, когда вы вернётесь к коду, обнаружите, что большая его часть совершенно вам незнакома, так что старайтесь писать как будто для другого.
“Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.” (Стив Макконнелл «Совершенный код»)
http://c2.com/cgi/wiki?CodeForTheMaintainer

Principle of least astonishment (Принцип наименьшего удивления) – На принцип наименьшего удивления, как правило, ссылаются в отношении пользовательского интерфейса, но тот же принцип применим и к написанию кода. Код должен удивлять читателя как можно меньше. Это означает что необходимо придерживаться стандартным соглашениям форматирования кода, код должен делать то, что написано в названии и комментариях, а побочных эффектов необходимо избегать насколько это возможно.
http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Single Responsibility Principle (Принцип единственной ответственности) –
Компонент кода (т.е. класс или функция) должен выполнять единственную четко определённую задачу.
http://en.wikipedia.org/wiki/Single_responsibility_principle

Minimize Coupling (Минимизируйте связи) – Любая часть кода (код блока, функции, класса и т.д.) должна минимизировать зависимости от других частей кода. Это достигается за счет как можно меньшего использования общих переменных. “Слабая связанность часто является признаком хорошо структурированной компьютерной системы и хорошей архитектуры, а в сочетании с высокой сплоченностью достигаются главные цели - высокая читаемость и удобство сопровождения.”
http://en.wikipedia.org/wiki/Coupling_(computer_programming)

Maximize Cohesion (Максимальная сплоченность) – Код, который имеет аналогичную функциональность должен находится в том же компоненте.
http://en.wikipedia.org/wiki/Cohesion_(computer_science)

Hide Implementation Details (Скрытие деталей реализации) – Скрытие деталей реализации позволяет вносить изменения в код компонента с минимальными затрагиваением других модулей которые используют этот компонент.
http://en.wikipedia.org/wiki/Information_Hiding

Law of Demeter (Закон Деметры) – Компоненты кода должны взаимодействовать только с их непосредственными связями (например, классы от которых они унаследованы, объекты, которые они содержат, объекты, переданные с помощью аргументов и т.д.)
http://en.wikipedia.org/wiki/Law_of_Demeter

Avoid Premature Optimization (Избегайте преждевременной оптимизации) – Даже не думайте об оптимизации, если ваш код работает, но медленней, чем вы хотите. Только потом можно начать задумываться об оптимизации, и только основываясь на полученном опыте.
Мы должны забыть про небольшие улучшения эффективности, скажем, около 97% времени: преждевременная оптимизация — корень всех бед. © Дональд Кнут
http://en.wikipedia.org/wiki/Program_optimization

Code Reuse is Good (Повторное использование это хорошо) – Не очень содержательный, но тоже хороший принцип как и все другие. Повторное использование кода повышает надежность и уменьшает время разработки.
http://en.wikipedia.org/wiki/Code_reuse

Separation of Concerns (Разделение ответственности) – Различные области функциональности должны управляться различными и минимально перекрывающимися модулями кода.
http://en.wikipedia.org/wiki/Separation_of_concerns

Embrace Change (Обними изменения) – Это подзаголовок книги Кента Бека, в которой рассматривается принципы экстремального программирования и общие методики гибкой разработки. Многие другие принципы основаны на концепции, в которой вы должны ожидать и приветствовать изменения. На самом деле очень старые принципы разработки, вроде минимизации связей, непосредственно предназначаются для более лёгкого изменения кода. Даже если вы не приверженец экстремального программирования этот подход к написанию кода не теряет смысла.
http://www.amazon.com/gp/product/0321278658

Это мой перевод статьи Christopher Diggins
http://www.artima.com/weblogs/viewpost.jsp?thread=331531