1. DRY (Do not repeat yourself) Не робіть одну і ту ж роботу двічі
2. KISS (Keep it simple, stupid!) Не ускладнюй, тупиця
3. YAGNI (You are not going to need it) Вам це не знадобиться
4. Роби відразу найпростішу річ, яка швидше за все запрацює ( Do the simplest thing that could possibly work )
5. Пишіть код для супроводжуючого ( Write Code for the Maintainer )
6. Уникайте передчасної оптимізації (Avoid Premature Optimization)
7. Від перекладача:
8. Обійми зміни ( Embrace Change )
9. Від перекладача: і ще один дуже важливий принцип не згаданий автором

Через багато років я виявив що такі відносно небагато фундаментальні принципи допомогли мені стати більш ефективним програмістом.

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

DRY (Do not repeat yourself) Не робіть одну і ту ж роботу двічі

Напевно, самий фундаментальний принцип в програмуванні це уникати повторення. Багато програмні конструкції існують виключно для цієї мети (тобто цикли, функції, класи та інші). Як тільки ви почнете повторювати себе (наприклад, довге вираження, серія схожих виразів, схожі сутності) створюйте нові абстракції.

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

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

Спрощення (і уникнути складності) завжди має бути ключовою метою. Простий код займає менше часу щоб його написати, має менше помилок, і його легше змінити.

YAGNI (You are not going to need it) Вам це не знадобиться

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

Роби відразу найпростішу річ, яка швидше за все запрацює ( Do the simplest thing that could possibly work )

Коли програмуєте відразу задайте собі питання: «Що є найпростішою річчю, яка могла б ось відразу заробити?». Це допомагає утримувати нас на шляху до простоти дизайну.

Це насправді ця назва книги Стіва Круга про веб-юзабіліті і також має відношення до програмування. Справа в тому, що код повинен легко читатися і сприйматися з мінімумом зусиль. Якщо код викликає труднощі щоб його зрозуміти, то ймовірно його варто спростити.

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

Пишіть код для супроводжуючого ( Write Code for the Maintainer )

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

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

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

Компонент коду (тобто клас або функція) повинен виконувати єдину добре певне завдання.

Будь-яка частина коду (код блоку, функції, класу і т.д.) повинна мінімізувати залежності від інших частин коду. Це досягається за рахунок якомога меншого використання загальних змінних. Слабка зв'язаність часто є ознакою добре структурованої комп'ютерної системи і хорошою архітектури, а в поєднанні з високим зчепленням, підтримує головні цілі високою читання і зручності супроводу.

Код який має схожу функціональність повинен знаходиться в тому ж компоненті.

Приховування деталей реалізації дозволяє змінювати реалізацію код компонента з мінімальними затрагіваеніем будь-яких інших модулів які використовують цей компонент.

Компоненти коду повинні взаємодіяти тільки зі своїми безпосередніми відносинами (наприклад, класи від яких вони успадковані, об'єкти які вони містять, об'єкти передані за допомогою аргументів і т.д.)

Уникайте передчасної оптимізації (Avoid Premature Optimization)

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

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

Від перекладача:

Передчасна оптимізація гірше передчасної еякуляції. © namezys

Врахуйте, що часто оптимізацію погіршує зрозумілість системи. І перед оптимізацією я б настійно рекомендував виконати рефакторинг.

Оптимізуйте тільки ті частини системи, які дійсно потребують цього. Як правило це обробка великих масивів даних.

Визначайте такі фрагменти за допомогою профайлером - аналізаторів продуктивності. Оцінивши з їх допомогою швидкість роботи на реальних даних ви можете виявити що самі здавалося б важкі фрагменти системи можуть особливо не надати негативного впливу на продуктивність системи, оскільки вони виконуються пару раз за все за роботу. У той же час іноді несподівано прозорі фрагменти можуть виявитися самими загальмовує роботу.

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

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

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

Обійми зміни ( Embrace Change )

це заголовок книги Кента Бека , В якій розглядається принципи екстремального програмування (XP) і методології гнучкої розробки (Agile) в цілому. Багато інші принципи засновані на концепції, що ви повинні очікувати і вітати зміни. Насправді дуже старі принципи розробки, на зразок мінімізації пов'язаності, безпосередньо призначаються для легшого зміни коду. Навіть якщо ви не прихильник екстремального програмування цей підхід до написання коду не втрачає сенсу.

Від перекладача: і ще один дуже важливий принцип не згаданий автором

В об'єктно-орієнтованої дизайні обов'язковий SOLID : Абревіатура з перших букв назв прініципов, частина яких вже описана в цій статті:

© Christopher Diggins

UPD
Подивіться ще на відмінні мотиватори з цими приницпе для програмістів.