Головні характеристики якісного коду


Як часто ви поражаетесь, читаючи чужий код, і думаєте «господи, ну і каша...». Швидше за все, досить часто. І чи можете ви бути впевненим, що ніхто не думав також коли читав ваш код? Іншими словами, наскільки ви впевнені в чистоті свого коду? Можна бути впевненим тільки якщо повністю розумієш, що означає чистий код.
Складно дати точне визначення чистого коду, і, швидше за все, скільки програмістів — стільки визначень. Однак, деякі принципи достатньо універсальні. Я зібрав дев'ять найбільш релевантних і описав нижче.
1.Поганий код робить занадто багато, чистий код сфокусований
Кожен клас, метод і будь-яка інша субстанція повинна залишатися неспотвореної. Вона повинна слідувати принципом єдиною обов'язки. Коротко можна сказати так: якщо подумати про причини зміни класу, то можна придумати більше однієї гарної причини.
Але я б не обмежував визначення класами. У свій останній статті Ральф Вестфал (Ralf Westphal) представив більш широке визначення принципу єдиною обов'язки:
Функціональна одиниця на певному рівні абстракції повинна відповідати за один аспект вимог системи. Аспект вимог це ознака або властивість вимоги, яка може змінюватися незалежно від інших аспектів.


Якщо хочете дізнатися більше, то раджу прочитати його статтю.
2. Мова, на якому ви написали код повинен виглядати як ніби його створили для вирішення цієї проблеми.
мова робить програму простий, а програміст, який робить так, що мова виглядає просто.
(цитата Роберта C. Мартіна)
Це означає, що не потрібно використовувати хакі, з-за яких код і мова зазвичай виглядають незграбно. Якщо ви вважаєте, що щось можна зробити тільки хаком або латкою, то зазвичай це означає, що ви недостатньо часу провели в спробах знайти гарне, чисте рішення.
3. Не потрібно надмірності
Код повинен підкорятися правилу DRY (don't repeat yourself — не повторюйте). Якщо це так, то модифікація будь-якого елемента системи не вимагає зміни інших, логічно не пов'язаних елементів.
4. Читати ваш код повинно бути приємно
Коли читаєш ваш код, має бути відчуття, що читаєш «Гаррі Поттера» (так, знаю, я трохи переборщив). Має бути відчуття, що його написали, щоб будь-який розробник міг з легкістю прочитати, не проводячи години в спробах розібратися.
Для цього потрібно намагатися підкорятися принципам KISS (Keep It Simple, Stupid!) YAGNI (You ain't Gonna Need It — Вам це не знадобиться). Принцип KISS свідчить, що більшість систем працюють краще всього якщо зберігати їх простоту, а не розвивати складність.
тобто, простота повинна бути метою в дизайні, і потрібно уникати непотрібних ускладнень. YAGNI це практика, мотивуюча фокусуватися на найпростіших речах, які дозволяють вашому софту працювати.
5. Інший розробник може легко розширити ваш код
Ви не пишіть код для себе, або ще гірше — для компілятора. Ви пишіть код для інших розробників. Не будьте егоїстом — подумайте про людей. Не мучте інших розробників, видаючи погано підтримуваний і погано розширюваний код. До того ж, через кілька місяців цим іншим розробником можете опинитися ви самі.
6. Потрібно мінімізувати залежності
Чим більше залежностей, тим складніше підтримувати і змінювати код в майбутньому. Завжди (у випадку з .NET, — прим. пер.) можна допомогти собі мінімізувати залежності з NDEPEND, наприклад. Він перевіряє потенційні помилки в залежностях в коді.
7. Менше — краще
Код повинен бути мінімальним. Класи та модулі повинні бути короткими, в ідеалі — усього кілька рядків коду. Код повинен бути добре розділений (у тому числі всередині класу). Чим краще ви ділите код, тим легше його читати. Цей принцип добре впливає на пункт 4 — іншим програмістам буде простіше зрозуміти його.
8. Необхідні юніт — і приймальні тести
Як можна дізнатися, чи задовольняє наш код вимогам, якщо не писати тести? Як можна підтримувати і розширювати його, не боячись, що все зламається? Код без тестів — просто не чистий. Якщо хочете дізнатися більше про засади юніт-тестування, то раджу прочитати дуже гарну статтю Three Pillars of Unit Tests, написану одним з моїх колег.
9. Код повинен бути виразним
Виразність коду означає, що в ньому використовуються імена зі змістом. Ці імена повинні виражати намір. Вони не повинні заплутувати. Вони повинні бути помітними. Виразність документує код і робить окрему документацію менше необхідної. Якщо хочете дізнатися більше про тему самодокументированного коду, то раджу прочитати цю статтю.
Так що ж таке чистий код?
У цілому, одне останнє якості можна назвати підсумком усього вищесказаного:
Чистий код написаний тим, кому не начхати.
цитата Майкла Фетерса (Michael Feathers).
Він написаний тим, хто відноситься до коду як до мистецтва, і хто звертає увагу на всі деталі.
Тема чистого коду — дуже складна, і виходить за рамки описаної в цій статті. Так що, якщо ви вважаєте, що існують інші характеристики чистого коду, то, будь ласка, поділіться ними в коментарях.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.