釣りキチプログラマー翔平の備忘録 
はじめに
「良いコード/悪いコードで学ぶ設計入門』著者トーク」という勉強会に参加したので、
勉強会での内容を気になったポイントに絞ってまとめ、僕の感想や気付きなども書いてみました。
「基本から学ぶ テーブル設計 超入門！」(勉強会)で印象に残ったところや気づきなど
自分は、ここ数年特にアプリケーションの設計に興味を持ち、
設計についてネットで情報を集めたり、本を読み漁ってみたり、
実際にサンプルコード書いてみたりして良い設計を体験してみたり、
今回のような勉強会に参加してみたり・・・
して自分なりに設計スキルを磨いてきました。
そして、現場で見るコードが悪しきコードだということの認識を持ち、
会社の上の人に現状の設計における課題を説明しにいって、
会社の上の人はなんとか納得させたものの、
今までアプリケーションアーキテクトの立ち位置で仕事をしていた(トランザクションスクリプト派の)人に
反感を食らいながらもなんとか技術負債の対応を仲間を増やしながら進めつつ、
本来の機能追加もそれはそれで進める。
ということを今まさにやっているところです。
今回の勉強会でミノ駆動さんが現場でのリアルについても語られていたのですが、
今自分が体験していることと似た話もありかなり共感できる部分も多かったです。
良いコード/悪いコードで学ぶ設計入門という本はプログラミング言語を習得して中級〜上級エンジニアになるための架け橋となる
エンジニアの必須スキルにはgithubが使えることだったり、
AWSやDockerが使えることなどなど募集要項に記載されていることが多い。
一方、
アプリケーションの技術負債が要因で年間12兆円もの損失が出ており、
我々の業界の成長を妨げている。
これをなんとかするためにも、
エンジニアの必須スキルに変更容易性を考慮した設計のスキルを追加すべき。
とはいえ、
技術書はとあるプログラミング言語を習得する本からその先の、
中級以上の設計スキルを身につける本との間には溝がある(難易度が一気に上がる)
このミノ駆動さんの良いコード/悪いコードで学ぶ設計入門という本は
この中級以上のスキルを身につけるための架け橋になる。
という話がありました。
自分も、Javaを習得したあと、
データベース周りの勉強をしたり、
認証認可周りの勉強は資格や本があってスキルアップしやすかったですが、
アプリケーションの設計の勉強についてはいきなりリファクタリングとかドメイン駆動設計の本に手を出して
難しいな・・・と感じたことがありました。
ちなみに、自分の場合だと、
プログラミング言語を習得した次に設計スキルを上げるために読んだ本は、
増田さんの現場で役立つシステム設計の原則でした。
これは、読んだだけではなく、
実際にサンプルコードを自分でお題を考えて作ってみたり、
作ってみて設計の引き出しを増やすことができたり、
それぞれの特徴や重要性を体感したりしました。(個人的に人生で初めて真面目に読んだ本でした)
興味がある方は是非まとめ記事を読んでみてください。
自分はこれで良い設計とはそもそも何？？という基本的なことを学びました。
ミノ駆動さんの良いコード/悪いコードで学ぶ設計入門という本は僕にとっての
現場で役立つシステム設計の原則に近い位置づけの本なのかなと今時点では感じています。
実際に読んでみるとまた感じることがあると思うので感想や気づきはまとめていきたいと思います。
注文予約しているのですが、本が届いたらゴールデンウィークで一気読みだな・・・
現場でのミノ駆動さんが体験したリアルなリファクタリングや設計改善時のハードル
ミノ駆動さんはリファクタリングで悪しきコードを良いコードにしていくことに関しては、
いかに難攻不落の悪しきコードでも楽しめるそうです。
が、
リファクタリングをしていいかジャッジする上の人とのやりとり、
現状のアプリケーションアーキテクチャに慣れているエンジニアとのやりとり
が一番のハードルだとのことでした。
自分もちょうど先月、
同じようなシチュエーションになり・・・・
自社プロダクトのかなりの機能に影響が出るような追加機能開発チームのテックリード兼開発リーダー
としてアサインされ、
既存のトランザクションスクリプトのためのアーキテクチャをガチガチに作ってあるシステムに対して、
ドメインモデルを作って(無駄なビジネスロジックがあり、あるべき姿も不明だった)
既存アーキテクチャとの相性を考えて理想系から少し落とし所を模索して設計方針を検討
コスト出して上への説明(現場の課題と設計変更によるメリットなど)
既存アプリケーションアーキテクトや配下メンバーへの説明
をして大変さを味わったところだったのでよく気持ちがわかりました。
特に上の人はいろんな思いを持った人やシステム設計に詳しくない人、
逆にトランザクションスクリプト思考の強いアプリケーションアーキテクトなどなど
同じ１回の説明では伝わりきらなかったりかなりの時間と労力を使いました。
逆に配下メンバーは現場の課題を痛感しているので是非それで進めたいとのことでした。
最終的には、
条件付きで許可されて、少し理想の設計ではないものの、
方針自体には全員やるべきだし案として素晴らしいという話でなんとかやる方向になりました。
が、それなりに反対派からの攻撃にもあい、周りから心配されたりも・・・
ミノ駆動さんもかなり反対派からの攻撃にあったりした経験があったそうですが、
(リファクタリングをするのがメインだと多分そういうシーンの連続なんだろうな、、)
その度に、負の感情をエネルギーに設計スキルを磨き、
その人たちへの説明の理論武装への力に変えていたそうなのと、
エンジニアとしてちゃんとしたもの作りたいという強い意志を持っておられるのだと感じました。
これがプロフェッショナルだなと憧れましたし、ファンになりました。。。。
それと同時に僕もエンジニアとして何があってもちゃんとしたものを作るための最善を尽くす努力を
していかなければと強く思いました。
落とし所や優先度をどのようにつけながらミノ駆動さんが技術負債を解決していくのか
全て理想の設計をすることはできない。
ビジネス的に重要なところ、変更が多くなりがちなところを
システム全体を俯瞰した上で判断し選択していくところから技術負債の解決を進めていくという話がありました。
この落とし所を探るというか、
かけられる工数と優先度とを考慮したアプローチは
僕の中では先月できていたのかなと少しこの話を聞いて間違ってなかったかなと思いました。
具体的には
担当したプロダクトの中で一番複雑でカオスになっており、
ビジネス的に重要で仕様変更の激しいところを
ドメインエキスパートを巻き込みながら整理して、
そこに対してのリファクタをかけ、テストコードも作るが、
他の機能はひとまず触らない。
というような整理をしてリファクタリングの計画を立てて、今まさに取り組んでいます。
以上が勉強会を通じて感じたことです。
自分も精進して少しでもミノ駆動さんや増田さんに追いつきたいなと思いますし、
現場でいろんな目にあっても自分の強い意志を持ち、
妥協せずちゃんとしたものを作るために努力し続けるプロフェッショナルを目指そうと思いました。
(ちょっと今回熱くなってしまった、、、)
