コーディングとメンテナンスの間にメモ、考え、アルゴリズム、決定を書き留めることは正常ですか/受け入れられますか？
一部の人々は彼らが言葉なしでは考えることができないというこの問題を抱えています。そして、彼らの考えや決定を書き留めることが、続行する最も効果的な方法です。
それで、コーディング中にいくつかのNotepad ++ファイルに自分の考えと決定を書き留めることは正常であり、受け入れられますか？
時々それは受け入れられるべきです、例えば。技術文書を再作成するとき、またはより複雑なアルゴリズムについて推論するときですが、奇妙な場合もあります。デザインオプションを検討し、判断を下すとき。
この慣行が生産性に与える影響は不明です。片側から-内面の言葉を使った推論は、書かれた言葉を使うよりも速いかもしれません。反対側から-より複雑な問題は書く必要があります。その上、より多くの設計オプションに行き詰まっていると、決定が書かれたときに気持ちが良くなるため、士気が高まります。
それは正常なだけでなく、良い考えです。
有名な引用があります
「6時間かけて木を切り倒してください。最初の4つで斧を研ぎます。」.
コーディングの前に時間をかけて考えを整理し、作業を計画することは、時間を費やすのに十分です。それらの考えを紙に書いておくと、計画を反省し、批評し、「頭の中だけ」で行うのは非常に難しい方法で整理する時間が得られます。
はい、これは完全に許容され、正常です。
コードを再検討するとき、意思決定プロセスを文書化することは、コードが特定の方法で作成された理由を特定するのに役立つことがよくあります。
これらのメモは、十分に短い場合、コメントとしてコードに直接含めることができます。拡張解説は、外部の技術設計ドキュメントの一部として保存されることがよくあります。
それはいまいましい良いアイデアです。それが先延ばしになる方法になるまで。
重要なのはバランスです。私は自分を箱に入れず、アイデアが出てきたらそれを捉えるのが最も生産的だと思います。
私が低レベルで研いでいて、高レベルのアイデアが出てきたら、それを書き留めて、後でそれに戻ります。
仕事の計画を立てることは良い考えですが、聴衆の前でコミュニケーションまたはプレゼンテーションをする必要がない限り、ペンとナプキンが最適なツールです。アイデアをキャプチャします。時間を無駄にしないでください。
どんなプロフェッショナルな状況でも、それは「正常で許容できる」だけでなく、必須です。典型的な開発サイクルは、コーディングが始まる前の2つの文書化フェーズで構成されています。
機能要件文書：通常、ビジネスアナリストが作成し、実装する機能を指定します。
詳細設計ドキュメント：これは、システム、アルゴリズム、など。私の（非常に）古いもののいくつかはオンラインです。 これ 。
あまり正式ではないドキュメントの場合、インラインコメントに関する前述の発言に110％同意します。これがonlyの方法です。何らかの方法で、他のすべては最終的に失われます。しかし、きちんとした思慮深いインラインコメントは、他のスキルと同じように努力と実践を通じて開発された別個のコーディングスキルです。私の（非常に）古いもののいくつかを見ることができます。 これ 。そのスタイルはあなたにアピールするかもしれませんし、しないかもしれません。最初に、コメント付きのコードを好みのスタイルで見つけ、それを自分のコードでエミュレートすることをお勧めします。しばらくして、必要に応じて調整します。
この種の情報を配置するのに最適な場所は、バージョン管理システム（SVN、gitなど）のコミットメッセージに直接あります。これにより、同じ場所で変更とその理由を確認できます。
他の良い答えに加えて、私がやろうとしていることについての私の考えをしばしば書き留めることを付け加えます。
私がやろうとしていることを明確に説明することは非常に明確であるため、必ずしも成り立たない推定、仮定、要件を実現するのに役立ちます。
次に、代替案のヒントを示します。次に、代替案を順番に検討していきます。他のことを考えれば、その文章は私の場所を保存するのに役立ちます。
私はすばやくメモを取り、深みと深みを調査します。再帰的に機能するため、ソリューションツリーの詳細、ナビゲート、評価、バックアップ、探索、発見、実現、および決定に役立ちます。
あなた/（新しい）チームメンバーの時間を節約できる何かを書き留めることは、十分に費やす時間です。それが誰かに後で必要になる可能性があることを確認し、実際の長期的なプロジェクトでない限り、考えすぎないようにしてください。
また、時間もかかりません。考えることに時間を費やす場合は、1対1で考えを書き留めることができます（誰かに役立つ/可能である限り）。
実際の問題は、あなたが何を書いているのかを考えすぎている可能性があります。あなたが書いているからといって、既存の形式に準拠する必要がある、または完全なドキュメントを作成する必要があるという意味ではありません。
何も書いていないことと、メモ帳で非公式のメモを書くことのどちらかを選択する場合は、非公式のメモを書いてください。
あなたは言う：「何人かの人々は彼らが言葉なしでは考えることができないこの問題を抱えています。そして彼らの考えと決定を書き留めることは先へ進む最も効果的な方法です。」
自分の考えや決定を書き留めることが最も効果的な方法である場合、なぜ最も効果的な方法で進めるのが普通ではなく、受け入れられないのでしょうか。あなたはあなたのために最もうまくいくことをします。それは他の誰かにとって最もうまくいくものではないかもしれません。その場合、あなたは他の人にあなたにとって何が最善であるかを言わせないでください、そしてあなたは彼らに彼らにとって何が最善であるかを教えません。誰もが彼らのために最善を尽くします。
人間は頭の中で一度に約7つの「もの」しか持てません。それが7桁の電話番号の理由です。プログラマーが効率的に作業するためには、何かをメモリからオフロードして、後で必要に応じてすばやく取得するための何らかのシステムを見つける必要があります。あなたのメモを取ることは明白で直接的な方法ですが、適度に複雑なものに取り組んでいる誰もがそれを行わなければなりませんなんとか。プログラムを誰かとペアにするときは、その方法を探すようにします。
一般的な方法の1つは、テスト駆動開発です。この方法では、1つの失敗したテストを作成し、その失敗したテストに合格するのに十分なコードを作成してから、既存のすべてのテストに合格したまま、コードをリファクタリングして見栄えを良くします。この方法論は、テスト内でエンコードされたすべての「メモ」を保持します。人々は次のテストに集中するだけなので、メモを取る必要がないように、この方法で非常に迅速に作業できます。
もう1つの一般的な方法は、コードに疑似コードコメントまたはスタブとしてメモを書き込んでから、徐々にそれを実際のものに置き換えます。これが私が通常アルゴリズムを書く方法です。私の最初のドラフトは、疑似コードを使用したメイン関数にすぎませんが、徐々に、ますます深いレベルの抽象化が行われます。
効果的な方法を使用することについて気を悪くしないでください。ただし、「効率的な」同僚が使用している方法に注意してください。彼らはあなたがするのと同じ人間の制限があります。