gihyo.jp
良いコード／悪いコードで学ぶ設計入門 の読書メモです。
長いので章ごとにしてます。
15 設計の意義と設計への向き合い方
15.1 本書はなんの設計について書いたものなのか
設計とだけずっと書いてあったけど、その設計は変更容易性の向上を目的としたものだったのか…。
- 本のタイトルに入れてもらいたい気持ちもあります…。
- はじめにを見直したけど、そこにも書いていなかったです。
15.2 設計しないと開発生産性が低下する
- セクションタイトル、
設計しないとだけだと足りない気持ち。本文のように変更容易性がほしいような…。
15.2.1 要因1：バグを埋め込みやすくなる
15.2.2 要因2：可読性が低下する
- うーん…15.2.1と同じことをいっているような……？
15.2.3 木こりのジレンマ
- これ、刃を研ぐ時間がどれくらいかによると思うんです…。
- 研師に出して、1週間かかるとか言われたら、場合によっては待てないかもしれない…。
- 自分で30分研ぐだけなら、やりそうだし…。
- 木こり、そんなに急いで仕事をしているイメージがないし、自分の成果が収入に直結してるから、研ぐだろっていう違和感が…。
- 木こりを雇っている
- あんまこのたとえ、好きじゃないや…。
15.2.4 一生懸命仕事した感覚だけが残って生産性は悪いまま
15.2.5 国家規模の経済損失
- 1人1日3時間…！例えが極端過ぎません…？
- 8時間労働のコードをどれくらい書いてるかって言ったら…6時間あったらいいほうでは…？
- とすると、コードを書いている時間の半分以上持っていかれている……。
- …でも、おそらく……技術的負債が蓄積しているときは、測れていないし、測れないと思います…。
- …と書いてきて、ちょっと大げさだけど、最終的には案外あってるのかもなぁ…と思えてきました。
- 複雑で混乱したロジックがあると、もっと混乱した…
- 国家規模で集計すれば、国家規模の損失になるのは…
15.3 ソフトウェアとエンジニアの成長性
- ソフトウェアの成長性
- 生産性の言い換えな気もしますが、ちょっとワクワク感を感じるかも？
15.3.1 エンジニアにとっての資産とは何か
- アレなコードをなんとか使うためにアレな工夫をしても…ということでしょうか。
15.3.2 レガシーコードに人は引きずられやすい
- 既存の動いているものがエライと思っていて、再検討なしにコピーしちゃうときありますもんね…。
- ああ、たしかにレガシーコードと気づくのにはスキルが要りますね…。
15.3.3 レガシーコードは高品質設計を妨げる
レガシーコードは極めてアンバランスでトリッキー
- これはたくさん向かい合ってきての実感でしょうか。
- 自分も実感はありましたが、こんなにしっくりくる言葉に…！
15.3.4 レガシーコードは開発工数を減少させる
- タイトルを見て、
? ってなりました…。
- 必要な作業量のことを工数だと思ってて、思ってたことと反対のタイトルでした。
- レガシーコードのお守りのせいで、本来の開発に割ける時間が減っちゃうって意味でした。これはめっちゃわかります…！
- これのせいで、スキルを伸ばせなくなる！というのも、まぁ、なるほど…。
15.4 課題を解決する
15.4.1 課題が見えないとそもそも設計する意識が生まれない
- 「知覚できなければ」と言いたいのはわかりますが……ううむ……。
15.4.2 知覚容易な課題と知覚困難な課題がある
- 技術的負債は見えないマイナスの価値…。
- わかる…。どうやって説得したもんか、みたいな位置ですよね。
15.4.3 理想形を知ってはじめて課題を知覚できる
- 突然の空手ですが…いいこと言ってますね！
- 理想的な形をちゃんと描いてみるのは、やったほうがよさそうです。
- クソリプかもですが…
- 矢印の長さは揃えてほしいですね…。
- 数学とか物理では長さが値の大きさを表してたりしますから…。
- 相手を地面に対して平行に、自分より遠ざけようとしている前提をちゃんとしたほうが…。
- 殴った威力だったら、接触面に垂直ならよさそうですし。
- 空手の正拳突きは、押し返されないように足腰も使ってたりしてそうなので、結局まっすぐ打つのがいいと思ってますが、ここの図ほど簡単じゃないのではないのかなって思いました…。
15.4.4 変更容易性を比較できないジレンマ
15.5 コードの良し悪しを判断する指標
- メソッド行数とかいろいろありそうですが…みんな、普段どんなものを指標にしているんでしょう…？
- 静的解析ツールを入れていますが…可視化まではやってません。
- 見てたら結構rubocopにありますね…。全体を対象にした警告数をメトリクスにしてもいいかも。
- 整地部…！この活動いいですね…。
15.5.1 実行可能コードの行数
- スコープごとに上限を設定するとたしかに良さそうです。
- rubocopにありました！
Column クラスを分割すると読みにくくなる？
- なるほど…分割した先が信頼できなければ、分割した先を気にしなくてはならず、それならファイルがまとまってたほうが読みやすいだろ？と…。
- 適切に小さく、ちゃんとした名前で分割して、十分にテストしとけってことですね。そうすれば忘れちゃえるよ、と！
15.5.2 循環的複雑度
15.5.3 凝集度
- 度とはついていますが…
- ABCでもいいかしら…。これならrubocopにあるし。
15.5.4 結合度
15.5.5 チャンク
- rubocopのMetrics/MethidLength、Metrics/BlockLength、reekやflayの警告でも出るようです。
flayは知らなかった。コードの類似性を見てくれるんだって。めっちゃ、よさそう！
github.com
15.6 コード分析をサポートする各種ツール
15.6.1 Code Climate Quality
-
- 自分たちで揃えるより楽かなぁ、入れてみようかなぁ…。
- codeclimate.com
- Rubyで使えるのかなぁ…。だったら試してみたいところだけれども…。
15.6.3 Understand
- 初めて聞きました。品質改善に集中的に取り組むときにだったら入れてもいいかも…。
Column シンタックスハイライトを品質可視化に利用する
- なるほど…コードレビュー用にシンタックスハイライトの色合いを変えるとかしてみたい気持ちになりました。
15.7 設計対象と費用対効果
15.7.1 パレートの法則（80:20の法則）
- どうやってあぶり出し方たもんか……。
- 変更が多いところを改善するとか、変更に合わせて少し改善を入れるとか、そういうことですかね…。
15.7.2 サービスの中心的領域、コアドメイン
15.7.3 重点設計対象の選定にはビジネス知識が必要
- うーん、何をすればいいとか書いてあるわけではないんですね…。
- 自分がやってるのは、運用してるひとにいろいろ訊いて、自分が詳しくなることとか、かなあ…。
- ドメインエキスパートがいないことが多かったので…。
15.8 時間を操る超能力者になろう
- おもしろい言い方…！
- 操るための工数は…コードのメトリクスの悪化とかよく言われている値からの乖離とかから説明して得る感じですかねえ…。
- 操るぞ！という気概を持って、事に取り組むのはいいことな気がしてきました！
