Чи варто використовувати псевдокод перед фактичним кодуванням?

Псевдокод допомагає нам розуміти завдання мовно-агностично. Чи є найкращою практикою чи запропонованим підходом створення псевдокоду частиною життєвого циклу розробки? Наприклад:

• Визначте і розділіть завдання кодування
• Напишіть псевдокод
• Отримайте схвалення [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-коди, просто жартуючи) не має сенсу. Краще, представляйте рішення графічно.

Залежить від мови, якою ви користуєтесь, та вашої ознайомленості з нею.

Багато сучасних мов, таких як Python або Java, вже настільки близькі до псевдокоду, що написання деяких спеціальних псевдокодів спочатку марно, IMHO. Краще просто зробіть це відразу, використовуючи підхід tracer bullet .

Інша справа, якщо ви робите якісь низькі рівні, близькі до металевих речей або ще не зручні з мовою, якою ви користуєтесь. Тоді псевдокод, безумовно, може бути корисним.

Як правило, є кілька обставин, коли псевдокод має тенденцію до розриву в моїй роботі, що є в академічних закладах, де програмування має тенденцію звикнути як інструмент або "і тепер ми вирішуємо це", заповнюючи середину проекту:

1. Коли код стане більш контрпродуктивним для фактичного розуміння того, що буде, ніж псевдокод. Наприклад, SAS займе половину дошки, виконуючи деякі досить основні завдання програмування. Дивіться також С, про які йшлося в деяких інших афішах.
2. З великим аналізом даних та кодуванням статистики, як правило, виникає велика хитрість із кодом. Псевдокод дещо простіше використовувати для "тут лежить зворотній процес, якщо діагностичний графік не виглядає правильно, спробуйте X".
3. Студенти вивчають багато різних мов програмування. Наприклад, серед людей, яких я знаю, проблема зі статистикою може бути проаналізована в SAS, R або Stata. Щось, що вимагає чогось ближчого до традиційного програмування, можна зробити в R, Matlab, C, C ++, Java, Python ... це дійсно залежить від того, який конкретний студент реалізує програму та з якою метою. Але людям Java та людям Python та Matlab все ще корисно мати спільне уявлення про те, що роблять інші, і як працює підхід , а не сам код.

Це питання не так / ні. Швидше варто задуматися, коли використовувати псевдо-код. Важливо зрозуміти проблему перед розробкою рішення, і важливо мати чітке уявлення про рішення, перш ніж його реалізувати. Псевдо-код можна використовувати на будь-якому з наступних етапів:

1. Визначаючи проблему, звичайно записувати випадки використання, іноді використовуючи послідовності дій.
2. При проектуванні рішення. Діаграми класів приємні, але вони описують лише "статичну" частину, тобто дані. Що стосується динамічної частини, як тільки вам потрібно мати справу з циклом і нетривіальними даними, я вважаю псевдо-код найкращим методом. Графічні альтернативи включають стан машини (добре для складного потоку управління з невеликою кількістю даних) та діаграми потоку даних (хороші для простих потоків зі складними даними).
3. При реалізації рішення (або безпосередньо перед цим). Деякі мови програмування важко читати (думати, збирати). Альтернативне представлення може бути цінним у цьому випадку. Якщо ви не знайомі з мовами, це теж варто зробити.

Також використовується псевдо-код, який фактично є правильним кодом мовою високого рівня, зазвичай його називають прототипуванням.

Крім досягнення розуміння, псевдо-код також хороший для спілкування.

Якщо вам цікаво, чи слід регулярно використовувати псевдо-код, я особисто проти всіх жорстких правил. Це може легко перетворитися на нудну марну часу, якщо його використовувати для тривіальних проблем, які розуміють усі в колективі. Використання псевдо-коду для специфікацій, які ви підтримуєте протягом життя проекту, також може бути дорогим і мало цінувати.