はじめに
こんばんは。
今週から２つの輪読会が始まりました。
1つ目はクリーンアーキテクチャ輪読会
2つ目はレガシーコードからの脱却輪読会
リンクなし
クリーンアーキテクチャの方は、以前も輪読会したのですが、今お仕事を頂いている会社主催の輪読会だったので、復習のために再度参加しました。
本題
クリーンアーキテクチャ #1
第1章 設計とアーキテクチャ
気づき
- ソフトウェア設計の目的
- 求められるシステムを構築・保守するために必要な人材を最小限に抑えること
- 崩壊のサイン
- アーキテクチャ構造の配慮にかけているものをリリースし続けると、リリース毎にコストが上昇していく
- 経営者視点でみても、コストが上昇する毎に開発者単価も上がっていくため、経営にもダメージがある
- 後々対応する。の罠
- 設計の配慮を欠いているコードが世に出ることを理解した上で、「後でキレイにするからとりあえずリリースしよう」と、リリースしたものは、後でキレイにされることはない。競合他社のプレッシャーに打ち勝つため、次の機能のリリースをどんどん開発し、走り続ける必要があるから。
- 早期リリースのために設計配慮の欠けたコードを書くという行為は、事実誤認。実際は短期的にも長期的にも、設計に配慮されたコードを書くほうが早い。
- 一から再設計するという方針もおすすめしない。現実はそれほどうまくいかない。
第2章 2つの価値のお話
気づき
ソフトウェアの定義
- ソフトウェアは
ソフトに なるように考案されたものだから、簡単に振る舞いを変更できなければならない。簡単に変更できないものはハードウェアだ。
- ソフトウェアは
振る舞いと構造
- 大事なものは振る舞い(機能が動作すること)ではなく、構造(機能を提供しつつ変更に強い)である
-
- 振る舞いは
緊急だが、常に重要とは限らない。構造(アーキテクチャ)は重要だが、常に緊急とは限らない。緊急かつ重要というのが最優先だが、ビジネスマネージャは、振る舞いを緊急かつ重要に昇格させることが多々ある。構造の重要だが、緊急ではないを判断できていない。ここをわかっていないと崩壊のスタートになる。ビジネスマネージャにきちんと判断させるために、きちんと発言できるアーキテクトの存在が重要。
- 振る舞いは
感想
1〜2回読んだことがあるので、復習という感じで読めました。
はっとしたのは、クリーンアーキテクチャもレガシーコードからの脱却も、レガシコードや、それの影響について似たような文章があったことでした。
最初は2つ同時期に輪読会読みすすめることは少し不安でしたが、こういった気付きがあったのでやってよかったと思いました。
レガシーコードからの脱却 #1
0章 何かが間違っている
気づき
- クリーンアーキテクチャの冒頭でも、レガシーコード(設計が練られておらず、修正にコストがかかるコード)について似たような記載があった気がした
- ウォーターフォール手法が、ソフトウェア開発にマッチしないということを理解できた。
- What(何)コメントではなくWhy(なぜ)コメントを残す。Whatはコードが明瞭に表現されているべき(他書でも良く言われているけど言い回しが一番しっくりきた)
悩んだこと
- 本書でも書かれているウォーターフォールでの開発を経験したこと無いのだけど、経験した方はいるのか？どんな感じだったのか？また、今で結構あるものなのか。
感想
自分はガチガチのウォーターフォールを経験してなかったので、こういった現場は今でも結構あるのか？と思ったりしたのですが、参加者の方とお話して、ここまではないにしても、気づいてなかったけど小さい粒度でウォーターフォール開発をしていたというのを気づきました。
ただ、 小さい粒度のウォーターフォール開発ってなに？それがアジャイル開発？ という話題が広がっていき、そもそもアジャイル開発とはどんなものなのか？という謎が続いていきました。
僕は アジャイル開発とはなにかを説明してください と言われて、きちんと説明ができないので、アジャイル開発がどんなものかを理解していないのだとはっきりわかりました。
終わりに
色々と気づきがある輪読会でした。
あと HackMD便利。
現場からは以上です。
