「ちょうぜつソフトウェア設計入門」。

うちのプログラマーS君が

「おススメですよ！」

と言ってくれたので、読んでみました。

結論→よい本です！

かわいい絵がついていますが、中身は本格派！

普通に技術的なとっつきにくい話が展開されていますが、かわいい絵がついていることにより、とっつきやすい感じになっているのがすごい。

プログラマーの初心者向けというよりは、中級者、2年目とか3年目の方が読むとちょうどよさそうです！

 

ソフトウェアの設計って本当に大事ですよ。

この前、XにPostしたんですけど、一番大事なのはDBの設計ですが、次に大事なのは、クラス設計だと思ってます。

ただ、クラス設計についてまったくわからずにプログラミングをしている方も多くいると思います。

別にわからなくてもできるし、ソフトウェアは動くからです。

しかし、設計についてわかってやっている方が、他の人の開発が早くなるし、バグも少なくなります。

その逆も真です。

また、クリーンアーキテクチャーの一番内側に近い部分の設計がダメだと、技術的負債が膨れ上がります。

外側に近いほうはダメでもまだなんとかなるのですが。

 

この本は、いろんな手法をある程度の深さまで紹介してくれる点で優秀だと思います。

ぜひ、設計をちゃんとやってみたいという志がある方は、この本を読んでみてください！( ˊᵕˋ )

 

以下、私が読んでよかったなとか知らなかったことなどをメモしておきます。

①パッケージ原則

ちゃんとパッケージに分けましょう。

②オブジェクト指向とかSOLIDとか

オブジェクト指向の紹介と、SOLIDというソフトウェア設計の原則について紹介されています。

SOLIDは次の原則たちの頭文字です。

・Single Responsibility Principle　単一責任原則

・Open Closed Principle　拡張に対してオープン、変更に対してクローズドであるべき
この本の中で
「洋服をいっぱい着てというのはいいけど、痩せろとか胸を大きくとかは難しい、というのに似ている」
と紹介されていて、このたとえはわかりやすいな！と思いました。

・Liskov Substitution Principle　リスコフの置換原則

・Interface Separation Principle　　単一責任原則のインターフェース版

・Dependency Inversion Principle　依存関係逆転原則

 

ちなみに、SOLIDとは別で「デメテルの法則」というのが紹介されていて、すごい重要と思わないですが、これに名前がついてたのか！というのを知らなかったのでメモしておきます。

詳しくは下記を読んでいただきたいですが、
（デメテルの法則を厳密に守るにはどうすればいいの？）

現場ではこうなってるプログラムっていっぱいありますよね。

 

みたいなやつ。

いや、もうEngineクラスに書きなさいよって。でも、書いてる時は夢中で書いちゃうから気が付かないんでしょうね。

③テスト駆動開発やデザインパターン

 

スタブとかモックとかをあんまり使い分けていなかったので、大変参考になりました。

・スタブはテスト用の疑似オブジェクト　仮に期待通りの答えを得たとしたら、を仮定するダミーオブジェクト

・モックは使われ方を検証するための疑似オブジェクト（呼び出し回数とかをちゃんとチェックする）

 

④アジャイル開発

 

アジャイル開発とは何か、というだけではなく、ソフトウェア開発の歴史が書いてあって、非常に参考になりました。

私の師みたいな人がよく

「歴史を知ったほうがいい」

ってよく言ってるんですが、その意味がよくわかります。

ウォーターフォールについて、一般に誤解があることもわかりました。

ドキュメント偏重とか、SIの歴史なども勉強になりました。（o_ _)ｏ））

---

 

それにしても、ソフトウェア開発って苦労することばっかりですよね。

世に目を向ければ、ソフトウェア開発の失敗のニュースがよく飛び込んできます。

日本のシステム開発が少しでもよい方向に行ったらいいなと思います！

 

さて、弊社でも新卒・中途でプログラマーを募集しています！（営業も募集中）

ソフトウェア開発、設計とか考えてやりたいと思っている方がいれば、ぜひ弊社に応募してください。

イチから教えます！(`･ω･´)

応募はコチラから！