Следует ли использовать псевдокод до фактического кодирования?

Псевдокод помогает нам понимать задачи в не зависящей от языка манере. Является ли наилучшей практикой или предложенным подходом создание псевдокода в качестве части жизненного цикла разработки? Например:

• Определить и разделить задачи кодирования
• Написать псевдокод
• Получите одобрение [по PL или TL]
• Начать кодирование на основе псевдокода

Это предлагаемый подход? Это практикуется в отрасли?

Написание псевдокода перед кодированием, безусловно, лучше, чем просто кодирование без планирования, но это далеко не лучшая практика. Разработка через тестирование - это улучшение.

Еще лучше проанализировать предметную область и разработать решения с использованием таких методов, как пользовательские истории, сценарии использования, карты CRC, создание диаграмм в соответствии с такими методологиями, как Cleanroom, RUP, Lean, Kanban, Agile и т. Д.

Тщательное понимание природы проблемы и компонентов, которые вы используете для реализации решения, является принципом, лежащим в основе передового опыта.

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

Нет, сначала не псевдокод

Это слишком много накладных расходов. Вы делаете работу по написанию логики без каких-либо преимуществ. Вместо этого я бы предложил любое из следующего:

1. Прототип на языке, который вы собираетесь отправить (AKA Напишите один, чтобы выбросить )
2. Диаграммы архитектуры с фрагментами кода для проверки предположений / ключевых конструкций
3. Разработка через тестирование, где вы сначала пишете свои интерфейсы / структуру кода, а затем тесты, а затем реализацию кода.

Все три из них направляют вас прямо к вашему решению, в отличие от псевдокода. Лично я склонен использовать техники 1 или 2 в зависимости от размера команды. Для небольших команд (например, 5 человек или меньше) прототипирование работает очень хорошо. Для более крупных команд, в которых несколько групп разработчиков работают параллельно, я обнаружил, что документация, подготовленная на раннем этапе с помощью метода 2, работает хорошо, потому что она дает вам кое-что для обсуждения на ранней стадии и помогает вам лучше определять границы компонентов. Я уверен, что TDD будет работать очень хорошо, но мне еще предстоит работать в команде, которая посвятила себя этому процессу.

На мой взгляд, псевдокод имеет только две допустимые цели:

(1) Для программистов, которые должны изучать понятия модульности и алгоритмов, но еще не владеют языком программирования.

(2) Рассказать, как что-то будет работать нетехническому человеку или просто ради целесообразности на собрании типа доски.

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

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

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

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

Но как формализованная часть процесса разработки? Ни за что. Это спорадически полезный инструмент для людей. Есть лучшие способы «узнать, что вы пишете, прежде чем писать», например:

1. определение контракта (до / после / инвариантные условия) метода перед началом
2. TDD
3. 1 и 2 вместе (написание тестов для выполнения контракта)

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

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

Если вы пишете COBOL или C, псевдокод может быть полезен, потому что написание реального кода займет намного больше времени, и если вы сможете проверить свой алгоритм / требования из псевдокода, вы можете сэкономить некоторое время.

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

Единственный раз, когда я использовал псевдокод за последние 10 лет, это интервью, когда мы работаем над доской, а конкретный язык не имеет значения.

Это, безусловно, полезно для обсуждения процесса / алгоритма в свободной форме, не увязая в синтаксисе. Например, написание класса C ++, который имеет свойства C #, просто чтобы проиллюстрировать это.

Он имеет свое место, но должен использоваться только там, где это необходимо (это работа, которую вы выбросите), и, конечно, не является частью формального процесса, если у вас нет стандартов типа ISO, которые настаивают на этом.

Для меня и людей, с которыми я работал последние несколько лет, псевдокод в значительной степени превратился в не совсем идеальный реальный код. если вы не работаете со многими языками одновременно, большинство людей, кажется, начинают думать в общем порядке своего основного языка. Я какое-то время работал в магазинах .net, поэтому большинство людей, пишущих на доске, в офисе выглядят как vb или c #, а некоторые знаки препинания отсутствуют.

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

Все больше и больше псевдокод пишется графически с помощью таких инструментов, как UML. Например, попробуйте yUML .

онлайн-инструмент для создания и публикации простых UML-диаграмм. Это позволяет вам действительно легко:

• Встраивайте UML-диаграммы в блоги, электронные письма и вики.
• Опубликовать UML-диаграммы в форумах и комментариях к блогам.
• Используйте непосредственно в своем веб-инструменте отслеживания ошибок.
• Скопируйте и вставьте UML-диаграммы в документы MS Word и презентации Powerpoint ...

... yUML экономит ваше время. Он предназначен для тех, кто любит создавать небольшие UML-диаграммы и эскизы.

Без yUML создание диаграммы UML может включать в себя загрузку инструмента UML, создание диаграммы, присвоение ей имени, управление макетом, экспорт ее в растровое изображение, а затем ее загрузку где-нибудь в Интернете. yUML не заставляет вас делать это ...

Отличная работа. Вы начали хорошую дискуссию. Что касается меня, я писал псевдокоды, когда изучал программирование, чтобы понимать различные циклы и алгоритмы. Это было более полутора десятилетий назад. В те дни даже языки программирования были не очень мощными ... и программирование на основе событий было будущим. Теперь с 4GL и 5GL мы думаем на самом языке, а не на простом английском. Когда мы думаем о проблеме, мы думаем с точки зрения объектов и операций. И пока это не сложный алгоритм, написание псевдокодов (или PSEU-DO-Codes, просто шутка) не имеет никакого смысла. Лучше представить решение в графическом виде.

Зависит от используемого языка и вашего знакомства с ним.

Многие современные языки, такие как Python или Java, уже настолько близки к псевдокоду, что написание какого-то специального псевдокода сначала бесполезно, ИМХО. Лучше просто сделайте это прямо сейчас, используя подход трассирующей пули .

Это совсем другое дело, если вы делаете какие-то вещи низкого уровня, близкие к металлическим, или вам еще не нравится язык, который вы используете. Тогда псевдокод определенно может быть полезен.

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

1. Когда код будет более контрпродуктивным для реального понимания того, что произойдет, чем будет псевдокод. Например, SAS займет половину доски, выполняя некоторые довольно простые задачи программирования. Смотрите также C, который обсуждали некоторые другие постеры.
2. С большим количеством анализа данных и статистического кодирования, как правило, есть много поворотов с кодом, поскольку результаты генерируются. Псевдокод несколько проще в использовании, так как «здесь описывается процесс перемотки назад, если диагностический график выглядит неправильно, попробуйте X».
3. Студенты изучают много разных языков программирования. Например, среди людей, которых я знаю, проблема статистики может быть проанализирована в SAS, R или Stata. То, что требует чего-то более близкого к традиционному программированию, может быть сделано в R, Matlab, C, C ++, Java, Python ... это действительно зависит от того, какой конкретный студент реализует программу и для какой цели. Но для Java-людей, Python-людей и Matlab-прежнему полезно иметь общее представление о том, что делают другие, и как работает подход , а не сам код.

Это не вопрос да / нет. Скорее нужно задаться вопросом, когда использовать псевдокод. Важно понять проблему, прежде чем разрабатывать решение, и важно иметь четкое представление о решении до его реализации. Псевдокод может быть использован на любом из этих шагов:

1. При определении проблемы часто записывают варианты использования, иногда используя последовательности действий.
2. При разработке решения. Диаграммы классов хороши, но они описывают только «статическую» часть, то есть данные. Для динамической части, как только вам нужно разобраться с циклом и нетривиальными данными, я считаю псевдокод наилучшим доступным методом. Графические альтернативы включают конечные автоматы (хорошо для сложного потока управления с небольшим объемом данных) и диаграммы потоков данных (хорошо для простых потоков со сложными данными).
3. При реализации решения (или только до). Некоторые языки программирования трудно читать (думать, собирать). В этом случае может быть полезным альтернативное представление. Если вы не знакомы с языками, это тоже стоит делать.

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

В дополнение к достижению понимания, псевдокод также хорош для общения.

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