怠け者の考え方

誘引子
実は良い名前をつけることができます.例えば勤勉倹約家といいますが、勤倹は私の趣味ではありません.家族を持つのは私の得意なところではありません.
8月から4人だけの開発チームがスタートしました.このグループは主に部門の未来のmicro serviceの探索と研究開発を担当しています.その中の一人は修士の実習生です.学習コストを減らすために、nodejsを開発言語として選びました.開発の過程で、私達はいかなる技術問題に対しても広く深く討論します.一部の問題が私の考えを引き起こした.例えば、この文章は間もなく述べるもので、設計、流れ、最適化に関する一連の問題について、少しまとめてみたら、多くの問題は怠け者の思考で答えられます.これらには一定の共通性があり、しかも少しでも思考を引き起こすことができるものについては、書く必要があります.
しないことができます
仕事に対して、敬業の私達は必ずしないでやらないという考えを持ってはいけません.でも、プログラミングは違っています.
私たちが機能を開発すると、ユーザーの入力を受け入れるかもしれません.入力はチェックが必要です.フォーマットが必要です.アプリケーションが関心のないところに保存する必要があります.その中のロジックとプロセスはしばしば複雑で無秩序であり、その理由を説明するために詳細な文書が必要である.良い注釈を説明すれば、読む人にプログラムの意味を理解するように助けられます.これは通常、プログラムから独立したドキュメントよりも効果的です.
以下はコメントから始まり、ゆっくりとこれらの考えを示していきます.
コメント
長い注釈が必要ですか?
一般的に、大段の文字は忍耐力を失いやすいです.また、注釈の内容は説明したいコードから遠いかもしれないので、比較して見るのに不便です.ですから、一番いい方法は、一番最初に、簡単に大体の機能や流れを説明することです.具体的な説明は、特定の注釈が必要なコードに移行することができる.
コメントはコードの説明です.
関連技術を知らない閲覧者に類似の教程の注釈を提供しようとしないでください.いくつかのプログラマは、例えば技術的な説明に似た注釈を加えるのが好きです.

//Close the db connection
connection.close();

確かに、データベースの閉鎖メカニズムを知らない読書者はこの注釈から利益を受けるが、注釈は煩雑な教程になるべきではない.たとえ読む人が本当にこのようなヒントを必要としても、それは対応する技術文書の中で必要な知識を得るべきです.
データ検証
ある時、私達はデータベースに預け入れられるデータをチェックします.例えば、学生情報を一行預けたいです.

{
 name:'  ',
 gender:'0',
 grade:'3'
}

この中で、genderとgradeはそれぞれ、genderテーブルとgradeテーブルの主キーであり、studentテーブルでは、これらの2つは外キーである.はい、問題が来ました.情報を入れる前に、この二つの項目の合法性を確認するべきですか?
私の提案は、使わないでください.チェックしなくても、データベースは間違ったデータが保存されないことを保証します.もし私たちが正確なエラー情報をユーザーに返したいならば(例えば、性別が合法ではない、あるいは年齢が合法ではない)、大は失敗を保存してから検証してもいいです.
二つの方式の比較
事前に合法性を検査して、データベースを調べなければなりません.性別が合法かどうか、学年が合法かどうかを調べます.全部合法的にデータを入れます.エラーが発生した場合、2回確認しました.悪くないです.検査しないなら、三回まで検査します.普通は一回の保存だけで完成します.
また、実際のアプリケーションシーンでは、このようなエラーはめったに発生しません.この2つのデータはプルダウンリスト形式でユーザーに提供されることが多いので、ユーザがミスをする機会はほとんどないです.つまり、エラーは小さな確率のイベントです.小確率イベントに対して広範囲に防御を行うと、必要でないシステムリソースが消費されます.また、プログラムの複雑度も上がります.このようなプログラムは、このようにするかもしれません.

validator.verifyGender(gender);

validator.verifyGrade(grade);

...      

student.save();

検証されたロジックと通常の流れ(読み取り、転化、格納)が混在しており、後期メンテナンスにおいては、アップグレードが大きな課題となっている.
悪くないですね.調べませんか?

return  student.save();

通常のプロセス以外に、または後にエラーが発生したかどうかを監督してから、逐次処理する必要があります.つまり、正常プロセスとエラー処理は完全に分離されました.全体の流れがはっきりして分かりやすいです.
エラー処理
エラーが発生した場合、私たちは通常、詳細に適切な情報をユーザーに返すことを選択します.

は、非常に詳細であり、このような情報は、一般にエラーコード、情報、またはエラーが発生した位置およびプログラムコールスタックを含む.

非常に曖昧で、一般的にはエラーの種類だけを区別します.例えば、お客様の入力ミス、サーバーエラーなど.

詳細レベルは、ユーザーのタイプによって異なります.
直接ユーザが端末ユーザである場合、情報はあまり詳細ではない.このような情報はバックグラウンドロジックをスヌープするために使用されやすく、また、一般の端末ユーザにとっては、このような情報は役に立たない.いくつかのプロジェクトマネージャーは、詳細な情報はエラーの分析に役立つと考えていますが、端末からの情報を返して、エラーを分析するのはよく効果がなく、正確ではないです.
使用指導のような情報は含まれてはならない.
時々、私たちは無邪気に情報に次のような指導を加えます.

grade should be a number from 1 to 6

このような情報は、エラーリターンではなく、ドキュメントを使用するか、またはフロントページのヒントに表示されるべきです.簡単な提示情報を使うと、バックグラウンドの詳細をよく隠すことができますし、エラー情報をバックグラウンドで管理することも難しくなります.
考えてみてください.間違った入力に対するリターンは似ています.

grade is invalid

では、エラー情報を使って関数を生成したり、同じ種類のエラーを生成したりして、入力エラーごとにエラーを生成して返しても良いです.この部分のロジックは独立してもいいです.同じように、管理とアップグレードのコストは受け入れられます.
締め括りをつける
以上はばらばらですが、効果的にまとめました.多くの問題は最後まで設計思想上の衝突になりました.論争はまだ続いている.この文章は沈殿した貴重なものを記録し続けます.