プログラマーの開発段階

インディー ゲーム開発者の Erik Rydeman は、プログラマーの開発の典型的な段階のリストを特定しました。

• コピペスター/完全にグリーンな初心者: オンラインで見つけたコード例をまとめようとしています。それが何をどのように機能させるかについて、非常に漠然としたアイデアを持っています。
• 独立初心者: マトリックスを見てみよう! 実は片目の隅にそれが見えていたのですが、まだそのことに気づいておらず、力を覚えたから今は大したことないと本気で妄想しているのです（ふふ）。例を見ずに単純なコードと複雑なコードを書くことができる。仕事の結果が期待どおりに機能すると、彼は非常に満足します。
• デザインパターンを詳しく見てみましょう。彼はすでに母国語の構文をマスターしており、現在はベスト プラクティスを検討しています。彼はデザインパターンの研究を始めるが、前段階で彼に降り注いだ全能感は秋霧のように溶けていく。再び私たちの前に、絶望的に緑で永遠に疑念を抱く新参者がいます...
• デザインパターン愛好家。彼の意識は「理想のコード」という考えとともに生きています。愛好家は、達成不可能な理想に近づき、既存のパターンにできる限り適合するように、独自のコードを構築しようとします。今では、彼が書いたコードを扱うのがずっと楽しくなりました。
• 建築の狂信者: それは誰にでも起こります。しかし、プログラマーの中には、ベスト プラクティスを熱心に研究するあまり、経験豊富な宗教狂信者ですら羨むような熱意を持ってベスト プラクティスを擁護しようとする人もいます。そして、後者のように、周囲の誰もが自分の視点を受け入れるか、自分の視野から離れるまで、落ち着きません。場合によっては、この段階で生産性が低下することがありますが、それはすべて間違った決定が行われたことが原因です (理論を信頼しすぎ、実践で確認されていないため)。
• 経験豊富な建築家。積み重ねてきた経験が実を結び始めています。「建築家」は、実際に何が起こっているのか、そしてそれに対して何をすべきかを本能的に知っています。この段階で、プログラマは厳格な教義から遠ざかり始め、彼の主なフレーズは「状況次第」（「何でも起こり得る」）になります。難しい決断はもはや彼の趣味ではありません。
• 禁欲的なミニマリスト。質問: コードを構造化する最良の方法は何ですか? 修行者の答えは、可能な限り最も単純なものです。現在、彼は実際の結果よりも理論的な工学的開発に興味を持っていますが、結果的に良いことが判明する解決策を見つけて、最初の試行でそれを実行することはかなり可能です。苦行者の経験が役に立ちます。

あなたはどの段階にいますか?