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

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/12683

  •  16-10-2019
  •  | 
  •  

Вопрос

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

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

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

Это было полезно?

Решение

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

Еще лучше проанализировать задачу и дизайнерские решения с использованием таких методов, как пользовательские истории, варианты использования, карты CRC, диаграммы, как это поддерживается методологиями, такими как чистая комната, Rup, Lean, Kanban, Agile и т. Д.

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

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для меня и людей, с которыми я работал в течение последних нескольких лет, Псевдокод в значительной степени превратился в не совсем идеальный настоящий код. Если вы не работаете со многими языками одновременно, большинство людей, похоже, начинают думать в общем образце своего основного языка. Я некоторое время работал в магазинах .NET, поэтому большинство людей пробежают доску вокруг офиса, как правило, выглядят как VB или C#, а некоторые пунктуации отсутствуют.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
scroll top