web-dev-qa-db-ja.com

コードで抽象化を理解するにはどうすればよいですか?

新しいコードベースを見るとき、私はボトムアップのアプローチから始めたいと思います。
1つのファイルを理解してから、次の抽象化に移ります。
しかし、低レベルの抽象化が何をしているか忘れてしまうことがよくあります。

したがって、この時点で、以前完全に理解していたファイルに戻って、それらを再学習しようとするほぼ無限のループに陥っています。私の頭の中で互いにつながっている他の多くの抽象化を両立させようとしている間。

この状況に対処するためのより良い戦略はありますか?

下位レベルの詳細を忘れて、それらを与えられたものとして解釈する必要がありますか?しかし、それでも、現在の抽象化が何をしているかを理解するために、下位レベルの抽象化を以前に理解することが何度も必要です。

15
John DeBord

具体的にプログラミングすることは、ディテールを手前に引くための衝動であり、1か所ですべてを釘付けにすることができます。私たちは皆このように始め、手放すのは難しいです。

抽象的にプログラミングすることは、間違いなく「下位レベルの詳細を忘れる」ことです。時には高レベルの詳細さえ。あなたは詳細を押しのけて、何か他のものにそれらを処理させます。卑劣なことは、これをずっとやってきたことです。画面に表示されるprint "Hello world"とそれの間のすべてがどうなるか本当に理解していますか?

これらの詳細を手放すのに苦労するときに要求する一番のことは良い名前です。良い名前を付けると、中を覗いても驚かないでしょう。これが、printが画面に何かを配置したことに驚かず、実際にその方法を気にしなかった理由です。 foo "Hello world"は別の話でした。

また、抽象化のレベルは一貫している必要があります。円周率を計算するレベルにいる場合は、円周率を表示する方法についても心配する必要はありません。その詳細は、それが属していない抽象化に漏れています。

この1つの場所で私が考えている1つのことではない、より低い、高い、または横向きの詳細は、完全に消えるか、少なくとも良い名前の後ろに隠れることができます。

したがって、ファイルからファイルへのバウンスに本当に苦労している場合は、誰かが悪い名前や漏れやすい抽象化で立ち往生している可能性があります。

私は指で読んでこれを修正します。この混乱について適切なテストを行ったら、責任をばらばらにし、驚きを避けるために明確な名前を付け、他の人に見せて、私がファンタジーの世界に住んでいないことを確認します。

このように機能することになると私だけではないようです:

なじみのないコードに取り組むたびに、メソッドの抽出を開始します。これを行うと、名前を付けることができるコードのチャンクを探し、次に抽出します。後で抽出したメソッドをインライン化しても、少なくとも全体的な構造を確認できるように、一時的に詳細を非表示にする方法があります。

Michael Feathers-Orange Code

31
candied_orange

下部には、これが年の四半期ごとにどのように私にうまくいったかに関するいくつかの更新があります、それらは貴重だと思います。

良いネーミング。または、それが他の誰かのコードである場合は、そのシステムのクラス/関数の悪い名前にも基づいて、良い名前/責任を属性付けして、私の頭の中の感覚。それが行われると、低レベルの実装が覚えやすくなります。

それは私が持っているすべてです。このサイトには多くの純粋主義者がいて、神の誓いによってどんなパターンやどんな種類のオブジェクトでも知っていますが、良いネーミングはあなたを遠くへ連れて行きます。最小限の文書化/適切な名前の付いた、適切に分離されたコードを作成することにより、私は自分でより多くのことを行いました。コードが多くの場所で多くの人々によって使用されたとしても、それは私に噛み付くことはありませんでしたが、私が正しくやったことの1つは、適切な名前、適切なコメント、およびコードのフローを説明する回路図に多くの時間を費やすことでした。私のコードをより深く拡張したいかどうかを理解するには、低レベルの実装が必要です。適切に記述されたコードは妥当な方法で拡張できるため、誰かまたはあなたが低レベルの実装を理解または覚えていなくても問題ありません。

私と同じように私の元の分野の人々が真実であることを知っている少しの論争に興味があれば、ここに書かれていることを聞くと、この答えに同意することと反対することの両方を学ぶでしょう、先を読んでください:


しかし、ここには別の問題があります-純粋主義者。合理的で完全に論理的であり、実際には何の問題もない、よく書かれた答えとイデオロギーを聞くでしょう。しかし、あなたはそれらに従う必要はありません、実際には、彼らはあなたの不利益に影響しているかもしれません。

私の友達は大きなシステムで働いていて、慣習やパターンについて少しばかり気にしすぎている人たちを笑い飛ばしているだけなのですが、私もそうしています-データ分析の主な分野から、これに対する私の推論を見つけることができます。私はそれほど経験豊富な開発者ではないので:あなたが重要だと思うことのほとんどは重要ではなく、この意味であなたのエゴと強い相関関係があります。多くの場合、自分のエゴのために、個人は、彼がただ「私がしたのと同じこと」と言ったと考えている当局によって現在強化されている彼のバイアスのために彼が誤解している可能性が高いという知識を得るでしょう。これは非常によく知られたわなで、決して陥ることはありません。これは、彼がそれを正しくまたはより良い目的で使用していないことを意味するわけではありませんが、多くの場合、これらの人々が行うことは、彼らが言っていることはすべて黄金の賞であることを約束することです。

それで、あなたは何ができますか?

同僚にコードを説明し、高レベルの観点からそれが理にかなっているか尋ねます。

それは重要なことのすべてです。もちろん、他の誰かのコードを読んでいる人は常に特定の事柄の実装を確認するためにalt-tabフィエスタを持っていますが、あなたのコードを読んでいる人があなたのシステムを高度に理解し、「なぜ事が起こるのかを理解しているなら、それは問題ではありません。 "(もう一度、必ずしも知らなくても、完全に"どのように起こるか ")、あなたは黄金です。

これは私が先に行って、パフォーマンスが良くないか、何も尊重しないがらくたコードを書くと言っているのではありませんが、私が言っているのは:

1)忘れても大丈夫です。やがて、使用しているコードをよりよく理解できるようになります。あなたが読んでいるコードが低レベルの実装を良いレベルで知っていることを要求するなら、それはコードがひどく書かれていて、私が前に言ったものに影響します:同僚はあなたを理解していますか?

2)世界は非常に賢くない多くの非常にインテリジェントな人々でいっぱいです。彼らはまたしばしば非常に感情的であり、外部の力からバイアスを強化する傾向があります。彼らは何をするかは非常に得意ですが、情報を広める行為者としての彼らが忘れていることは、「ロジック」に裏付けられているとしても、アイデア/情報は、それらを送信するもののコンテキストを持っているということです。情報はあなたにも役立ちます。あなたにとって意味のあるものは、他の人にとっても意味があるかもしれませんし、彼らはそれを愛するでしょうが、情報は絶対的なものとして解釈されるべきではなく、繰り返しになります。それが一致するかどうかを確認するための独自のコンテキスト。それは億万長者が私たちにこれらの「先を行くための知識のビット」を私たちに与えるのと本当に同じです-彼らが言うことを言うのは確かに簡単ですが、もちろん、これは馬鹿げた例ですが、あなたはアイデアを得ます。

簡単に言うと、理解できるコードを記述し、一部の人が言うように、多くのパターン/クラスと精製所が必要な場合でも、それはまだ議論の余地があることを理解してください。議論の両側には非常に賢い人がいて、それはあなたのチームのために機能するものを合理的な方法で行うという考えを強化するだけです-重要ではない細部にこだわらないでください、あなたはそれらを理解します後で、あなたは非常に競争の激しい世界に住んでいることを覚えておいてください。そこではタイミングが最も重要です。

スタートアップの成功のタイミング。

有意義で貪欲な方法で時間とリソースを割り当てます。


6か月後の編集を次に示します。

それは非常識な旅でした。分離/適切なネーミングとドキュメンテーションだけで基本的に何でもコードベースの内外にプラグインできるとは思いませんでした。新しい変更に対応するために、多くのコードを書き直す必要があり、2〜3日でかなりの量のコードを作成しました。 SOLID知識不足とベストプラクティスのためにどこでも従わなかったと私は安全に言えます。私は彼らが私の技術的負債にあると言えますが、多くはそうではありません。別個に、よく名前を付けてドキュメントを作成すれば、最終的にコードが簡単に変更できるようになります。

私を誤解しないでください。緊密に結合されたコードを作成すると、SOLIDが嫌いかどうかにかかわらず、基本レベルでそれを理解して適用するだけでも、正直なところ、優れた分離が可能になり、多くの苦痛を感じることになります。 OOPが本当に役立つ唯一のことです。OOPは、コードの再利用と、その間こことそこでは、作成した多くのオブジェクトを実際に再利用することはできないので、システムが適切に分離されていることを確認することに集中してください。ボブおじさんが来てあなたのプロジェクトを主導すると仮定すると、彼は「わかりました、これは地獄のように馬鹿げていますが、少なくともすべてが分離され、適切に名前が付けられ、文書化されているので、少なくとも私はこれが何であるかを知っています」と言います。 LOCは絶えず変化しますが、執筆時点では、110k行のコードであり、1人の人に調和して機能する110k行の実行コードはたくさんあります。


これが3か月後の8か月のコードでの編集です。

それはすべて理にかなっています。何が起こっているのかを完全に理解しているので、当時書いたものを概念的に取り、コードを新たに作り直すことができます。回路図/優れた命名とコメントのために機能する理由かなり前にいくつかのコードを書きましたが、名前の付け方などは気にせず、苦労しました。私は今、コードを説明する次のステップが何であるかを考えています。

12
coolpasta