Документы дизайна по сравнению с UML или обоими?
Мне было нелегко сидеть перед UML и вытаскивать значение из него, потому что на такую же работы как программирующий (при использовании выразительного языка) почти походит. Я нахожу, что запись естественного языка говорит мне больше о проекте программного обеспечения, чем создание сложных схем. Я плохо знаком с UML, хотя и я задался вопросом от других, которые знают UML хорошо:
- Действительно ли UML стоит все время, он берет для изучения / делают, даже для маленько-средних проектов?
- Могут хорошо разработанные документы дизайна, в то время как еще высокоуровневый, быть достаточными для хранения программистов на цели для создания правильного кода, даже в командах?
3 ответа
Я не думаю, что одного UML достаточно.
Мне было трудно сидеть перед UML и извлекать из него пользу , потому что кажется, что работы почти не меньше программирования (если вы используете выразительный язык).
Я согласен с этим. UML может предоставлять сигнатуры методов, но вы не заполняете суть метода. Хуже того, вы не можете сделать ничего похожего на TDD с UML. Если бы у меня был выбор, я бы предпочел TDD и работающий код, чем диаграммы UML.
Я считаю, что написание естественного языка говорит мне больше о программном проекте , чем создание сложных диаграмм.
Отлично. Картинки могут быть полезны, если только они не плохие. Диаграммы последовательностей имеют тенденцию становиться невероятно сложными для всех потоков, кроме тривиальных.
Стоит ли UML тратить все время на изучение / выполнение даже для малых проектов?
Поставщики и архитекторы скажут вам, что UML незаменим, но я не не согласен. Я попадаю в лагерь «скечеров» пользователей UML .
Может ли хорошо разработанная проектная документация, хотя и более высокого уровня, быть достаточной, чтобы удерживать программистов на пути к созданию правильного кода даже в командах?
Не знаю, чего достаточно, чтобы удержать программистов в нужном направлении, но я предполагаю, что UML не играет большой роли. Архитекторам это нравится, потому что инструменты UML занимают их, но большинству разработчиков все равно, кроме прямоугольников и стрелок на белых досках.
Я бы ответил:
Ничто, абсолютно ничто не заменит необходимость хорошего общения между программистами в команде программистов и руководством.
Это означает определенный уровень разбивки задачи на простые формулировки "что нам нужно сделать" для менеджеров и объяснение любых препятствий.
Я работал над небольшим проектом, где вся структура классов программы была разработана кем-то на UML до написания кода. Отлично, но дизайнеры не предусмотрели, как классы могут быть использованы, или необходимость изменить определенные структуры, чтобы лучше соответствовать логике программы. Они просто выкинули дизайн, который, как им казалось, будет работать.
Я еще не встречал человека, который мог бы спроектировать программу в своей голове и точно так же создать ее при написании, за исключением очень простых вещей. Процесс довольно органичный, и по ходу дела все должно меняться по мере того, как программисты осознают свои прежние ошибки и исправляют их. Я понимаю, почему начинает происходить "ползучесть функций", и именно здесь руководство должно понимать, что происходит, быть в курсе событий и обновляться. Хорошие менеджеры прислушиваются к тому, что говорят им программисты, и соответствующим образом корректируют планы.
Итак, из двух вариантов я бы выбрал высокоуровневый проектный документ: мы хотим, чтобы программное обеспечение делало вот это, работало на этой платформе, принимало вот такие входные данные и выводило вот такие вещи. Это работает, если придерживаться вышеизложенного.
UML, насколько я понимаю, того не стоит.
На мой взгляд, нет. Однажды я проходил модуль по проектированию ОО в рамках MSc по информатике, и UML почти не упоминался (хотя, на мой взгляд, его следовало бы обсуждать гораздо больше, учитывая его влияние).
В письменном тексте больше возможностей уменьшить двусмысленность, чем в диаграмме UML, большинство диаграмм UML оставляют много возможностей для интерпретации. Несмотря на это, я являюсь большим поклонником использования диаграмм в документах по проектированию программного обеспечения, и многие диаграммы UML чрезвычайно лаконичны: развертывание, состояние, класс и действие - мои любимые. Когда я создаю диаграммы UML, я стараюсь строго придерживаться соглашений, но не позволяю им мешать, если они не могут представить концепцию, которую я пытаюсь донести.