回答:
そのコードを維持する必要があるのは、あなたであるかのようなコードを書きます。
可能な限り怠けてください。
Zen、パートI：プログラミングは道であり、方法ではありません。
プログラミングは、コンピューターにすべきことを教えるための唯一の手法です。高速で信頼性の高いソフトウェアの作成に成功するとは、アルゴリズム、ベストプラクティス、およびプログラミング（言語）に必ずしも接続されていないその他すべてのものを知ることを意味します。
禅、パートII：急いでいる場合は、ゆっくりと散歩してください。あなたが本当に急いでいるなら、迂回してください。
馬鹿げているように聞こえますが、（実際に）後で問題になる可能性のある妥協点に身を委ねないでください。私はルールを得ました：あなたがプログラムの中核にいるなら、できるだけ正確で良いことをしてください。ソフトウェアの奥深くにあるコアのメソッドを使用している場合は、コーディングを高速化してください。これら2つを超えてコーディングしている場合は、少しずさんなこともあります。
設計エラーは、発見および/または修正が最も難しく、次のステップは、誰もが依存する部分のプログラミングエラーです。次に、「本当の魅力的なソフトウェア部分」です。プロジェクトの終わりに設計エラーを修正する必要がある場合は、うーん、それは良くありません... ;-)
禅、パートIII：あなたの道を知っている、ネオ。
環境、ツール、依存しているものを日常的に把握し、適切に機能するように整理します。プログラミングの「環境」を非常に自然に使用しているので、考える必要すらない場合に最適です。仕事を終わらせなければならない場合は、「派手な新しいもの」を紹介せずに、仕事をしてください。このようなものは、新しいプロジェクトに導入できます。つまり、準備して使用する時間があるときに導入できます。
KISS（シンプルに、愚かにしてください）。
それは確かに「シンプルをどのように定義しますか？」という質問を請います。また、「手近なタスクに単純すぎるものがある場合」これが、プログラミングの最初の原則を知っているだけでは優れたプログラマーになれない理由です。
最初に問題を理解してください！
ヤグニ-あなたはそれを必要としません。YAGNIの背後にある考え方は、将来の潜在的な機能ではなく、要件に合わせてプログラムすることです。前提は、プログラムに必要なものを維持することにより、（特に）コードの肥大化を減らし、複雑さを軽減し、機能のクリープを回避し、実行できること（および実行できる方法）の制限を減らすことです。未来。
モジュール設計と連携して動作すると思います。既存のコードを再設計することなく、将来の機能を拡張できます。
いつプログラムしないかを知る。
原因と結果の区別（コンピューターでの作業）
事実と意見を区別する（人々と働く）
できるだけシンプルだが、シンプルではない（デザイン）
プログラミングは終わりではなく手段です。または、おそらく「できる」という意味ではありません。
次の男のコードを書きます。
それはすべてユーザーに関するものです。