Наскільки корисний UML, якщо ви розробник, який працює сам над проектом?
Відповіді:
Це може бути дуже корисно, якщо проект достатньо великий, щоб у вас виникли проблеми тримати все прямо в голові. Як дістати щось на папері / діаграмах також може допомогти проектуванню та вирішенню проблем, принаймні для мене.
... Я також визнаю, що для особистих проектів мої діаграми не такі формальні, як для проектів на роботі, мені просто добре працювати з ними ...
Це дуже корисно і цінно .
Як говорили інші, це найкраще для спілкування, і при короткому погляді ви можете сказати «лише 1 розробник, так що спілкування не потрібно», але я не думаю, що це правда.
То для кого це UML та комунікація?
Крім того, вони також корисні для практики, коли ви потрапляєте в ситуацію, коли вони є обов'язковими.
Словом, напевно, не дуже.
Найбільша цінність UML - це спілкування, тому мало що можна запропонувати команді для однієї людини. Хоча я все-таки використовую його для ескізних дизайнерських ескізів і т. Д. Візуалізація може значно допомогти зрозуміти складні проблеми.
Одне з можливих важливих застосувань - це документування проекту для наступника (ів) - навряд чи ви будете єдиним, хто працював над цим проектом (будь-яким проектом).
Відповідь, звичайно, залежить від розміру та складності проекту, від того, наскільки ви маєте намір взяти моделювання та від того, чи потрібно вам надати офіційний проект проекту.
Я намагався використовувати його для невеликих особистих проектів, і це було не дуже корисно. Непарний клас чи діаграма послідовностей можуть допомогти впорядкувати ваші думки, але після балу це буде більше роботи, ніж варто.
Я багато працюю в одиночку (я фрілансер) і, як правило, не використовую UML. Зазвичай ERD та деякі примітки в інструменті організації (я використав один коментар). Я ніколи не відчував нестачі. Але я бачу, як це корисно у великих середовищах з великою кількістю людей, які працюють над одним проектом.
Це може бути корисно, тому що, коли ви намагаєтесь документувати свої дизайнерські та архітектурні рішення в UML, це змушує задуматися над додатком, а іноді відкривати для себе нові речі та робити кращі ідеї. Але я погоджуюся з іншими, що якщо це невеликий проект, ви, можливо, не отримаєте великої користі від нього, працюючи в самоті.
Маргінальне, я думаю, UML призначений для передачі ідей дизайну. Якщо ви дійсно думаєте про UML і можете зробити його так само швидко, як і інші способи відображення цього дизайну, обов'язково продовжуйте його та використовуйте. Інакше вам, мабуть, краще розібратися з чимось, що схоже на грубі ескізи і, можливо, трохи UML "Lite", оскільки ваш проект потребує цього.
Зрозуміло, вичерпайте кілька випадків використання, якщо відчуваєте, що певна зона потребує їх. тощо.
Куди б ви не пішли, вам знадобиться щось, на що слід звернутися через 12 місяців, коли настав час подумати про v2.
У деяких проектах я використовував дуже мінімальну реалізацію (фігурки, з'єднані ящики та маркування). Я думав, що легше представити певний процес, ніж намагатися описати у письмовій формі. Якийсь пурист, мабуть, скаже, що це насправді не UML, але клієнтів це не хвилює, тому я теж не знаю.
Графічне зображення архітектури може допомогти, якщо архітектура занадто велика, щоб просто мати на увазі (це те, що ви повинні визначити для себе).
Вам не потрібно щось формальне, як UML, якщо ви робите це лише для себе.
Мета - візуалізувати архітектуру, щоб ви могли з нею оброблятись. Використовуйте все, що працює, будучи максимально безперешкодним.
Це хороша практика зберігати хорошу документацію проекту, але для однієї людини це зробити не дуже просто і забирає багато часу, моє становище тут полягає в тому, що вам, звичайно, потрібно зробити деякі UML, і якщо ваша програма дуже складна або ви збираєтеся випустити свій код, для цього вам потрібно. якщо ваш проект складний і великий, ви можете подумати, щоб зробити документацію досить добре, тому якщо ви пройдете певний проміжок часу, ви зможете легко переробити її.