プロジェクトに不可欠なコードの特定の部分を知っていますが、それを完了するにはおそらく多くの時間がかかりますか? その部分に取り組む代わりに、他の何か (おそらくそれほど重要ではない) に取り組みたい、またはコーディングをまったくしたくないと感じたことはありますか? あなたが避けようとする獣を、あなたが知っているすべての怠惰なトリックを使用して、その避けられない実装を遅らせようとしていますか？
さて、私は怠惰なだけかもしれませんが、常にそのようなコードを処理しなければなりませんでした。書きたくないことを書いてください (そして、楽しみのために書いていて、お金をもらっていないのであれば、さらに悪いことです!)。有用な結果や動作の兆候が得られる段階に移行するのに多くの時間がかかる大規模なシステム。どうやってそのようなコーディングを始めますか? ほとんどの人は、おそらく分割統治法や同様のアーキテクチャ手法を提案するでしょうが、これはあなたがそれをどのように行うかではありません。それはあなたがそれをやり始める方法についてです。あなたがとる一番最初のステップは何ですか？
これが私に起こったケースの話をします。
私は、順方向動的計画法 (Viterbi アルゴリズム) を使用する x264 用の新しいフレームタイプ決定アルゴリズムを実装したいと考えていました。しかし、それは複雑で、厄介で、醜いものになるでしょう。そして、私は本当にそれをしたくありませんでした。私はプロジェクトを Google Summer of Code にポーンオフしようとしましたが、ある種のひどい不運のために、私たちが持っていた 1 人の学生が彼のプロジェクトを単に救済しました... そのプロジェクトを選んだ学生でした.
それで、それについて不平を言い、それをかわす2か月後、私はついにアルゴリズムに取り掛かるようになりました. そして、これが私がそれをした方法です。
最初に、私は他の開発者と話をしました。どうやらそれを行う方法についてすでにいくつかのアイデアを持っていたようです。私たちはそれについて話し合い、アルゴリズムの観点からプロセスを完全に理解するまで、彼は私に説明してくれました。これは、そのようなプロジェクトの最初のステップです。その背後にあるアルゴリズムをよく理解して、全体を疑似コード化できるようにします。
それから、私は私の別の同僚と話しました。私たちはホワイトボードに近づき、彼もそれを理解するまでスケッチしました. 誰かに説明することで、自分自身を理解することができました。これが 2 番目のステップです。他の人にアルゴリズムを説明して、疑似コードを作成できるようにします。これは、プログラミング プロセスのエミュレーションです。プログラミングは、アルゴリズムをコンピューターに「説明する」形式であるためです。
次に、コスト関数に任意の偽の値を使用し、Viterbi 検索をテストするためだけに使用される単純な Java プロトタイプを作成しました。私はそれを完成させ、徹底的な検索に照らしてチェックしました - それは完全に一致しました. 私の動的計画法は正しかった。これが 3 番目のステップです。可能な限り単純な環境で、可能な限り単純な形式のアルゴリズムを記述します。
次に、x264 のネイティブ言語である C に移植しました。それは再び働いた。これが 4 番目のステップです。単純な形式のアルゴリズムを完全な環境に移植します。
そして最後に、偽のコスト関数を本物のコスト関数に置き換えました。いくつかのバグハンティングと修正の後、それは機能しました。これが最終ステップです。アルゴリズムを環境に完全に統合します。
このプロセスにかかった時間はわずか 1 週間でしたが、プロジェクトを開始したときの私から見ると、非常に困難で、始めることさえできませんでした。やり遂げただけでなく、思っていたよりもずっと早くやり遂げることができました。
そのメリットは x264 をはるかに超えていました。私は今、ビタビを完全に理解しているので、他の人に説明することができます...そして、他の人はそれから大きな恩恵を受けることができます. たとえば、ffmpeg 開発者の 1 人は、私のアルゴリズムとコードの適応を使用して、多少異なる問題を最適に解決しています: オーディオ ファイルの最適なヘッダー配置です。
一般的に、大きくて複雑な部分が好きです。それらは実際に挑戦を拡張し、私が何をしているのかを慎重に検討するように強制する部分です. 私が嫌いなのは、小さくて退屈なビットです。しかし、私が先延ばしにしてきた何かをすることになると、1 つの簡単なアドバイスが重要だと思います
。
真剣に、それが開始されると、終了するのははるかに簡単です。私はいつも物事を始めるまで後回しにしていることに気づきますが、突然、始めてみて、想像していたほど悪くはなく、ほら、もうほとんど終わっていることに気づきました！
分割統治は、コードを構造化するだけでなく、プロジェクトを概念的に管理しやすくするためのアプローチとしても機能します。プロジェクトを始めるのに苦労するのは、ほとんどの場合、それが大きすぎて怖いからです。概念的に扱いやすい部分に分割することで、怖くなくなります。
また、実用的なプログラマーが説明する「トレーサー弾」も信じています。プロジェクトを、コア部分の可能な限り単純な「概念実証」に縮小します。たとえば、UI、特殊なケース、エラー処理などは除きます。おそらく、関連する単体テストを含むいくつかのコア ルーチンにすぎません。これで怖い部分を克服し、コアから構築することができます。
基本的に、始めるための秘訣は (少なくとも私にとっては)、次のとおりです。プロジェクト全体から始めないでください。1 つの小さな (できればコア) パーツから始めて、そこからビルドします。それでもなかなか始められない場合は、決めた小さい部分がまだ大きいので、分割してさらに減らしていく必要があります。
ソフトウェアの大きくて重要な部分の多くは、書くのが楽しくないというあなたの意見に同意します。私は通常、ここに機能を追加したり、バグを修正したりするなど、いくつかの小さなことから開発日を開始します。時間があるときは大きな部分から始めますが、それが見えなくなったら別のことをします。それでも時間通りにすべてを完了できれば、それで問題ありません。そして、それを行う前、行っている間、および行った後に、その大きな獣について他の人と話すと、物事が楽になるかもしれないことを覚えておいてください. これにより、心が解放されるだけでなく、主観的でない視点から他の人の意見を得ることができます。そのようなことを一緒に計画することも役立ちます。
おかしいな、俺は逆だ。問題に取り組み始めるときは、まず大きな問題に取り組みます。問題の核心は通常、私が興味を持っているものです。
私が自分でプロジェクトを行っている場合、通常、エッジの周りのあいまいなビットをすべて実装するのは面倒なので、決して完了しません。私が実際に何かをしている場合、最終的にはすべてのあいまいな部分に到達しますが、それは私のお気に入りの部分ではありません.
ここには2つの問題があると思います。
まずは実際に始めることです。おっしゃる通り、かなり難しいかもしれません。個人的には、紙やスクリーンで何かを得るために、少しずつ始めます。おそらく間違いであり、編集が必要ですが、一般的に、自分の作品であっても、作成するよりも批判する方が簡単です.
次に、難しい問題を解決する実際のプロセスがあります。問題にアプローチするさまざまな方法について説明している「Conceptual Blockbusting」という素晴らしい本があります。その本を使って、問題解決と盲点へのアプローチ方法について多くのことを学びました。強くお勧めします。
システムがやろうとしていることの比喩を確立しようとします。比喩の観点から行動を説明できると、いつもより快適に感じます。
次に、テスト駆動開発の観点からアプローチします。つまり、正しい動作を検証するテストを設定することによって、システムが何をする必要があるかを説明し始めます。
HTH。
乾杯、
ロブ
私は通常、家でペンと紙を使ってこの種の問題に取り組んでいます。アルゴリズムや論理フローを想像してから (紙に!) クラスとメソッドのスタブをスタブします。 /コンピュータの方がずっと簡単にできます...おそらくそれは私だけです..
プロジェクトの最も困難な部分は、何もしていない状態から最初の行に進むことです。紙に書き出すだけでこのプロセスが開始され、残りがここからどれだけ速く流れるかは驚くべきことです.
私自身、「分割統治」型のアプローチのファンです。
システムに特定の大きなタスクがかかっている場合、私はコンピューターを離れ、ペンと紙を取り、そのタスクをすべての論理コンポーネントとワークフローに分割します。
次に、これらの各タスクを実行し、必要な最も基本的な関数/呼び出しに分解します。
その後、必要になると思われるスタブ メソッドを挿入できます。そして一つ一つ肉付け。この時点で、これらの「サブタスク」のそれぞれは、同じプロジェクトを周回する小さな開発タスクよりも大きくないため、私にかかっている負担の少ないタスクのように感じます.