Зараз я працюю над проектом, який збирається досягти понад 5000 рядків коду, але я ніколи не повністю продумав дизайн. Які методи я повинен використовувати для структуризації та організації свого коду? Папір і ручка? Діаграми UML? Щось ще?
Відповіді:
Ви, мабуть, отримаєте стільки різних поглядів, скільки відповідей буде. Але ось моя точка зору.
Для початківців 5000+ рядків коду - дуже маленький проект. Тепер, як ви займаєтесь розробкою проектів, які зростають. По-перше, ви проектуєте свою систему, а не код. Код насправді є вторинним щодо архітектури. Почніть з підтримки мінімальних поточних вимог. Поставте кілька спрощених креслень компонентів. Мені особисто подобається UML, але все візуальне буде добре. В ідеалі, ви хочете дотримуватися тут належних дизайнерських практик (інтерфейси, розділення проблем тощо).
Як тільки ви підтримаєте мінімальні вимоги до свого дизайну, кодуйте його. Знову ж таки, спробуйте дотримуватися належних методів кодування.
Після цього ітеративно додайте більше функціональності, оскільки виникають нові вимоги. В ідеалі ви також хочете оновити свій дизайн.
Важливо, виходячи з мого досвіду, - це не проектувати вашу систему в очікуванні неіснуючих вимог. Інакше ваш проект буде рости дуже швидко і стане дуже складним за короткий час. Знову ж - дотримуйтесь передового досвіду та починайте з конкретних сучасних вимог.
Діаграма потоку, діаграма класів, діаграма використання випадків - це обов'язкові діаграми для великих проектів. Шукайте та вибирайте, які зовнішні бібліотеки вам потрібні, і шукайте будь-які подібні відкриті вихідні коди, які ви можете використовувати (для вивчення та скорочення часу розробки).
Я пропоную вам придбати дошку та кілька різнокольорових магнітів & Post-It. Це допоможе вам визначити свої завдання.
ps 5000+ рядків кодів, однак, не "великі". Програмне забезпечення CMS / Forum має більше 5000+ рядків кодів.
Я б створив діаграми пакетів і класів. У пакетній діаграмі мені було б цікаво групувати класи та інтерфейси логічно. Я також хотів би створити внутрішні пакунки тощо.
Але спочатку потрібно подумати, що повинна робити програма. Ви можете створити діаграми наборів або зробити це вручну. Я роблю це вручну за допомогою діаграми класів, тому що я вважаю за краще отримати код негайно, і простіше пізніше поміняти схеми класів пакетів. Використання діаграми класів дає мені свою Java. Якщо мені це не подобається, я його вручну змінюю. Новий код автоматично оновлюється в моїх схемах. Я маю візуально оновлене подання свого коду на високому рівні. Дуже корисно, тому що навіть якщо я кодую, я завжди можу зайняти кілька хвилин, щоб подивитися на те, як рухається мій проект у графічному вигляді. Я просто перетягую об'єкти в потрібний пакет вручну, щоб організувати його. Я думаю, що мій код краще використовувати більш високий рівень абстракційного пакету та діаграми класів.
(джерело: ejb3.org )
деякі мої колеги сказали, що мій спосіб роботи - це лайно .... але мені це подобається :-)
Безумовно. У мене є невелика дошка "планшетного" сухого стирання, яку можна використовувати для подібних речей, але використовуйте все, що вам подобається. Важливим є те, що ви можете легко звести свої думки і побачити велику картину того, як все поєднується.
Деякі люди віддають перевагу більш офіційним планам, як, наприклад, UML-діаграми, але я вважаю, що занадто легко захопитись мікроменеджментом, як має виглядати кожен метод. Однак ще раз використовуйте все, що вам зручніше.
EDIT: Можливо, вас також зацікавить грамотне програмування . Ідея полягає в тому, що ви можете все це планувати і поступово отримувати більш конкретні. Наприклад, ви можете сказати, що ваша програма складається з:
Тоді ви можете уточнити свою ідею перетворення тексту в зображення. Так це може виглядати так:
Тоді ви можете уточнити ідею вибору випадкових кольорів, і незабаром ви просто пишете звичайний код.
Для мене діяльність з розробки програмного забезпечення - це низка прогресивно більш тонких конструкцій для вирішення певної проблеми. Коли ви просто маєте уявлення про високий рівень того, що ви будуєте, ваш дизайн може бути чимось дуже високим рівнем, наприклад, "буде веб-додаток, який спілкується з базою даних SQL та кількома веб-сервісами" або щось подібне. Потім, коли ви детально вивчаєте деталі кожної деталі, ви отримуєте більш детальну деталь дизайну. Залежно від складності рішення буде більше або менше ітерацій проектних зусиль. Остаточна ітерація включає створення фактичного коду, який реалізує більш високі рівні дизайну.
Для мене різниця між архітектурою та дизайном мінімальна, і вони просто різні ітерації процесу, який я описав вище. Лінія між двома нечітка і різна для різних людей.
Мистецтво вирішувати, на якому рівні деталізації дизайну потрібно звертатись, для яких частин програми та в які моменти життєвого циклу проекту. Для проектів з високим рівнем ризику, високої складності, можливо, ви хочете мати дуже детальний дизайн, перш ніж писати рядок коду. Що стосується менших проектів, ви можете піти з того, щоб зробити дуже мало переднього дизайну і просто вибити якийсь код, а потім побачити те, що не працює, і переробити ці області. Тут не одна відповідь на написання. Зазвичай він знаходиться десь між цими двома крайнощами.
У мене є допис у блозі, який розповідає про деякі принципи, якими я користуюся під час підходу до архітектури. Можливо, вам це стане в нагоді, коли ви думаєте в цьому напрямку. Частина статті є специфічною для .NET, але більшість не є.
Я раніше задавав собі це саме запитання. Зараз я просто практикую тестові розробки, і не хвилююся з цього приводу. Я взагалі не "планую" код, окрім дотримання стандартів обраної архітектури. Коли я запускаю проект, я маю деяке уявлення про те, що буде потрібно, але в міру розвитку розробки я намагаюся зберігати відкритість. Слідуючи тестовим розробкам та постійно переробляючи код, мені не доведеться "планувати" код. Я просто задовольняю один тестовий випадок за іншим, і дизайн виходить із рефакторингу. Це завжди кращий дизайн, ніж будь-які плани, які я міг зробити перед кодуванням.