ソフトウェア設計についての原則や法則についてまとめてみた
ソフトウェア設計について、YAGNIやSOLIDなど多くの原則・法則があることが知られていますが、その解釈にはぶれが存在することが多いです。そこで、特に有名なものあるいは有用と感じることが多いものをいくつかピックアップして、その解釈やトレードオフについてまとめてみました。 注意としては、SOLIDが入ってることからわかる通り、主にOOPに関する文脈になります。また、各原則の定義については概ね知っている前提で書いているのであまり初学者向けの記事ではないかもしれませんのでご承知おきください。 YAGNI（You ain't gonna need it.） YAGNIは、予測による実装が実際に役立つことは少ないという経験則から生まれた原則です。 一般にオーバーエンジニアリングが利益をもたらすケースは限定的で、どちらかというとプロジェクトに害を与えることが多いとされています。YAGNIは日々状況の
OOPはプログラマが用いる道具の一つに過ぎない
はじめに OOPは批判にさらされることが多く、これまでに問題点が多く指摘されてきています。その一方で、OOPは大規模開発でもよく用いられており、仕事で使える程度には有用であることが経験的に証明されているとも言えます。そのため、OOPに関する議論は「OOPのアイデアは悪い vs OOPは使えるから良い」というような構図に陥りがちで、あまり建設的ではないと感じることが多いです。 しかし、OOPは所詮は一つのプログラミングのスタイル、つまりは問題を解決する道具のひとつでしかありません。OOPの批判はWeb開発、特にサーバサイドの文脈上であることが多いですが、例えばGUIやゲーム開発においては便利に活用されているため、オブジェクト指向のアイデアが完全に悪いというわけではありません。オブジェクト指向の構成要素はオブジェクト、継承、カプセル化、多態性、動的束縛と言われていますが、これらをただの言語機能
開発チームでドキュメントを継続的に保守していくシンプルな方法
はじめに ドキュメントの管理方法はプロジェクトを進めるうえで頭を悩ませる話題のひとつであり、プロジェクトの本筋ではないこともあってなあなあで運用して後悔しやすい部分になります。ドキュメントを探しづらくなったり、ドキュメントが全然更新されずに使えるドキュメントがほとんどない状況になったり、ドキュメントの存在自体が暗黙知になったり、とにかく諸々の問題がよく起きます。こうしたことからプロジェクトに与える影響は存外に大きく、きちんと運用を考える必要性は高いと言えます。しかしながら、大袈裟な運用体制を敷いたり複雑なルールを作ったりすると、今度はコストが掛かり過ぎたりドキュメントを書くこと自体が難しくなったりもするので、費用対効果を考えると匙加減が難しい話でもあります。 そこで、本記事では比較的導入しやすく機能もしやすいシンプルな管理方法を提案します。なお、シンプルさを優先した方法なので要点を理解した
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
