複雑なものにアプローチする方法は？

Question

プロジェクトに不可欠なコードの特定の部分を知っていますが、おそらくそれを成し遂げるのに多くの時間がかかりますか？他の何か（おそらく重要度が低い）に取り組むか、その部分に取り組むのではなく、まったくコードを書きたくないという気持ちになりますか？あなたが知っているすべての怠zyなトリックを避けて使用して、必然的な実装を遅らせるためにあなたは一生懸命努力しているその獣？

今、私はたぶん怠けているだけかもしれませんが、私はいつもそのようなコードに対処しなければなりませんでした。私が書く気にならない何かを書いてください（そして、あなたが楽しみのためにそれをしていて、支払いを受けないならば、それはより悪いです！）。有用な結果や動作の兆候を取り戻す段階に至るまでに時間がかかる大規模なシステム。そのようなものをどのようにコーディングし始めますか？ほとんどの人は、おそらく分割して征服し、同様のアーキテクチャ手法を提案するでしょうが、これはあなたがそれをどのように行うかについてではありません。それはあなたが自分でそれを始める方法についてです。あなたがとる最初のステップは何ですか？

Answer 1

これが私に起こった事例の話をします。

フォワードダイナミックプログラミング（Viterbiアルゴリズム）を使用したx264用の新しいフレームタイプ決定アルゴリズムを実装したかった。しかし、それは複雑で、面倒で、いなどになるでしょう。そして、私は本当にそれをやりたくありませんでした。 Google Summer of Codeにプロジェクトを投入しようとしましたが、何らかのひどい不運から、彼のプロジェクトで単に保釈された学生は...そのプロジェクトを選んだ学生でした。

それで、2か月間不平を言ってそれをかわした後、私はついにアルゴリズムに取り掛かりました。そして、ここに私がそれをした方法があります。

最初に、他の開発者と話をしました。開発者は、どうやってそれを行うかのアイデアをすでに持っていたようです。私たちはそれについて話し合い、アルゴリズムの観点からプロセスを完全に理解するまで、彼はそれを私に説明しました。これは、このようなプロジェクトの最初のステップです。その背後にあるアルゴリズムを十分に理解して、全体を疑似コード化できます。

その後、私は私の同僚と話をしました。ホワイトボードに行き、彼もそれを理解するまでスケッチしました。他の人に説明することで、私は自分自身を理解しました。これは2番目のステップです。アルゴリズムを他の誰かに説明して、それらが擬似コードを作成できるようにします。プログラミングは「説明」の形式であるため、これはプログラミングプロセスのエミュレーションです。コンピューターへのアルゴリズム。

次に、コスト関数に任意の偽の値を使用し、ビタビ検索のテストにのみ使用されていた単純なJavaプロトタイプを作成しました。私はそれを完成させ、徹底的な検索に対してチェックしました。完全に一致しました。私の動的プログラミングは正しかった。これは3番目のステップです。可能な限り単純な環境で、アルゴリズムのできるだけ単純な形式を記述します。

次に、x264のネイティブ言語であるCに移植しました。再び機能しました。これは4番目のステップです。この単純な形式のアルゴリズムを完全な環境に移植します。

最後に、偽のコスト関数を実際の関数に置き換えました。バグハンティングと修正を行ったところ、うまくいきました。これが最後のステップです。アルゴリズムを環境に完全に統合します。

このプロセスは1週間ほどで完了しましたが、プロジェクトの開始時点での私の観点から見ると、それは完全に困難であり、開始することさえできませんでした。ステッププロセスでは、やるだけでなく a>、しかし、それは私が予想したよりもはるかに速く完了します。

そして、その利点はx264をはるかに超えています。私は今、ビタビを非常に完全に理解しているので、他の人に説明することができます...そしてそれらの人はそれから大いに利益を得ます。たとえば、ffmpeg開発者の1人が、アルゴリズムとコードの適応を使用して、多少異なる問題を最適に解決しています：オーディオファイルの最適なヘッダー配置。

Answer 2

一般的に、大きくて複雑な部分が大好きです。それらは、実際に課題を広げ、私がやっていることを慎重に検討することを強制する部分です。私が嫌いなのは、すべて小さくて退屈な部分です。しかし、私が先延ばしにしてきたことに関しては、1つの簡単なアドバイスが重要だと思います。

JUST DO IT !!!

真剣に、一度開始すると、終了するのがずっと簡単になります。それらを開始するまで物事を先送りしますが、突然、私が始めた今、それは私が想像していたほど悪くはないことを発見し、見て、すでにほぼ完了しています！

Answer 3

分割統治は、コードを構造化することだけでなく、プロジェクトを概念的に管理しやすくするためのアプローチとしても機能します。プロジェクトを開始するのが難しい場合、ほとんどの場合、それは大きくて怖いであるためです。概念的に管理可能な部分に分割することにより、それはそれほど怖くなりません。

＆quot; トレーサーの箇条書き＆quot;実用的なプログラマーによって説明されているように。 削減可能な限り単純な「概念実証」プロジェクトにプロジェクトを縮小します。コアパーツの例、 UI、特殊なケース、エラー処理などがありません。おそらく、いくつかのコアルーチンと関連する単体テストがあります。これで恐ろしい部分を征服し、コアから構築できます。

基本的に（少なくとも私にとって）始めるための秘trickは、プロジェクト全体から始めないことです。 1つの小さな（できればコア）パーツから始めて、そこからビルドします。開始するのがまだ難しい 場合、それは、私が決めた小さな部分がまだ大きいため、それをさらに分割して削減する必要があるためです。

Answer 4

私は、ソフトウェアの多くの重要で重要な部分は書くのが面白くないことに同意します。私は通常、ここで機能を追加したり、バグを修正したりするなど、いくつかの小さなことから開発の日を始めます。時間が来たら、大きな部分から始めますが、それ以上物が見えなくなったら、別のことをします。それでもすべてを時間通りに完了できれば、それで十分です。そして、あなたがそれをしている間、そしてあなたがしている間、そしてあなたがそれをしている前に、あなたがそれをしている前にその大きな獣について他の人と話すならば、それは物事をより簡単にするかもしれないことを覚えておいてください。これはあなたの心を解放するだけでなく、より主観的な観点から他の人の意見を得るでしょう。そのようなことを一緒に計画することも役立ちます。

Answer 5

おかしい、私は反対です。問題への取り組みを開始するとき、最初に大きな問題に取り組みます。通常、問題の核心は私が興味を持っていることです。

自分でプロジェクトを行っている場合、通常、エッジの周りにすべてのファジィビットを実装することに煩わされることはないので、それらは実行されません。実際に何かをしている場合、最終的にはすべてのファジィビットに到達しますが、それは私のお気に入りの部分ではありません。

Answer 6

ここには2つの問題があると思います。

最初は実際に始めています。あなたが言うように、それはかなり注意が必要です。個人的には、紙/画面で何かを得るために、少しだけ始めます。おそらく間違っており、編集が必要になりますが、一般的には、自分の作品であっても、作成するよりも批判する方が簡単です。

次に、難しい問題を解決する実際のプロセスがあります。 「概念ブロックバスティング」という素晴らしい本があります。問題にアプローチするさまざまな方法を説明しています。私はその本を使って問題解決と盲点にどのようにアプローチするかについて多くを学びました。強くお勧めします。

Answer 7

システムがやろうとしていることの隠metaを確立しようとしています。メタファーの観点から振る舞いを説明できると、いつもより快適に感じることができます。

次に、テスト駆動開発の観点からアプローチします。つまり、正しい動作を検証するテストを設定して、システムが実行する必要があることを説明し始めます。

HTH。

歓声、

ロブ

Answer 8

プロジェクトの最も難しい部分は、最初の行まで何もしないことです。紙の上に何かを置くだけで、このプロセスが開始され、残りがここからどれだけ速く流れるかが驚くべきことです。

私は＆quot; 分割して征服する＆quot;タイプのアプローチが好きです私自身。

システムに特定の大きなタスクがぶら下がっている場合、コンピューターを離れてペンと紙を取り出し、そのタスクをすべての論理コンポーネントとワークフローに分解します。

これらの各タスクを実行し、必要な最も基本的な関数/呼び出しに分解します。

これで、必要なスタブメソッドを追加できます。そしてそれらを一つずつ肉付けします。この時点で、これらの「サブタスク」はそれぞれ同じプロジェクトを周回する小さな開発タスクよりも大きくないので、はるかに面倒なタスクが私にかかっているように感じます。

Answer 9

私は通常、家でペンと紙を使ってこの種の問題に取り組んでいます。アルゴリズムや論理フローを想像してから、クラスとメソッドのスタブをスタブ（紙上で）スタブします。コンピュータの前でもっと簡単にできる...おそらく私だけだろう。