読みやすいコードを書くためのガイドライン

はじめに 長くシステム開発に携わっていると、最初は素早く開発することができたけども、今では新たな機能を付け加えるのに、多くの時間を費やすようになったという話をよく聞きます。 初めはシンプルだったソースコードも年月が過ぎていくなかで、機能追加やバグ修正、変更を行なっていくと、コードが非常に複雑化していき、開発者が修正するコストの増加やコード品質の低下につながります。設計の良くないコードや複雑化したコードは、同じ処理をするのにも余計にコードを書く必要がでてくるからです。 今回は、コードを複雑化して品質を低下させないために、普段意識しているソフトウェア設計や手法を紹介していきたいと思います。色々書いていますが、結果的にクリーンアーキテクチャー成分が多めになってしまいました。 「読みやすいコード」が持つメリット コードを読みやすくすることは開発全体に好影響を与え、特に以下の点において最大限効果を発

[xlc]

面倒くさいので自分のためだけにコードを書ける立場でいたい。

[pmint]

チームのためのガイドラインを一人で書く愚かさ。せめてレビューしてもらって。「設計原則が守られていない場合」の図なんか嘘だし、残高0でも金を引き出せる仕様なら、そりゃ読みやすくなるだろう。

[turanukimaru]

自分のためだけにコードを書くべきであり明日の自分のために読みやすいコードを書くのだ。私は自分の記憶力も理解力も信用していない。ところで static にしていいのはインスタンス生成コードだけだ。Amount class を作れ。

[ghostbass]

メソッドチェーンはその名の通り「メソッドの呼び出しをチェーンする」なのでデータ構造の深いところにアクセスする事とは無関係(LoDとも無関係)ただチェーンの最中にコンテキストを変更するのは不可

[kenzy_n]

心がけたいことが多い