PIEとは
Program Intently and Expressivery.
ひたすら意図を表現するプラグラミングをせよ
設計書はコード
あるあるですね。
設計書はない、OR 、メンテしてないから情報が正しいかわからない。
結局コードが一番の設計書になりがちです（たまに本番で動いているのとgitに上がっているのが違うコードで、コードすら正しくないパターンもありますが）。
なので、設計書のつもりで、誰かに読ませるつもりでコードを書くのが一番ですね。
コードは読みやすさが最優先
可読性とか言ったりしますが、書くことよりも読まれることのほうが圧倒的に多いので、読み物としてコーディングする必要があります。
コメントを書くのも、ネストしすぎないのも、一つのクラスや関数で長々と書かないのもそのためですね。
クラスや関数の役割を明確にしておくと、読みやすくなります。私の場合はクラスや関数を部署と思って設計しますが、「データを取得するだけの部署」、「データをチェックするだけの部署」、「データを整形するだけの部署」などと役割を明確にしておくと、あとから改修するときに「この関数だけを気にすれば良い」と最初に割り切れるので、対応しやすかったりします。
他の人のコードを直すのも大事
他の人が作ったシステムを改修するタイミングでついでに見やすくリファクタリングするのも大事です。
もともと美しいコードであれば良いですが、そうではない場合こういうタイミングで直していかないといつまでも負の遺産が残されていくので、勇気を持ってこれも運命だと思って読みやすく正していくことで、プロジェクト全体の生産性が上がっていきます。
つまり
コーディングルール作って、メンバー全員で意識してプログラミングしようぜ