JavaRush/Java блог/Random UA/Роберт Мартін, "Чистий Код". Огляд книги по «кунг-фу коду...
Artem Murk
35 рівень

Роберт Мартін, "Чистий Код". Огляд книги по «кунг-фу коду» для розробника

Стаття з групи Random UA
учасників
Привіт Джаварашівці! Ця стаття присвячена огляду книги «Чистий код» Роберта Мартіна. Ми разом розглянемо методи поліпшення та оптимізації вашого коду, а також наприкінці вас чекає маленьке, але цікаве завдання.
"Чистий Код", Роберт Мартін.  Огляд книги по «кунг-фу коду» для розробника.
Щодня відкриваючи редактор вашого коду, ми стикаємося з безліччю класів, функцій та змінних. Найкращий варіант, якщо це ваш код написаний з нуля, написаний один раз, у ньому трохи рядків, ви над ним працює одні, немає правок та подальшого супроводу з боку замовника. АЛЕ! Як показує практика, та я думаю ви й самі розумієте, що такого не буває. В основному нам доведеться якось взаємодіяти з членами своєї команди, супроводжувати «індуський» код, і розбирати продукти в мільйони рядків. Я часто чув від колег з навчання відповіді такого плану «Цей код написаний мною, і я його не збираюся нікому показувати», але коли я бачу прохання на Хелпі про допомогу з таким кодом, то доводиться дуже довго (іноді дійсно доооолго) вникати і розуміти чого людина хотіла мені сказати, навіть хочеться сказати «зітри і перепиши заново»! Цінуйте час, і сабо людей, які хочуть вам допомогти, пишіть правильно, а якщо не вмієте, то навчиться ніколи не пізно. Книга Роберта Мартіна серед книг такого формату вигідно відрізняється тим, що в ній є безліч прикладів Java. Може трохи фанатичний вислів з моєї сторони, але вона написана в стилі ООП, а саме в написанні частин і розділів. Проста для розуміння та читання книга легко читається у дорозі або ввечері перед сном. "Чистий код" розділений на 3 частини. У першій частині нам пропонують пройтися по теорії книги, дізнатися про патерни проектування та правила хорошого тону. Друга частина нам пропонує попрактикуватися в рефакторинг і написання, ну а третина є фінальним вичавлюванням «запахів» коду в прикладах. Що ж автор торкнувся безліч тем для знання яких вам в основному знадобиться знання Java Core, але є і розділи присвячені Модульним тестам JUnit, Логування log4j, знання найпростіших патернів у проектуванні (але як я сказав вище їх небагато, і все незрозуміле успішно гуглиться, та й розбираючи на курсі JavaRush). Всі розділи книги не пов'язані один з одним, ви успішно можете почати читати з того розділу, який вам до душі. Коротка вичавка основних ідей, які я підкреслив з книги. Буду вдячний за коментарі до них, де ви зможете поділитися власним баченням цих висловлювань. Коротка вичавка основних ідей, які я підкреслив з книги. Буду вдячний за коментарі до них, де ви зможете поділитися власним баченням цих висловлювань. Коротка вичавка основних ідей, які я підкреслив з книги. Буду вдячний за коментарі до них, де ви зможете поділитися власним баченням цих висловлювань.

1. Коментарі == зло.

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

2. Закоментований код, мертвий код.

Залишати дані шматки коду у вашому додатку — рівнозначно сміттю. Код, що не використовується, з часом накопичується і заважає чистоті вашого додатка, час від часу перевіряйте код на такі ось модулі.

3. Заголовки методів, класів та змінних.

Коштує окремих статей для розгляду цієї теми. Не полінуйтеся і пишіть імена, які можуть розповісти про своє призначення. Вивчіть деякі стандарти у написанні назв. Ця тема «Мастхев» для детального вивчення.

4. Кожному методу та змінній своє місце в ієрархії класу.

Зазвичай у класі можуть бути змінні та методи (статичні та не статичні), конструтор, вкладені та внутрішні класи, енуми. Одним словом інформації багато, і необхідно визначити кожному своє місце у класі. Якщо ви заглянете в java core класи, то побачите, що структура чітко структурована, ми можемо побачити кожну частину на своєму місці, звичайно, у ваших проектах вона може змінюватися в рамках проекту, але не в кожному класі. Для себе я визначив таку структуру побудови: На початку класу у мене статик змінні, потім змінні об'єкта + Енуми якщо вони є. Після змінних я визначаю констуктори класу. Потім пишу методи роботи із класом. Після методів я пишу гетери та сетери. І в самому кінці в мене є внутрішні класи. Можете скористатися моєю структурою або написати в коментарях свою.

5. Рівень абстракції методів.

Для мене це було відкриттям №1. Кожен метод містить оператори лише одного рівня абстракції. Не варто заважати у купі різнорівневі операції.

6. Обробка помилок.

Checked або Uncheked Exceptions, що краще краще використовувати в проекті (а ви як думаєте?, пишіть коментарі)? Я прихильник checked, але книга допомагає подивитися з боку та на Неперевірені винятки. Дійсно unchecked Exception не спотворює сигнатуру методу, особливо якщо враховувати, що виключення «пробивають» відразу кілька шарів. Незручність у дрібній зміні призводить до перевизначення всього ланцюжка методів до її відлову, що вкрай незручно для розробки у багатьох випадках.

7. Форматування коду.

Правильно відформатований код є не тільки красивим, але й добре читаним. Відразу складається уявлення про дужки і дії всередині. На прикладі умов у конструкціях if, else – не варто писати все в один рядок, краще перенесіть довгі ланцюжки.

8. Заперечення за умови.

Намагайтеся уникати заперечення в умовах, це більше психологічний фактор, наш мозок погано сприймає заперечення та й ! перед виразом можна й не помітити. Наприклад, заперечення if (!condition.isTrue) краще переписати метод, це істотно полегшить ось так(condition.isFalse)

9. Функції мають виконувати одну операцію.

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

10. Не повторюйтесь.

Не повторюйте код DRY (Don`t repeat yourself). Це одне з основних правил, яке скоротить у рази ваш код, постійно пам'ятайте. Намагайтеся всі ваші шматки коду, що повторюються, винести в окрему функцію. Звичайно можна ще багато говорити про DRY, KISS (Keep it simple Stupid), SOLID , YAGNI. Дані терміни необхідні розуміння і проектування. Вони стоять окремої статті, можливо я ще напишу про них, тому що ця стаття присвячена огляду книги «Чистий код».
"Чистий Код", Роберт Мартін.  Огляд книги по «кунг-фу коду» для розробника - 2
Як і обіцяв, невелике і легке завдання для вас. Програма повинна обчислювати Індекс Ожиріння за даними. Пишіть у коментарях кількість помилок та виправлень у коді. П.С. код робочий і виконує свою функцію, якщо його правильно використовувати.
//Weight in kg.
//Height in metres.
public class sample {
    public static void main (String[] args) {
        humanIMB humanIMB = new humanIMB(80,1.52);
        System.out.println(humanIMB.Result());
    }
}
class humanIMB {
    public double W; //Weight Human
    public double H; // Height Human
    private static double imb;
    public humanIMB(double w, double h) {
        W = w;
        H = h;
        imb = W / (H * H);
    }
    public double takeW() {
        return W;
    }
    public void putW(double w) {
        W = w;
        imb = W / (H * H);
    }
    public double takeH() {
        return H;
    }
    public void putH(double h) {
        H = h;
        imb = W / (H * H);
    }
    public static double takeImt() {
        return imb;
    }
    public static String Result() {
        String  string = null;
        if (imb >=18.5 & imb <25) {
            string ="Норма, ты в форме!";
        }
        if (imb >=25 & imb <30) {
            string ="Предожирение. Эй, поосторожнее с пирожными ";
        }
        if (imb >=30) {
            string ="Ожирение. SCHWEINE! Хватит жрать, иди на треню!";
        }
        if (imb <18.5) {
            string ="Дефицит массы тела. В модели решил переквалифицироваться?";
        }
        return string;
    }
}
Коментарі
  • популярні
  • нові
  • старі
Щоб залишити коментар, потрібно ввійти в систему
Для цієї сторінки немає коментарів.