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

9

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

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

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

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

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

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

Gerenuk
источник
3
Стив Макконнелл описывает процесс программирования псевдокодов (PPP) в своей книге Код завершен 2 . Этот метод концентрируется на низкоуровневом проектировании и реализации, но он может быть хорошо прочитан, если вы к этому стремитесь.
Титон

Ответы:

8
 I thought agile is about schedule only?

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

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

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

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

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

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

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

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

Юсубы
источник
3
+1 за ссылку на псевдокод или код . Просто напишите этот чертов код.
Кевин Клайн
@ElYusubov: Спасибо за объяснение. Кажется, вы также подразумеваете, что UML больше подходит для презентации? Для реального дизайна я не делаю акцент на этом? В конце вы предлагаете 3 диаграммы. Могут ли они быть сделаны один к одному с некоторым расширением кода. Я имею в виду, напротив, некоторые вещи, которые работают в диаграмме, могут не работать с кодом - чего я хочу избежать.
Геренюк
@Gerenuk, диаграммы потоков данных могут быть сделаны один к одному с потоком кода. Тем не менее, диаграммы обычно используются, чтобы увидеть дизайн высокого уровня и взаимодействие между компонентами / модулями / вариантами использования.
Юсубов
3

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

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

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

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

Кевин Клайн
источник
Когда я только начинаю кодировать, иногда позже я замечаю, что с точки зрения дизайна я мог бы выделить какой-то код. Хотя рефакторинг - это нормально, его все равно можно было бы избежать, если бы я сначала посмотрел на обзор всего кода и использовал некоторую креативность. Графическое представление псевдокода может представлять все в одном сжатом графе. Моя ошибка где-то еще?
Геренюк
2
Ваша ошибка в том, что рефакторинг кода - это нечто большее, чем рефакторинг псевдокода. С современной IDE проще и быстрее писать реальный код, чем возиться с псевдокодом на бумаге в текстовом редакторе.
Кевин Клайн
1

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

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

TMN
источник
0

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

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

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

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

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

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

Лоран Кедвес
источник