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

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

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

Які стратегії у вас є для боротьби з цими типами функціональних змін, потреба яких виникає - частіше внаслідок факторів навколишнього середовища, а не зміни специфікацій - пізніше в процесі розробки або в результаті тестування? Як ви балансуєте між уникненням передчасної оптимізації / YAGNI / надмірного ризику розробки рішення, яке пом'якшує можливі, але не обов'язково ймовірні проблеми, на відміну від розробки більш простого та легшого рішення, яке, ймовірно, буде настільки ж ефективним, але не містить готовності до будь-яка можлива подія?

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

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

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

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

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

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

Розподілене обчислення та паралельне програмування додають ще два виміри щодо розміру простору "складності", який зростає принаймні в кубічному (sp?) (N ^ 3) порівняно з "нормальним" програмуванням. Наприклад, подумайте про нові набори проблем і помилок, з якими нам доводиться впоратися. Навіть грати з ідеєю, що ви могли б зрозуміти взаємозв'язки та побічні ефекти в такому масштабі, смішно.

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

Деякі ідеї, як впоратися з усім цим, на додаток до тих, що вже відповіли на інші відповіді:

• Велика смиренність
• Прийміть, що ваша система / програма недосконала, непостійна та неповна .
• Підготуйтеся до помилок
• Отримати зміну
• План надмірності
• Подумайте про майбутню перевірку
• Подивіться (або вивчіть) біологію чи соціологію, як ведуть себе складні системи
• Постарайтеся зробити все можливе, щоб уникнути змін у стані. Перейдіть на протоколи без стану (наприклад, REST і HTTP).
• Функціональне програмування може полегшити частину болю

Я думаю, я міг би продовжувати і продовжувати. Дуже цікава тема :)

Я не погоджуюся з духом відповіді @ Péter Török, оскільки він передбачає, що команда (або окрема особа) можуть обов'язково передбачити найбільш ризикові елементи на початку життєвого циклу проекту. Наприклад, у випадку з ОП команда не могла передбачити зростаючу складність, пов'язану з багатопотоковим рішенням, поки їхні спини не опинилися до стіни.

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

Ось як я впорався з цією проблемою:

1. Дотримуйтесь порад Фред Брукс і організуйте своїх розробників, як хірургічна команда .
2. Виберіть мудрого та "доброзичливого" майстра-хірурга, який може: А) здобути довіру та повагу своїх однолітків; і В) своєчасно приймати важкі рішення.
3. Очікуйте, що майстер-хірург зменшить складність в передній і задній частині процесу розвитку.

Детальніше про пункт №3:

1. Майстер-хірург повинен усвідомлено докласти зусиль, щоб запропонувати найпростіше рішення, яке спрацює. Роки значущого досвіду повинні поставити майстра-хірурга в змогу це зробити.
2. Більш широка організація, тобто начальники хірурга-майстра, повинна дати команді достатньо часу та ресурсів, щоб зменшити складність після суднової дати. Це дозволить команді розробників своєчасно вводити код коду та виконувати kaizen для зменшення складності на постійній основі.

Код до інтерфейсів

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

1. переконайтеся, що ви маєте повний контроль над тим, які функції використовуються
2. дозволяють мати кілька реалізацій одного і того ж функціоналу.
3. знижуйте загальну складність, оскільки модулі з'єднані лише тонко, а не повністю переплетені.

можна починати з простої передумови та моделі та раптом мати складність в процесі розвитку проекту

Не дивно.

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

Середнього місця мало.

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

Як керувати цим?

1. Майте реалістичні очікування. Ви вигадуєте щось нове. Там повинні бути частини , які ви не розумієте.

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

3. Майте реалістичні очікування. Якби це було просто, хтось інший це зробив би спочатку, і ви можете просто завантажити це рішення.

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

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

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

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

Однак тут може існувати безліч локальних, специфічних факторів, таких як:

• Цілі цієї системи. Це разова річ? Чи маєте ви намір продовжувати роботу цієї системи середньо- та довгостроково?

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

• Цілі команди. Це більше "щось робити зараз, будь-якою ціною" або "зробимо це правильно"?

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

• Ваше розуміння проблеми. Чому попереднє рішення не спрацювало?

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

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