Скільки деталей вкласти в першу ітерацію проекту?

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

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

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

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

Питання, пов’язані з цим: Коли добре жертвувати «акуратністю» дизайну, щоб виконати проект?

Однозначної відповіді немає, оскільки це повністю залежить від проекту. Тут потрібно подумати про дві речі. Яка ваша цільова ціль? Як ви розраховуєте потрапити туди?

Кінцевий результат

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

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

Як ви розраховуєте потрапити туди?

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

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

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

Тепер знайдіть власну відповідь

Для більшості відповідь буде лежати десь посередині. Дайте відповіді на обидва ці питання щодо вашого проекту, і це повинно вести вас в основному напрямку.

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

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

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

Звідси випливає, що якщо проблема, яку має вирішити шаблон програмного забезпечення, не існує у вашому конкретному програмному забезпеченні, то вам не потрібен шаблон. Крім того, будь-які дискусії про те, які зразки можуть знадобитися вашому програмному забезпеченню, повинні також включати детальне обговорення запропонованого програмного забезпечення: що він повинен робити? Яку проблему вона вирішує? Скільки користувачів буде? Чи будуть користувачі якось обмінюватися даними? І так далі.

Проблема, яку повинні вирішити винятки, - коли щось трапляється, з кодом нічого не можна зробити. Прикладом може бути операція «Файл / Відкрити», де вказано ім’я файлу, яке не існує на носії інформації. Винятки дають коду можливість сказати абоненту "Щось сталося, що заважає мені продовжувати, і я нічого не можу зробити з цим, тому я здаюсь". Якщо у вашому коді немає жодного місця, де існують такі умови, то вам не потрібні винятки. Або ви можете просто повернути код помилки і взагалі уникнути виключення.

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

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

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

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

З усіх цих функцій з'ясовуються ключові речі, які потрібно зробити програмі - основні функції.

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

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

Потім ви можете продовжувати реалізовувати інші функції за потребою.

Якість коду та функції

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

Тепер, що з обробкою виключень?

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

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