Основи майстерності

Боріться зі складністю

Як відомо, мозок людини може одночасно розглядати 7 2 елемента. Тому дуже важливо прагнути до зниження складності ПЗ. Ось деякі конкретні рекомендації:

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

внутрішній пристрій класів.

• Підтримуйте абстракцію, що формується інтерфейсом класу, щоб не

запам'ятовувати непотрібних деталей.

• Уникайте глобальних даних, тому що їх використання значно збільшує відсоток коду, який потрібно утримувати в розумі в будь-який момент

часу.

• Уникайте глибоких ієрархій спадкування, бо вони пред "являють

високі вимоги до інтелекту.

• Уникайте глибокої вкладеності циклів і умовних операторів, оскільки

їх можна замінити на більш прості керуючі структури, що дозволяють

дбайливіше витрачати розумові ресурси.

• Уникайте операторів goto, так як вони вносять в програму нелінійність, за

якої більшості людей важко слідувати.

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

може стати нелінійною керуючою структурою, яку при недисциплінованому застосуванні зрозуміти майже так само важко, як і оператори goto.

• Не дозволяйте класам перетворюватися на монстрів, які досягають розміру цілих

програм.

• Підтримуйте методи короткими.
• Використовуйте ясні, очевидні імена змінних, щоб не згадувати деталі на кшталт «xx - це індекс рахунку, а yy - індекс клієнта чи навпаки?».
• Мінімізуйте кількість параметрів, що передаються в метод, або, що ще важливіше, передавайте лише ті параметри, які потрібні для підтримки абстракції, що формується інтерфейсом методу.
• Використовуйте угоди, щоб не запам'ятовувати довільні, несуттєві відмінності між різними фрагментами коду.

Аналізуйте процес розробки

У проектах, що реалізуються за участю більше одного програміста, більш важливу

роль відіграють організаційні характеристики, а не індивідуальні навички. Навіть

якщо у вас відмінна група, її колективна здатність не еквівалентна сумі

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

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

дефектні області програми - воно не зробить вашу програму зручнішою у використанні, більш швидкою, компактною, зручною або розширюваною.

Передчасна оптимізація - ще одна вилучена процесу розробки. Ефективний процес передбачає, що ви виконуєте грубу роботу на початку і тонку

в кінці. Якби ви були скульптором, ви надавали б композиції загальну форму

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

які полірувати не потрібно. Завжди питайте себе: "Чи роблю я це в правильному порядку? Що змінилося б при зміні порядку? ".

Пишіть програми в першу чергу для людей і лише в другу - для комп'ютерів

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

позитивно впливає на такі аспекти програми, як:

• зрозумілість;
• легкість виконання оглядів;
• рівень помилок;
• зручність налагодження;
• легкість зміни;
• час розробки - наслідок усього перерахованого вище;
• зовнішня якість - наслідок усього перерахованого вище.

Зручний код писати нітрохи не довше, ніж заплутаний - принаймні в далекій перспективі.

Програмуйте з використанням мови, а не мовою

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

Концентруйте увагу за допомогою угод

Загальні переваги угод:

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

Програмуйте в термінах проблемної області

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

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

i, j і k. Високорівневий код повинен описувати вирішену проблему. Він повинен

бути наповненими описовими іменами класів і викликами методів, що ясно характеризують виконувані дії, а не детальними відомостями про те, що файл

відкривається в режимі «тільки для читання». Високорівневий код не повинен бути

захаращений коментарями, що свідчать, що "тут змінна i представляє

індекс запису з файлу про співробітників, а трохи пізніше він використовується для індексації файлу рахунків клієнтів ".

Це незграбна методика програмування. На найвищому рівні програми

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

Розділення програми на рівні абстракції

Очевидно, що на деякому рівні треба працювати і в термінах реалізації, але

ви можете ізолювати ці частини програми від частин, розроблених у термінах проблемної області. Проектуючи програму, обміркуйте рівні абстракції:

• можливості операційної системи та машинні команди;
• структури та засоби мови програмування;
• низькорівневі структури реалізації;
• низькорівневі елементи проблемної області;
• високорівневі елементи проблемної області.

Побоюйтеся падаючих каменів

Чим би програмування не було - мистецтвом, ремеслом

або інженерною дисципліною, створення працюючої програми потребує неабиякої

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

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

Ітеруйте, ітеруйте та ітеруйте

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

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

Проектування ПО - процес евристичний і, як всі евристичні процеси, допускає ітеративні ревізії і поліпшення. Правильність ПЗ зазвичай перевіряється, а не доводиться, а значить, воно тестується і розробляється ітеративно,

поки на всі питання не будуть отримані правильні відповіді. І високорівневі, і

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

Неодноразове застосування різних підходів дозволяє дізнатися про проблему багато

такого, що вислизає при використанні єдиного підходу.

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

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

Кажуть, інженерна справа - це вміння зробити за 10 центів те, що будь-хто може зробити за долар. Ітерація на більш пізніх етапах - це трата двох доларів на те, що будь-хто може зробити за один. Фред Брукс радить «планувати викинути один варіант програми, тому що це доведеться зробити в будь-якому випадку». Хитрість розробки ПЗ в тому, щоб створювати викидаються частини якомога швидше і дешевше - це і є суть ітерації на ранніх етапах розробки.

Стів Макконнелл