Архітектура ПЗ

Остерігайтеся «хороших ідей»

Грег Найберг Хороші ідеї вбивають проекти Іноді смерть настає швидко, але частіше це повільне, болісне вмирання, причиною якого служать зірвані терміни і лавини програмних помилок Ви знаєте, про які хороших ідеях я кажу: спокусливі, очевидні, абсолютно нешкідливі на перший погляд – «нічого-страшного-ні-буде-якщо-ми-спробуємо» Зазвичай вони приходять в голову будь-кому в команді десь в середині життєвого циклу […]

Відповідальна керівництво важливіше зовнішнього враження

Баррі Хокінс Коли архітектор приступає до проекту, у нього зявляється зрозуміле бажання «показати себе» Призначення на посаду архітектора програмного забезпечення зазвичай свідчить про довіру до технічної компетентності фахівця з боку компанії природно, архітектор бажає якомога швидше показати, що він заслуговує цієї довіри На жаль, деякі з нас помилково вважають, що для цього слід «представити себе […]

Перевіряйте рішення на міцність за ключовими характеристиками

Стівен Джонс Спочатку архітектура додатку Формується на підставі заданих бізнес-вимог, обраних або вже застосовуваних технологій, діапазону продуктивності, очікуваних обсягів даних і фінансових ресурсів, виділених для побудови, розгортання та управління системою Рішення, яким би воно не було, має відповідати вимогам з цього набору або перевершувати їх – і при цьому успішно працювати в сучасних умовах (інакше […]

Не створюйте рішення «на перспективу»

Річард Монсон-Хейфел Сьогоднішнє рішення стає завтрашньою проблемою Ніхто не може передбачити майбутнє Якщо ви згодні з цієї загальної істиною, виникає питання: що слід вважати майбутнім Десятиліття Два роки Двадцять хвилин Якщо майбутнє неможливо передбачити, значить, ви не можете прогнозувати взагалі нічого Поточний момент і те, що йому передувало, – от і все, що ви знаєте, […]

Неоднорідність перемагає

Едвард Гарсон Природна еволюція компютерних технологій привела до важливих змін в тих інструментах, які використовують архітектори для створення компютерних систем Ці зміни воскресили інтерес до Багатомовна програмування, тобто до використання декількох мов в якості основних при реалізації програмної системи

Архітектор повинен бути практиком

Джон Девіс Хороший архітектор повинен подавати особистий приклад іншим Він повинен бути здатний замінити будь-якого члена своєї команди і виконати будь-яку роботу – від прокладки мережі та налаштування процесу збирання до написання модульних тестів і виконання тестів продуктивності Без доброго розуміння всього діапазону технологій архітектор мало чим відрізняється від звичайного керівника проекту Члени команди можуть […]

Бізнес і незадоволений архітектор

Чед Лавінь У карєрі будь-якого АРХІТЕКТОРА настає момент, коли стає ясно, що багато питань, з якими він має справу, вже зустрічалися на його шляху раніше Змінюються проекти та області, але проблеми залишаються колишніми На цій стадії ми можемо спертися на свій досвід, щоб створювати рішення швидше і залишати максимум часу для більш цікавих завдань Ми […]

Сумнівайтеся в допущених – особливо у власних

Тімоті Хай Закон відкладених рішень Уезерна говорить: «Допущення – корінь всіх провалів» Звичайно, формулювання не дуже серйозна, але коли припущення обходяться вам в кілька тисяч (а то й мільйонів) доларів, стає не до сміху

Ваш клієнт – не ваш клієнт

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

Проектуйте тільки те, що можете запрограмувати

Майк Браун Архітекторів часто підстерігає спокуса створити витончені абстракції і дизайн для елегантного вирішення поточної задачі Ще більш спокусливо виглядає включення в проект нових технологій Але в кінцевому підсумку комусь доведеться реалізовувати ваші ідеї, і архітектурна акробатика, на яку ви прирікаєте розробників, відібється на ході проекту