Разработка программного обеспечения с помощью псевдокодирования?

Знаете ли вы хороший способ разработки (т.е. записи) программного обеспечения с помощью метода, основанного на псевдокоде?

Я новичок в разработке программного обеспечения и прочитал некоторую информацию о UML. Мои скромные иерархии классов пока хороши, однако, после того, как они становятся сложными, я замечаю, что, увидев картину целиком, я мог бы использовать другую структуру для большей расширяемости в будущем. Поскольку Python хорош для создания прототипов, я почти в порядке, когда начинаю писать, но не совсем.

Поэтому я попробовал диаграммы классов UML, но, похоже, они мне мало помогают. Проблемы, которые я там решаю, я легко решаю в своей голове. Но я замечаю дополнительные требования к дизайну, когда начинаю псевдокодировать реальные методы.

Итак, если вы хотите создать псевдокод, как бы вы это сделали? Я считаю, что метод, который примерно один к одному с кодом, работает лучше всего. Но большинство программ UML даже не показывает код метода (в отличие от изображений, например, в GoF).

Кто-то утверждал, что UML предназначен только для документации и презентаций, а не для дизайна? Я тоже чувствую это. Я думал, что чистый UML и некоторые упрощенные наброски на доске - это путь к разработке программного обеспечения, пока я не нашел Google Envision APDT.

Так стоит ли искать гибкую разработку, или я случайно называю ее гибкой - я думал, что гибкость - это только расписание? Или я проектирую неправильно (с UML) - кто-нибудь разрабатывает псевдокод? Как мне найти хороший инструмент для этого?

 I thought agile is about schedule only?

Это не просто планирование. Гибкая разработка программного обеспечения - это скорее эволюционная разработка и итеративная поставка с временными рамками с адаптивным планированием, которая способствует гибкому реагированию на изменения, запрошенные владельцем продукта.

 Or am I designing incorrectly (with UML) - does anyone design by pseudocode? 

По моему опыту, диаграммы намного легче понять с точки зрения клиентского стенда. Они визуально привлекательны и часто очень красочны и просты в использовании. Тем не менее, очень трудно поддерживать диаграммы из-за характера разрыва с реальным кодом приложения. Каждый раз, когда в приложение вносятся изменения, разработчик должен уделять время обновлению всей документации, включая диаграммы. Однако эту проблему можно легко устранить, если в команде или компании есть БА, который хорошо понимает бизнес-процесс клиента и может управлять диаграммами UML.

Такие инструменты, как UML, могут упростить этот процесс, но хорошо работают только с объектно-ориентированным программированием. Псевдокод гораздо проще для технических команд. Процесс создания этого кода значительно увеличивает скорость фактической фазы разработки языка программирования.

Есть и другие альтернативы, которые вы можете посмотреть:

• Диаграммы потока данных
• Диаграммы состояний
• Технологические схемы

Хорошие ссылки, чтобы посмотреть: Учебные пособия по разработке программного обеспечения . Кроме того, я бы лично посоветовал прочитать хороший блог о псевдокоде или коде? опубликовал Coding Horror - мой любимый блог для чтения :)

В общем, есть некоторые компромиссы, которые вы должны рассмотреть.

При программировании на ассемблере написание псевдокода имеет большой смысл. Алгоритм может быть проверен перед тем, как приложить усилия, чтобы вручную перевести его на язык ассемблера, а затем отладить перевод. Это все еще имело некоторый смысл для скомпилированных языков первого поколения, таких как FORTRAN IV, где единственной управляющей конструкцией был GOTO, все переменные (кроме формальных аргументов) были глобальными, а имена переменных были ограничены шестью символами.

Сегодня мы очень мало программируем на ассемблере, и я вижу небольшую ценность в написании псевдокода, а не просто в написании кода. На приличном языке реальный код будет следовать псевдокоду почти дословно, а псевдокод - просто трата времени.

Однако я не начинаю кодировать внизу. Я следую TDD и начинаю с теста. Затем я начинаю кодировать сверху и постепенно опускаю вниз, чтобы пройти тесты.

Альтернатива псевдокоду - не писать 1000 строк низкоуровневых классов. Вместо этого начните с самого верха, вызывая идеальный, но несуществующий API для вашего домена. Затем создайте API.

Я считаю, что диаграммы классов едва стоят усилий, даже если вы пропустите список всех методов и просто покажете иерархию наследования. Диаграммы последовательности хороши, но я чувствую себя неловко, когда я рисую их (вероятно, только я).

Я считаю, что диаграммы потоков данных и структурные диаграммы более полезны (хотя структурные диаграммы обычно связаны с BDUF и поэтому в настоящее время не пользуются популярностью). DFD особенно полезны для функционального разложения. Каждый «пузырь» в DFD может быть разбит на собственный DFD, пока вы не достигнете желаемого уровня детализации.

Я думаю, что графические инструменты лучше, чем псевдокодирование, но UML просто настолько сильно усложнен, что объединяет в себе плохие методы :-)

Чтобы быть немного более ясным: я думаю, что программирование - это в основном способ анализа определенной проблемы, разделения ее на более мелкие компоненты и их взаимодействие. Это «путешествие, а не пункт назначения», вы постоянно улучшаете свои знания о проблеме, поэтому график компонентов меняется: слои появляются и исчезают, функции и элементы данных перемещаются вверх и вниз и т. Д.

Естественным инструментом для отслеживания этого процесса является скетчборд, настолько простой, насколько это возможно, но достаточно сложный, чтобы помочь быстрому пониманию (те же цвета, формы, стрелки для того же логического значения). Я не нашел серебряную пулю, и, возможно, я напишу свою собственную однажды, но теперь я использую gliffy ; в сочетании с функцией увеличения prezi это было бы почти идеально.

Почему не псевдокодирование? Псевдокодирование - это один шаг вперед к реализации, «сериализованная форма графа компонентов», когда вы еще формируете свои идеи. Не хорошо, ограничивает вашу голову. По своему опыту я обнаружил, что чем позже я начинаю кодировать, тем меньше кода мне приходится выбрасывать ...

Но, возможно, это потому, что я написал все эти выброшенные коды, поэтому мне не нужно писать их сейчас, опыт, который я получил от них, у меня при разработке системы? Ну, я должен изменить утверждение.

Если вы потеряли свой график и видите много эквивалентных возможных решений, перейдите к псевдокоду или даже напишите этот код с фиктивными объектами - в Java это почти безразлично. Посмотрите код, почувствуйте структуру и удобство использования этих компонентов, это поможет вам исправить ваш график и принимать решения. Но это работает ТОЛЬКО если вы готовы выбросить этот код, если считаете, что он плохой. Я думаю, что это преимущество псевдокода: меньше соблазна сохранить его, когда он работает, но он неправильный по структуре (и, как всегда, у вас не хватает времени). :-)