Що планувати перед початком розробки проекту? [зачинено]

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

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

Щоб краще зрозуміти, про що я прошу, як я,

а) Розділіть проект на компоненти,

б) Плануйте їх взаємодії, наприклад, чи слід робити діаграми класів, писати одиничні тести тощо?

Будь-які ідеї?

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

• Почніть з цілей проекту. Цілі обов'язково є найяскравішими, але допомагають зосередитись на тому, що клієнт чи користувач має намір робити з програмним забезпеченням. Зрештою, ви хочете виконати ці цілі - навіть якщо це означає відмову від деяких справді цікавих функцій.
• Потім я починаю розбивати додаток на його субдомени. Напевно, існує сто різних способів зробити це, тому ми починаємо з цілей проекту. Ми хочемо розбити програму на деякі пов'язані підсистеми, які підтримують ці цілі. Це допомагає нам зосередитись на наступному завданні.
• Визначте, як і коли потрібно взаємодіяти підсистемам. Ми не обробляємо деталі, просто інформацію високого рівня, щоб переконатися, що у нас є інтегрована система підсистем. Вам потрібно загальне уявлення про це, щоб ви могли чітко розробити деталі, які підтримують загальні цілі проекту.
• Лише деталі постачань для підсистеми, над якою я працюю на даний момент (подібно до вашої поточної стратегії). Я вже знаю, як ця підсистема повинна взаємодіяти з іншими підсистемами, але мені може знадобитися опрацювати пару альтернатив, щоб це мало сенс. Кожна підсистема відокремлена інтерфейсом, тому я можу максимально налаштувати реалізацію, не порушуючи систему в цілому.
• Перегляньте, як реалізуються речі в моїй поточній підсистемі порівняно з тим, як вона реалізована в інших підсистемах. Кожен невідповідний підхід - це те, чому користувач повинен навчитися. Це нормально, якщо ми говоримо про абсолютно нову концепцію. Заради зручності використання ми не хочемо 5 різних способів видалити інформацію, яка присутня просто тому, що ми ліниві. Повторне використання тих же елементів інтерфейсу користувача - найшвидший спосіб зробити додаток більш інтуїтивним. Вивчити три поняття набагато простіше, ніж навчитися 20.

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

Я думаю, що було б краще, якби я перейшов за специфікаціями

Правильно. Гарна ідея.

спланував, як система працюватиме до того, як я її зашифрував.

Добре. Робіть більше цього.

які основні компоненти,

Відмінно.

як вони збираються взаємодіяти,

Правильно.

Я просто не впевнений, що саме я повинен планувати.

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

Прочитайте модель 4 + 1 перегляду: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

Читайте в рамках Захмана: http://en.wikipedia.org/wiki/Zachman_Framework

Це те, що потрібно планувати.

як я повинен a) Розділити проект на компоненти,

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

Якщо ви сумніваєтеся, прочитайте креслення J2EE для ідей.

http://www.oracle.com/technetwork/java/javaee/blueprints/index.html

як я повинен b) планувати їх взаємодії, наприклад, чи варто робити діаграми класів, писати одиничні тести тощо?

Так. Гарні ідеї, всі.

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

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

Отже, вам слід переглянути характеристики, взяти інтерв’ю у замовника та з’ясувати, чи це саме те, що він / вона справді потребує та хоче, і чи може він собі дозволити тощо.

Розробка справ для тесту / використання та перегляд із замовником. Якщо вимога не перевірена, викиньте її.

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

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

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

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

Тоді я будую 1 функцію зверху вниз, щоб ви повністю реалізували щось.

Тоді йдіть звідти.

Все

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