Що таке якісний дизайн. Відкрітість , адітівність , відстежуваність

[Переклад на російську мову - наприкінці матеріалу.]

Проектування програмних систем досі залішається Ближче до кустарного ремесла або мистецтва, чем до науки, того, звичайний, вивести формулу якісного дизайну Неможливо. Альо можна віділіті характерні Ознака (своєрідні чек-листи), что окреслюють межу между добрим и поганим. І ЯКЩО у процесі розробки намагатіся прінаймні НЕ делать Нічого поганого, вірогідність отріматі позитивний результат підвіщіться.

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

Відкрітість

У математічній логіці існує таке Поняття як «Відкритий світ ». Це такий світ, де відомі факти заздалегідь НЕ могут поясніті ВСІ Можливі стани и в подалі могут з'явитися Нові факти, Які Неможливо вивести Із існуючіх. Протілежене Поняття - «закритий світ», де ВСІ Властивості, Які Неможливо вивести з Нашої МОДЕЛІ, вважаються Хибне.

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

Відкрітість компоненти візначається кількістю обмежень ее Використання у рамках Вибраного стеку технологий. Очевидно, что Повністю обійтіся без обмежень Неможливо: це свого роду плата за функціональність. Як приклад, у фронт-Енді з одного боку находится JQuery, что практично НЕ накладає обмежень на Використання, з Іншого - ExtJS, розрахована на роботу у конкретному віді Додатків.

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

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

До того ж, користуватись такою бібліотекою у прикладній Програмі буде складніше, чем тім пробачимо варіантом, что БУВ спочатку, Аджея перед використаних ее нужно будет спеціально конфігуруваті. Такоже у нас вінікне свой DLL hell - конфлікті между перелогових різніх компонент.

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

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

У комп'ютерних науках найбільш очевидних способ Вирішення проблеми часто несе в Собі РИЗИКИ набагато більші, чем сама проблема. І ЯКЩО у первом прікладі годину вітрачається на Вирішення існуючіх проблем, то, проектуючі окремий абстрактний фреймворк, мі різікуємо втрачають Левову частко годині на Вирішення проблем неіснуючіх. Тому слід пам'ятати, что передчасно Абстракція, як правило, некоректно и заважає враховуваті Важливі деталі.

Если мова розробки дозволяє рефакторінг, то свідома дублікація кодом з подалі его СКОРОЧЕННЯ спріяє побудові ємної та якісної МОДЕЛІ. Правильність підходом мені здається Наступний: Якщо Вже нам потрібен фреймворк, то давайте вірощуваті его паралельно з основною програмою.

до речі, більшість Розповсюдження стеків розробки Вже повінні мати більш-Менш узагальнені системи Керування конфігурацією та конвенції за замовчуванням. Так ми! Зміни до Наступний пункту:

Адітівність

Підтримка та рефакторінг после розробки НЕ повінні дорого коштуваті. У добрі спроектованій Системі, змінюючі Сістемні компоненти, можна не перепісуваті реалізовану функціональність Повністю, а «плавно перенести» ее на новий фундамент. Саме адітівність дозволяє створюваті Великі Програмні комплекси та формуваті зручні інтерфейси відкритих бібліотек, Які існують десятіріччямі.

Засоби Досягнення адітівності - відсутність Переліку зв'язків между компонентами різніх підсістем та Слабко зв'язність. Нагадаємо: компоненти А і В назіваються Слабко пов'язаними, ЯКЩО для взаємодії їм НЕ нужно знаті деталі реалізації Одне одного. Існують Дві основні техніки Досягнення слабкої зв'язності. Перша - це Взаємодія через загальний інтерфейс, друга - Використання проксі об'єктів представніків (тоб з боці А є один об'єкт, что інкапсулює взаємодію з В, аналогічно з боці У є представник А). Тоді для того, шоб Изменить компоненту, й достатньо переписати позбав проксі представніків, залішаючі всі Інше незміннім.

Чі є техніки розробки, что спріяють адітівності? Так. Перш за все, це розробка невелика кроками. Тоб, ЯКЩО нам нужно в одній зміні віконаті задачі X, Y та Z, то давайте зробимо це послідовно (можливо, даже Розбите їх на дрібніші частина) и для шкірного випадка налаштуємо тести и окремий комміт. Дві Маленькі проблеми вірішіті простіше, чем одну велику, до того ж, часта робота з кодом «шліфує» его, Робить якіснішім Із шкірно Перегляд. Тому мене Дещо дівує бажання колег писати «ідеальний код»: краще прагнуті писати код, Який легко можна зрозуміті и модіфікуваті - тоді у нього матиме шанси за Якийсь годину дива ідеальнім.

Відстежуваність (traceability)

Ця властівість Полягає у легкості розуміння поведінкі програми. Если розглядаті ее Дії як певне Перетворення вхідніх сігналів у вихідні, то відстежуваність показує, наскількі точно Ми можемо відслідкуваті цею процес.

Існують Дві основні стратегії налагодження. Перша - це хаотично генерування та перевірка конкретних гіпотез, друга (правильна) - процес локалізації, что має гарантовано зійтіся, схожий на поиск на лева у пустелі за помощью ділення навпіл. Відстежуваність створюється Шляхом сістематічної ПІДТРИМКИ іншого способу.

Засоби досягення Дуже Прості. Один Із них - захисне програмування , альо такоже корисностей при розробці програми тримати в Голові НЕ Тільки шлях основного Виконання , а и его Зміни после Виникнення помилок. Уявіть Собі того, хто шукає помилки, як одного Із ваших кінцевіх Користувачів. Чого делать ні в якому разі неможна - так це губить інформацію та «маскуваті» помилки без визначення їхніх причин.

Если API бібліотеки можна представіті як корістувацькій інтерфейс програміста, то відстежуваність візначає «БЕЗПЕКА» цього інтерфейсу: после натіскання кнопки Нічого НЕ вібухне, а ЯКЩО цією кнопкою користуватись Наразі НЕ можна, то отриманий ПОВІДОМЛЕННЯ про помилки пояснити, чому Саме.

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

Переклад на російську мову

Що таке хороший дизайн. Відкритість, адитивність, трасуванню

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

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

Відкритість

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

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

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

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

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

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

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

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

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

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

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

Аддитивність

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

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

Чи техніки, підвищують аддитивность? Так. Це, перш за все, розробка невеликими кроками. Тобто, якщо нам потрібно в одному зміні виконати завдання X, Y і Z, давайте зробимо це послідовно (може, навіть розбивши їх на більш дрібні частини) і для кожного випадку відлагодити тести і окремий Ком. Дві маленькі проблеми вирішити простіше, ніж одну велику, до того ж, часта робота з кодом робить його кращим з кожним переглядом. Тому мене злегка насторожує прагнення колег «писати ідеальний код». Замість цього краще прагнути писати код, який легко розуміти і модифікувати - тоді у нього будуть шанси через якийсь час стати ідеальним.

трассируемого (або отслеживаемость)

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

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

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

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

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

Опубліковано: 23/04/13 @ 07:04
Розділ web дизайн

SEO Блог