Знижуйте невід’ємну складність, усувайте другорядну складність

Ніл Форд

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

З іншого боку, другорядна складність (accidental complexity) обумовлена ​​тими завданнями, які, як нам здається, необхідно вирішити для зниження невідємною складності Прикладом другорядної складності може служити застаріла система управління польотами, використовувана донині Система проектувалася для вирішення складної проблеми управління рухом тисяч літаків, але це рішення породжує свої власні проблеми Сучасні системи управління польотами настільки складні, що сама їх оновлення стає важким, якщо не неможливим справою Майже у всьому світі управління польотами здійснюється за технологіями більш ніж 30-річної давності

«Синдром другорядної складності» виявляється в багатьох інфраструктурах (framework) і фірмових «рішеннях» Інфраструктури для вирішення вузьких, конкретних завдань приносять реальну користь надмірно складні інфраструктури створюють більше труднощів, ніж усувають

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

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

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

Ніл Форд (Neal Ford) – архітектор програмного забезпечення і «мемовод»1 з ThoughtWorks, міжнародного консалтингового агентства, що спеціалізується на розробці та постачання комплексних рішень Він є творцем багатьох додатків, навчальних матеріалів, компютерних навчальних курсів, відео / DVD-презентацій, а також автором і / або редактором пяти книг і численних журнальних статей Часто виступає на конференціях Пекуче цікавість з приводу особи Нілу можна втамувати на сайті http://wwwnealfordcom

Термін «мемовод» (meme wrangler) придумав сам Ніл Форд Він вважає, що «.. це набагато краще знецінився терміну архітектор . Дуже шкода, що через відсутність галузевої системи сертифікації цю (номінально найвищу) посаду привласнюють собі люди, що повністю втратили звязок з реальністю » – Прямуючи перев

Джерело: Форд Н, Найгард М, де Ора Б, 97 етюдів для архітекторів програмних систем – Пер з англ – СПб: Сим-вол-Плюс, 2010 – 224 с, Мул

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*