しかし、あなたの人生をより良くする方法は？ コードの品質レベルを上げる方法。 このテーマについての私自身の反省のルールをいくつかお見せしましょう。
1.実行されたアクションの完全な認識。
プログラマは、記述されたコードの各行を完全に認識する必要があります。 ルールは非常に単純に聞こえます 。 「なぜ機能したのかわかりません 。 共有リポジトリに変更をプッシュしないでください 。 」 最近、私はランダムな実装に注目しています。 それらを認識することは非常に簡単です：精巧な構成、コメントの欠如、または熱心に曖昧な言葉遣い...最も正確な方法は、疑わしい機能を実装するメカニズムを説明するようにプログラマーに依頼することです。
観察の結果は恐ろしいように見えます-ほとんどすべての「無意識の」機能にはほとんど瞬時に現れるエラーが含まれています。 そして、たいていの場合、これらはいわゆる偶数バグであり、間違った部分を修正し、それのおかげで他のすべてが少なくともほぼ正しく動作したことを理解します。
長所：行われた作業を実現し、真実と同様の結果を達成するだけでなく、プログラマーは専門的に成長します。 エラーの数も減少し、それらのほとんどは修正の複雑さにより、ありふれたタイプミスのレベルにあります。 実装はより最適で、シンプルで直感的です-追加のドキュメントやコメントがなくても、アルゴリズムは読みやすいです。
短所 やがて非常に高価になります。 特にプログラマーのレベルがそれほど高くない場合。 松葉杖は、このルールを順守できないほど熱心なチームではうまく定着しません。 そして、これはあまり良くありません：困難な時期（例えば、リリースのために製品を緊急に準備する必要があるとき）には、高品質の松葉杖愛好家が2人必要です。 また、穏やかな時期には、チームが分析の行き詰まりであまりにも長く行き詰まらないようにするのに役立ちます。
2.許容される悪の明確な枠組みの存在。
時には、理想に屈して、低品質のコードを見逃さなければならないことがあります。 さらに悪い。 一定の譲歩を常にしなければなりません-人生は残酷で不公平です。 ただし、明確な制限が必要です。 したがって、ストレスの多い期間には、間隔と命名規則の非遵守を指で見ることができますが、危険な過失を何らかの形で機能し、期限が厳しい場合でも、鋭く残酷に停止することをお勧めします。
長所 適切に動作しているように見えても、実装が正しくないと感じた場合は、修正する必要があります。 第一に、重要な瞬間の緊張はすでに非常に高いため、良心への苦しみと否定性の蓄積がまだ十分ではないからです。 第二に、製品を引き渡すことは、もちろん第一の目標ですが、その主な機能を果たす必要があります。 いくつかの小さな欠陥があるアプリケーションをリリースすることと、コンパイルされたコードの無駄な部分に顧客を満足させることです。 これがプラスであるかマイナスであるかはわかりませんが、直観が発達しないとできません。 詰められたコーンなし。 しかし、まだプロのままにしておきます。
短所 下からも上からも圧力に備えなければなりません。 それはどうですか-あなたはそれをより早く必要としますが、チームはその輝きに気を取られます。 神経を失うことなくできません。 さらに、プロジェクトが失敗した場合に大幅に置き換えることができます。 要するに、深刻なリスク。
3.フランクネス。
人が問題を完全に意識的に解決できないと仮定します。 たぶん、それを正しく行う時間がないのかもしれません。パラメータの一部は、突く方法を使用して選択する必要がありました。 または、正しい解決策が複雑すぎる-簡単なバージョンを作成して、松葉杖でバックアップする方が簡単です。 これは、必要以上に頻繁に発生します。 しかし、少しだけ和解します。 チームで率直さを培う方がはるかに良い。 私はあまりうまくいきませんでした-コメント、コミットの説明のテキストでそれを認め、さらに良いことに、プロジェクト管理システムにメモを残します。
当然、承認に対する罰則はありません。
長所 良い時間になり、リードが増えれば増えるほど、未完了のタスクに戻ってすべてを正しく実行できる可能性が高くなります。 戻ってこなくても、正直な警告コメントは、エラーを修正するためではなく、少なくともそれを見つけるために、他のプログラマーのために将来多くの時間と神経を節約します...この関数は、一週間の奇妙な問題の後、それ自体を理解します。 さらに、不完全さを認めると、著者は恥ずかしくてやり直しになる可能性が常にあります。
短所 コントロールを失うのは非常に簡単です-従業員はそれに慣れることができます。あなたがそれに対して何も持たないように、枠を認めるのに十分です。 ここでも、すべてがリーダーの直感にかかっています。 欠陥は、プロジェクト全体に誇らしげに散らばっている「香ばしい」グアノパイルになってはいけません。 言い換えれば、このアプローチの主な難しさは、免責の正しい投与量です。
もちろん、何も保証するルールはありません。 さらに、それらのそれぞれは、肯定的な結果を無効にする可能性のある過剰を許可します。 しかし、何かする必要があります。 そして、問題の認識から始めます。 それを行うことは確かに完璧ではありませんが、可能な限り効率的にリソースを使用するよう努めなければなりません 。