実際のコーディングの前に擬似コードを使用する必要がありますか？

擬似コードは、言語に依存しない方法でタスクを理解するのに役立ちます。開発ライフサイクルの一部として擬似コードを作成することは、ベストプラクティスですか、または推奨されるアプローチですか？例えば：

• コーディングタスクの特定と分割
• 擬似コードを書く
• [PLまたはTLによる]承認を得る
• 擬似コードに基づいてコーディングを開始する

これは推奨されるアプローチですか？業界で実践されていますか？

コーディングの前に擬似コードを書くことは、計画せずにコーディングするよりも確かに優れていますが、ベストプラクティスとはほど遠いものです。テスト駆動開発は改善です。

さらに良いのは、クリーンルーム、RUP、リーン、かんばん、アジャイルなどの方法論で採用されているように、ユーザーストーリー、ユースケース、CRCカード、ダイアグラムなどの手法を使用して、問題ドメインを分析し、ソリューションを設計することです。

問題の性質とソリューションの実装に使用するコンポーネントを完全に理解することが、ベストプラクティスの背後にある原則です。

私は、コードを書く前にコメントを書くという点で、コメントを一種の非常に高レベルの擬似コードとして使用します。高レベルであっても、問題全体を考えることでコードが大幅に改善されることがわかりました。

いいえ、最初に擬似コードをしないでください

これはオーバーヘッドが大きすぎます。あなたは、メリットをまったく持たずにロジックを記述する作業を行っています。代わりに次のいずれかをお勧めします。

1. 一緒に出荷する言語のプロトタイプ（別名、1つを捨てて書きます）
2. 前提条件/主要な設計をテストするためのコードスニペット付きのアーキテクチャ図
3. 最初にインターフェイス/コード構造を記述し、次にテストを実行し、次にコードを実装するテスト駆動開発。

これら3つはすべて、擬似コードとは異なり、ソリューションに直接移動します。個人的には、チームの規模に応じてテクニック1または2を使用する傾向があります。小規模な（5人以下の）チームの場合、プロトタイピングは非常にうまく機能します。複数の開発者グループが並行して作業している大規模なチームの場合、テクニック2によって早期に作成されたドキュメントが適切に機能することがわかりました。TDDも非常にうまく機能すると確信していますが、このプロセスに取り組んできたチームにまだ取り組んでいません。

私の意見では、擬似コードには2つの有効な目的しかありません。

（1）モジュール性とアルゴリズムの概念を学ぶ必要があるが、まだプログラミング言語に堪能でないプログラミング学生向け。

（2）何かがどのように機能するかを非技術者に伝えるため、またはホワイトボード型の会議での便宜のためだけに。

擬似コードは推奨されるアプローチですか？初心者のプログラマーの場合、はいと言います。新しいプログラマーは、言語の正確な構文を心配することなく、問題をコードに変換する方法を学ぶのに役立ちます。これにより思考プロセスが形作られ、有用な習慣を根付かせることができます（そして悪い習慣もあると思います）。これが学校で多く使用されている理由です。

業界で実践されていますか？私の経験では、いいえ。ドキュメンテーション（要件、仕様、ストーリーボード、ユースケースなど、使用するもの）と実際のコードとの間でプロジェクトを荒らす時間はありません。一般に、青信号がコーディングされる前に、十分な思考がすでに問題に置かれていると想定されています。その時点で、プロジェクトのコーディングは、設計準備のレイヤーをもう1つ追加するよりも重要です。

私は間違いなく擬似コードをお勧めします。これは、何をしようとしているのかを明確にし、忘れたり潜在的な問題があるかもしれない項目を特定するのに役立ちます。コードの大部分をコーディングするまで待つのではなく、計画段階にあるコードを修正する方がはるかに簡単/高速です。

擬似コードは、言語に不慣れな場合や、メンタルコンテキストを変更する必要がある場合に役立ちます。まれに私が擬似コードを書くのは、紙の上です。キーボードから手を離し、紙に落書きするだけで精神障害を回避できる場合があります。

しかし、開発プロセスの正式な部分として？とんでもない。これは、個人にとっては散発的に役立つツールです。「書く前に何を書いているかを知る」より良い方法があります。例えば：

1. 開始する前にメソッドのコントラクト（事前/事後/不変条件）を定義する
2. TDD
3. 1と2を組み合わせた（テストを作成して契約を実行する）

また、コードの記述を開始する前に何らかの承認を取得することは、価値があるよりもはるかに面倒になる可能性があることをお勧めします。設計レビュー（実装前）は有用ですが、個々のアルゴリズムよりも高いレベルにする必要があります。

これまでの答えには同意せず、ノーと言いますが、警告があります：発生する問題に対処するためにコードをリファクタリングすることに熱心に専念している場合にのみ、擬似コードを取り除くことができます。Psuedocodeは、本質的に、コードを定義する前にコードを定義する方法です。それは多くの状況で不必要な抽象化であり、あなたのコードが初めて完璧になることは決してないので（そしておそらく、psuedocodeの設計に従って完成しない）、それは私には無関係のようです。

COBOLまたはCを記述している場合、実際のコードの記述には非常に長い時間がかかるため、疑似コードが役立つ場合があります。また、疑似コードからアルゴリズム/要件を検証できれば、時間を節約できます。

より現代的な言語では、擬似コードはあまり意味がありません。うまくいくのは、メソッドスタブを作成し、最上位のロジックに記入し、アルゴリズムと要件を検証するために必要なだけ詳細を記入することです。これらはすべて実際のコードで行います。その後、そのコードをチームリーダーに見せて承認を求め、実際のコードを既に開始することができます。

過去10年間に擬似コードを使用したのは、ホワイトボードで作業しているときのインタビューで、特定の言語は関係ありません。

構文にとらわれずに、疎い用語でプロセス/アルゴリズムを話すのに確かに役立ちます。たとえば、ポイントを説明するために、C＃プロパティを持つC ++クラスを作成します。

それは場所を持っていますが、必要な場合にのみ使用する必要があります（捨てる作業です）、それを主張するISOタイプの標準がない限り、確かに正式なプロセスの一部ではありません。

私自身と私がここ数年一緒に仕事をしてきた人々にとって、疑似コードは完全に完全ではない実際のコードに変わりました。同時に多くの言語で作業しない限り、ほとんどの人は主言語の一般的なパターンで考え始めるようです。私はしばらくの間.netショップで働いてきたので、オフィスの周りのほとんどの人のホワイトボードの落書きは、句読点の一部が欠けているvbまたはc＃のように見える傾向があります。

この演習は、オプションなどを議論する際にまだ価値がありますが、言語にとらわれないビットは、いくつかの言語でより多くの時間を費やすにつれて離れる傾向があります。

ますます、擬似コードはUMLなどのツールを使用してグラフィカルに記述されます。たとえば、yUMLを試してください。

シンプルなUMLダイアグラムを作成および公開するためのオンラインツール。次のことが非常に簡単になります。

• UML図をブログ、メール、ウィキに埋め込みます。
• フォーラムやブログのコメントにUML図を投稿してください。
• Webベースのバグ追跡ツール内で直接使用します。
• UML図をコピーして、MS Word文書とPowerPointプレゼンテーションに貼り付けます...

... yUMLは時間を節約します。小さなUML図やスケッチを作成したい人向けに設計されています。

yUMLを使用しない場合、UMLダイアグラムの作成には、UMLツールのロード、ダイアグラムの作成、名前の付け、レイアウトの操作、ビットマップへのエクスポート、オンラインでのアップロードが含まれます。yUMLはあなたにそれをさせません...

すごい仕事。良い議論を始めました。私のように、私はさまざまなループとアルゴリズムを理解するためにプログラミングを学んでいたときに擬似コードを書いていました。これは1年半前のことです。その日は、プログラミング言語でさえそれほど強力ではありませんでした...そしてイベント駆動型プログラミングは未来でした。現在、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. ソリューションを実装するとき（またはその直前）。一部のプログラミング言語は読みにくい（思考、アセンブリ）。この場合、別の表現が役立つことがあります。言語に慣れていない場合は、行う価値もあります。

高級言語で実際に適切なコードである擬似コードも使用されます。これは通常、プロトタイピングと呼ばれます。

理解を達成することに加えて、擬似コードはコミュニケーションにも適しています。

擬似コードを定期的に使用すべきかどうか疑問に思っているなら、私は個人的にあらゆる種類の厳格なルールに反対しています。チームの誰もが理解している些細な問題にこれを使用すると、これは退屈な時間の無駄に簡単に変わります。プロジェクトの全期間を通じて維持する仕様に擬似コードを使用することも、コストがかかり、ほとんど価値がありません。