これはなに
4月からスタートアップに入って自分の不甲斐なさを痛感しているので、リーダーからおすすめされた書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」をこの土日から読み始めました。知識の整理と発信を兼ねて、第一部の学びをつらつらと書いています。
なぜ読むか
- ソフトウェア開発をするにあたって、仕様を設計に落とし込むことができなかったから
- 仕様から機能に落とし込むにあたってどう抽象化すれば良いかわからなかったから
どうなりたいか
- 仕様を設計に落とし込む引き出しが増えていること
- 機能を抽象化する場合どういった手法があるのか、抽象化する各種の手法はどういったケースで使うのが最適化理解していること
学びと深堀り
- 学び 💪🏻
- 設計とアーキテクチャに違いはない
- リリースごとに労力が増えるようであれば設計は優れていないといえる
- 崩壊したコード＝再設計が必要になるコード、崩壊したコードが増えるほど変更するコストは増える
- エンジニアはうさぎ（自信過剰）、崩壊したコードを出してもリファクタリングで直す、直せると思っているが一度崩壊したコードを市場に出すと、再設計してもまた破綻する
- 生産性は一度低下すると、取り戻すことは難しい。生産性の低下はビジネスに多大な影響を与える（コストに対する成果が低くなり、開発チームが赤字になる）
- 速く進む唯一の方法は、うまく進むこと。うまく進むには、クリーンなコード、優れたアーキテクチャのみをリリースすること
- ソフトウェアは簡単に変更できなければいけない
- 変更の難易度は、変更の形状ではなく、変更のスコープに比例するべき
- アーキテクチャが特定の形状を選択していると、変更がその構造に適さない可能性が高くなる＝再設計が必要になる＝変更の難易度が高くなる
- 形状にとらわれないアーキテクチャに設計することが大事
- エンジニアはアーキテクチャに責任を持ち、変更コストを低くたもつことを最重要事項とするべき
- 緊急と重要は違い、緊急は重要にならないことを把握する。勘違いをして重要なアーキテクチャを疎かにしない
- エンジニアは各部署との調整の中でアーキテクチャの重要性を主張して「闘争」することが責務
- 各部署のメンバーも企業の最適を主張してくるが、戦いに負けないようにする
- より知りたい ❤️🔥
- 再設計が必要なコードの具体例
- 後でいっぱいでてくる
- コードに責任をもつ考え方や行動の仕方
- いい本か、ブログを探す
- エンジニアはビジネスに対してどう関与すべきか
- TDDはなぜやるのか、どうやるのか
- いくらでも本があるから読む
- 変更のコストを低く保つ具体的な手法
- 後で出てくる
- 「緊急だが重要でないもの」と「緊急かつ重要」の区別の仕方
- 経験して学ぶしかない？ビジネスの考え方とかで参考にできるやつがないか探す
- 再設計が必要なコードの具体例
あとがき
第二部も読み進めており、学びを整理するだけ。全部で6部、34章あるからある程度長期戦になりそうだけどダラダラせずに読み進めていこう。
