Псевдокод помогает нам понимать задачи в не зависящей от языка манере. Является ли наилучшей практикой или предложенным подходом создание псевдокода в качестве части жизненного цикла разработки? Например:
- Определить и разделить задачи кодирования
- Написать псевдокод
- Получите одобрение [по PL или TL]
- Начать кодирование на основе псевдокода
Это предлагаемый подход? Это практикуется в отрасли?
design
pseudocode
Vimal Raj
источник
источник
Ответы:
Написание псевдокода перед кодированием, безусловно, лучше, чем просто кодирование без планирования, но это далеко не лучшая практика. Разработка через тестирование - это улучшение.
Еще лучше проанализировать предметную область и разработать решения с использованием таких методов, как пользовательские истории, сценарии использования, карты CRC, создание диаграмм в соответствии с такими методологиями, как Cleanroom, RUP, Lean, Kanban, Agile и т. Д.
Тщательное понимание природы проблемы и компонентов, которые вы используете для реализации решения, является принципом, лежащим в основе передового опыта.
источник
Я использую комментарии как своего рода псевдокод очень высокого уровня, в котором я пишу комментарии перед тем, как писать код. Я считаю, что продумывание всей проблемы, даже на высоком уровне, значительно улучшает мой код.
источник
Нет, сначала не псевдокод
Это слишком много накладных расходов. Вы делаете работу по написанию логики без каких-либо преимуществ. Вместо этого я бы предложил любое из следующего:
Все три из них направляют вас прямо к вашему решению, в отличие от псевдокода. Лично я склонен использовать техники 1 или 2 в зависимости от размера команды. Для небольших команд (например, 5 человек или меньше) прототипирование работает очень хорошо. Для более крупных команд, в которых несколько групп разработчиков работают параллельно, я обнаружил, что документация, подготовленная на раннем этапе с помощью метода 2, работает хорошо, потому что она дает вам кое-что для обсуждения на ранней стадии и помогает вам лучше определять границы компонентов. Я уверен, что TDD будет работать очень хорошо, но мне еще предстоит работать в команде, которая посвятила себя этому процессу.
источник
На мой взгляд, псевдокод имеет только две допустимые цели:
(1) Для программистов, которые должны изучать понятия модульности и алгоритмов, но еще не владеют языком программирования.
(2) Рассказать, как что-то будет работать нетехническому человеку или просто ради целесообразности на собрании типа доски.
источник
Является ли псевдокод предложенным подходом? Для начинающих программистов я говорю да. Это помогает новому программисту научиться переводить проблему в код, не беспокоясь о точном синтаксисе языка. Это формирует мыслительный процесс и может помочь привить полезные привычки (и я предполагаю, что вредные привычки тоже). Вот почему он так часто используется в школах.
Это практикуется в промышленности? По моему опыту нет. Ни у кого нет времени, чтобы набросать проект между документацией (требованиями, спецификациями, раскадровками, вариантами использования или чем-то еще, что они используют) и фактическим кодом. Как правило, предполагается, что достаточное количество раздумий было решено до появления зеленого кода для кодирования. На этом этапе кодирование проекта важнее, чем добавление еще одного уровня подготовки дизайна.
источник
Я определенно рекомендую псевдокод. Это поможет вам уточнить, что вы собираетесь делать, и определить элементы, которые вы, возможно, забыли, или потенциальные проблемы. Гораздо проще / быстрее исправить ваш код, когда он все еще находится на стадии планирования, а не ждать, пока вы уже закодировали большую его часть.
источник
Псевдокод может быть полезен, если вы не знакомы с языком или если вам нужно изменить ментальный контекст. В редких случаях, когда я пишу псевдокод, это на бумаге. Иногда просто сняв руки с клавиатуры и набросав на бумаге, можно обойти умственный блок.
Но как формализованная часть процесса разработки? Ни за что. Это спорадически полезный инструмент для людей. Есть лучшие способы «узнать, что вы пишете, прежде чем писать», например:
Я бы также предположил, что получение какого-либо одобрения до того, как вы начнете писать код, может вызвать гораздо больше хлопот, чем оно того стоит. Проектные обзоры (предварительная реализация) могут быть полезны, но они должны быть на более высоком уровне, чем отдельные алгоритмы.
источник
Я собираюсь не согласиться с предыдущими ответами и сказать «нет», но с оговоркой: вы можете избавиться от psuedocode, только если вы лихорадочно посвятите себя рефакторингу своего кода для решения возникающих проблем. Psuedocode по своей сути является способом определения вашего кода до того, как вы определите свой код; это ненужная абстракция во многих обстоятельствах, и, поскольку ваш код никогда не будет совершенен в первый раз (и, вероятно, не будет следовать дизайну psuedocode до конца), он кажется мне посторонним.
источник
Если вы пишете COBOL или C, псевдокод может быть полезен, потому что написание реального кода займет намного больше времени, и если вы сможете проверить свой алгоритм / требования из псевдокода, вы можете сэкономить некоторое время.
В более современных языках псевдокод не имеет такого большого смысла. Лучше всего было бы написать заглушки методов и заполнить логику верхнего уровня, а также как можно больше подробностей, чтобы проверить алгоритм и требования, и все это в реальном коде. Затем вы можете показать этот код руководителю группы для утверждения, и ваш реальный код уже запущен.
источник
Единственный раз, когда я использовал псевдокод за последние 10 лет, это интервью, когда мы работаем над доской, а конкретный язык не имеет значения.
Это, безусловно, полезно для обсуждения процесса / алгоритма в свободной форме, не увязая в синтаксисе. Например, написание класса C ++, который имеет свойства C #, просто чтобы проиллюстрировать это.
Он имеет свое место, но должен использоваться только там, где это необходимо (это работа, которую вы выбросите), и, конечно, не является частью формального процесса, если у вас нет стандартов типа ISO, которые настаивают на этом.
источник
Для меня и людей, с которыми я работал последние несколько лет, псевдокод в значительной степени превратился в не совсем идеальный реальный код. если вы не работаете со многими языками одновременно, большинство людей, кажется, начинают думать в общем порядке своего основного языка. Я какое-то время работал в магазинах .net, поэтому большинство людей, пишущих на доске, в офисе выглядят как vb или c #, а некоторые знаки препинания отсутствуют.
Это упражнение по-прежнему полезно при обсуждении вариантов и тому подобного, но языковая независимость имеет тенденцию уходить, поскольку вы проводите больше времени с несколькими языками.
источник
Все больше и больше псевдокод пишется графически с помощью таких инструментов, как UML. Например, попробуйте yUML .
источник
Отличная работа. Вы начали хорошую дискуссию. Что касается меня, я писал псевдокоды, когда изучал программирование, чтобы понимать различные циклы и алгоритмы. Это было более полутора десятилетий назад. В те дни даже языки программирования были не очень мощными ... и программирование на основе событий было будущим. Теперь с 4GL и 5GL мы думаем на самом языке, а не на простом английском. Когда мы думаем о проблеме, мы думаем с точки зрения объектов и операций. И пока это не сложный алгоритм, написание псевдокодов (или PSEU-DO-Codes, просто шутка) не имеет никакого смысла. Лучше представить решение в графическом виде.
источник
Зависит от используемого языка и вашего знакомства с ним.
Многие современные языки, такие как Python или Java, уже настолько близки к псевдокоду, что написание какого-то специального псевдокода сначала бесполезно, ИМХО. Лучше просто сделайте это прямо сейчас, используя подход трассирующей пули .
Это совсем другое дело, если вы делаете какие-то вещи низкого уровня, близкие к металлическим, или вам еще не нравится язык, который вы используете. Тогда псевдокод определенно может быть полезен.
источник
В моей работе, как правило, возникает пара обстоятельств, когда псевдокод имеет тенденцию ломаться, то есть в академических кругах, где программирование имеет тенденцию использоваться как инструмент или «и теперь мы решаем это», заполняясь в середине проекта:
источник
Это не вопрос да / нет. Скорее нужно задаться вопросом, когда использовать псевдокод. Важно понять проблему, прежде чем разрабатывать решение, и важно иметь четкое представление о решении до его реализации. Псевдокод может быть использован на любом из этих шагов:
Псевдокод, который на самом деле является правильным кодом на языке высокого уровня, также используется, его обычно называют прототипированием.
В дополнение к достижению понимания, псевдокод также хорош для общения.
Если вам интересно, следует ли вам использовать псевдокод на регулярной основе, я лично против всех видов жестких правил. Это может легко превратиться в скучную трату времени, если ее использовать для простых задач, которые понимают все в команде. Использование псевдокода для спецификаций, которые вы поддерживаете на протяжении всей жизни проекта, также может быть дорогостоящим и иметь небольшую ценность.
источник