Тримайте це просто зараз чи програмуйте з майбутнім на увазі?

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

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

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

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

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

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

Якщо в крайній термін є достатня гнучкість (1 день, за звуком цього, тому прагніть продовжити на 2,5 дня), тоді обов'язково продовжуйте і кодуйте відоме майбутнє!

Уникайте потрапляння здобичі (рано) до Другого системного впливу . Ось кілька хороших методик застосування:

1. Безумовно, уникайте де-рейлінгової версії 1 лише тому, що ви бачите у версії 2. Планування заздалегідь чудово, але творець специфікацій v2 повинен відповідати за збій v2, а не v1.
2. (Якщо можливо) подивіться, чи зможете ви творця переробити вимоги до версії 2, які зараз не потребуватимуть більших змін - а потім плануйте їх пізніше, можливо, для v3.
3. Майте на увазі YAGNI , але намагайтеся кодувати розширюваність на увазі - уникайте магічних чисел, твердо кодованих значень, пишіть хороші одиничні тести чи контракти з кодом тощо. Застосування хороших методів на початку зробить рефакторинг та зміни коду менш болісними на цьому шляху.

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

Упорядкування [міста] може бути ефективнішим, якби всі громадянські системи будувались паралельно і періодично замінювалися (саме тому катастрофічні пожежі - наприклад, великі пожежі Лондона та Чикаго - іноді допомагають у плануванні міста). Але повільне нарощування нових функцій дозволяє місту працювати більш-менш безперервно протягом століть.

• Карл Саган, Космос : http://www.eridanus.info/genesis.html

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

Залиште так, як є.

Розробники насправді ВІДПОВІДАЮТЬ старий проект, який робить те, що потрібно робити, і не більше того.

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

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

Взагалі, хороший розробник передбачає майбутні вимоги, але коли настає термін, настав час реагувати на помилки у тому, що ви вже отримали, а не «качати човен».

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

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

Якщо є сумніви щодо необхідності v2, тоді дотримуйтесь YAGNI. Крім того, якщо ви з іншого боку спектру і маєте одного з тих клієнтів, які постійно розсипають вас своїми ідеями до того, як вони формуються, то перевіряйте ваші електронні листи лише 2 або 3 рази на день і не поспішайте з дією, ви здивуєтеся скільки "проблем" і запитів стають неактуальними, перш ніж ви навіть прочитали їх.