コーディングおよびメンテナンス中にメモ、思考、アルゴリズム、決定を書き留めることは正常ですか？[閉まっている]

言葉なしでは考えられないこの問題を抱えている人もいます。そして、彼らの考えや決定を書き留めることは、最も効果的な進め方です。

だから-コーディング中にNotepad ++ファイルに自分の考えや決定を書き留めることは正常で受け入れられますか？

技術文書を再作成したり、より複雑なアルゴリズムについて推論したりする場合など、受け入れられるべき場合もありますが、設計オプションを検討して判断しようとする場合など、奇妙な場合もあります。

このプラクティスが生産性に与える影響は不明です。片側から-内側の言葉を使った推論は、書かれた言葉を使った場合よりも速いかもしれません。反対側から-より複雑な問題は書く必要があります。それに、デザインの選択肢が増えれば、意思決定が書かれたときのフィーリングが良くなり、士気が上がります。

それは正常であるだけでなく、良いアイデアです。

有名な引用があります

「木を切り倒すために6時間与えてください。最初の4時間をかけてsharpを研ぎます」。

コーディングに時間をかける前に、時間をかけて考えを整理し、作業を計画してください。これらの考えを紙に書くことで、あなたの計画を振り返り、批評し、「頭の中で」だけでは非常に難しい方法でそれらを整理する時間が与えられます。

はい、これは完全に受け入れられ、正常です。

多くの場合、コードを再検討するときに、特定の方法でコードが記述された理由を判断するのに役立つ、意思決定プロセスを文書化することは有益です。

これらのメモは、十分短い場合、コメントとしてコードに直接含めることができます。拡張解説は、多くの場合、外部の技術設計文書の一部として保持されます。

それは非常に良い考えです。それが先延ばしになる方法になるまで。

キーはバランスです。自分を包み込むのではなく、アイデアが浮かび上がってくると、私は最も生産的になります。

低レベルで磨いていて、高レベルのアイデアが浮かんだら、書き留めて後で戻ってきます。

作業を計画することは良い考えですが、聴衆の前でコミュニケーションやプレゼンテーションをする必要がない限り、最高のツールはペンとナプキンです。アイデアをキャプチャします。時間を無駄にしないでください。

どんな専門的な状況でも、それは「正常で受け入れられる」だけでなく、必須です。典型的な開発サイクルは、コーディングが始まる前の2つのドキュメントフェーズで構成されます。

1. 機能要件ドキュメント：通常、ビジネスアナリストが作成し、実装する機能を指定します。

2. 詳細設計書：などシステムの機能分解（ファクタリング）を指定し、正式ちょうどより多くの、あなたが何を言ってるのかかなり多くあり、アルゴリズム、私の（非常に）古いものの中には、例えば、オンラインでこの。

あまり正式ではないドキュメントについては、110％がインラインコメントに関する前述のコメントに同意します。それが唯一の方法です。何らかの方法で、他のすべてが最終的に失われます。しかし、きちんとした思慮深いインラインコメントは、他のスキルと同様に努力と実践によって開発された別個のコーディングスキルです。私の（非常に）古いもののいくつかは、たとえばthisで見ることができます。そのスタイルはあなたにアピールするかもしれないし、しないかもしれません。まず、好きなスタイルのコメントの良いコードを見つけて、それを自分のコードでエミュレートすることをお勧めします。しばらくして、適切と思われるように調整します。

この種の情報を置くのに最適な場所は、バージョン管理システム（SVN、gitなど）のコミットメッセージに直接あります。これにより、同じ場所で変更とその理由を確認できます。

他の良い答えに加えて、私がやろうとしていることについての私の考えをしばしば書き留めることを付け加えます。

私がやろうとしていることを明確に表現することは、必ずしも当てはまらない推定、仮定、および/または要件を実現するのに役立ちます。

それは代替案を示唆しており、各選択肢を順番に検討することができます。私が何か他のことを考えると、私の文章は私の場所を救うのに役立ちます

呼吸と深さを調べるために簡単なメモを取るので、再帰的に機能し、ソリューションツリーの詳細化、ナビゲート、評価、バックアップ、探索、発見、実現、決定を支援します。

あなた/（新しい）チームメンバーの時間を節約できるものをすべて書き留めることは、時間を費やす時間です。それが誰かが後で必要とするかもしれないものであることを確かめてください、そして、それが本当の長期プロジェクトでない限り、考え直さないでください。

また、時間は一切かかりません。あなたが思考に時間を費やすなら、あなたはあなたの考えを1から1まで書き留めることができます（誰かに役立つ/有用である限り）。

本当の問題は、あなたが書いたものを考え直すことです。あなたが書いているからといって、既存のフォーマットを守らなければならないということでも、完全なドキュメントを作成するためにすべてを行う必要があるということでもありません。

何も書き留めないか、メモ帳に非公式のメモを書くだけのどちらかを選択する場合は、非公式のメモを書きます。

あなたは言う：「一部の人々は、言葉なしでは考えられないこの問題を抱えている。そして、自分の考えや決定を書き留めることが、最も効果的な進め方だ」

あなたの考えや決定を書き留めることが最も効果的な進め方であるなら、なぜ最も効果的なやり方で進めるのが普通で受け入れられないのでしょうか？あなたはあなたに最適なことをします。それは他の誰かにとって最適なものではないかもしれません。その場合、自分に最適なものを他人に言わせたり、自分に最適なものを教えたりすることはありません。誰もが彼らのために最善を尽くしています。

人間は一度に約7個の「もの」しか頭に入れることができません。それが7桁の電話番号の理由です。プログラマーが効率的に作業するためには、何らかの種類のシステムを見つけてメモリから負荷を取り除き、必要に応じて後ですばやく取得する必要があります。メモを取ることは明白で直接的な方法ですが、中程度に複雑な作業をしている人はなんとかしなければなりません。あなたがプログラムを誰かとペアリングするとき、彼らの方法を探すためにポイントを作ります。

一般的な方法の1つは、テスト駆動開発です。この方法では、失敗したテストを1つ作成し、失敗したテストに合格するのに十分なコードを記述し、コードをリファクタリングして、既存のすべてのテストを成功させながら見栄えを良くします。この方法では、テスト内ですべての「メモ」がエンコードされたままになります。次のテストに集中しているだけなので、人々はメモを取ることなく、この方法で非常に迅速に作業できます。

もう1つの一般的な方法は、コード内にメモを擬似コードのコメントまたはスタブとして記述し、それを徐々に本物に置き換えることです。これは私が通常アルゴリズムを書く方法です。私の最初のドラフトは、擬似コードを備えたメイン関数に過ぎず、次第に抽象化のレベルが深くなります。

自分に合った方法を使用することに気を悪くしないでください。しかし、「効率の良い」同僚が使用している方法に気をつけてください。彼らにはあなたと同じ人間の制限があります。