第７章 法則 ～プログラミングのアンチパターン～
7.1 ブルックスの法則
要員追加は「火に油」
- これ、まだやるひといるの…？
- チームに入って即動けるひとなんて、そんなに慣れるのに時間かかるのはわかりそうなもんですが…数値だけ見るとできそうになるのか……。
- どの立場のひとが言い出すんだろう…？
「人」と「月」は交換不可能
- この「交換不能」について理解することは、人月の交換を迫られたときにちゃんと説明してあげるためにいりますね。
リスケジュールせよ
- まぁ、遅れているプロジェクトはリスケしかないか…。
- リスケと合わせて、教育期間を考慮しての人数追加ってどう…？
- 遅れているプロジェクトはリスケしかないが…リスケが許されないので、無理して人員追加しようとしているような気もしていて……。
生産と出産のアナロジー
- たしかに絶対必要な時間までは縮められませんねw
- 1億人でゲームを開発したら、明日リリースできる…わけないよね。
「人」と「人」も交換不可能
- たしかに、初心者たくさんと上級者ひとりを比べりゃ、交換が難しいことがわかる…。
- 中間は…判断が難しいですよね。どうするんだろ…？
アンチパターン
その他
- ja.wikipedia.org
- 例外的なものがあれば知りたいです…！
- 高度にコンポーネント化されたものは、イケそう。
7.2 コンウェイの法則
コンウェイの法則
- こんなに大きなプロジェクトに参加したことがないので、なんとなくそうなのかなぁ…という気持ち。
- 読書会で大きな組織にいたことのあるひとからの経験談を熱望…！
アーキテクチャはコミュニケーションに従う
- なんとなくわかる…。
アーキテクチャ設計後に組織編成せよ
- なんとなくわかる…。
- これまでの読書会でたびたび、組織を再編成したほうが…といった話の原点かも。
組織とプロセス
- あ、こりゃそうだ…。
7.3 割れた窓の法則
悪いコードは「蟻の一穴」
- 悪いコードのほかに、落ちたままのテスト、通らないままのCIなども…。
悪いコードは邪心を引き出す
- 邪心を引き出す…はまさにそうですよね…。
コードは「清潔」に保つ
- レビューやツールによるチェックが発達してきてる今は、スコアで出るんである意味やりやすくなった気がします。
人は人を真似る
- まぁ…わかる……。
7.4 エントロピーの法則
コードは自然と腐っていく
- 「腐っていく」という表現はあんまり好きじゃないんですが…他にいい言い回しがなくって。
- 使われないアプリケーションは…「腐らない」ので単純な時間ではないんですが…うまく言えません💦
- コメントとコードが嘘をつき始める…これは腐ってきてると言ってもいいかも…。
- コメントが間違ってたり、メソッドやクラスの名前が役割と違ってくると、もう目も当てられない…。
コードは無秩序へ向かう
- 無秩序に向かうのは、ビジネスの変更に対して、既存のサービスと整合性を取りながらの変更であることが大きな原因じゃないかなあ…。
- 整合性について、企画段階で忘れられがち（経験上）
コード腐敗の兆候をつかむ
- 現状Webアプリケーション開発なので、移植性にそれほど気を配らなければならないことが多いです。
- OSやミドルウェア、開発言語その他多くのものの作者たちに感謝🙏
- 複雑さに対して、不要な要件を削除したり、既存のものを廃止したりと、開発者以外とも連携を取っていくのがいいと思っています。
アジャイルで腐敗を許さない
- 要件から実装、テストあらゆるものに対してシンプルを心がける、テストをしやすくするあたりが一番気をつけているかも。
チーム文化で腐敗を許さない
その他
- うちでは…
- 開発している箇所の近隣を少しきれいにするように心がけてます。
- コーディングエージェントを使って、気軽に小さい範囲のリファクタリングさせるのもありかも。
- 小さいが重要…。
- 大きくすると、混乱を運んでくる可能性が…。
7.5 80-10-10の法則
プログラミングに万能薬はない
- んー…プログラミングは万能薬ではない、のほうがしっくり来るんですが…どうだろう…。
プログラミングの問題領域は広すぎる
- 提供されるものですべて賄えるなら、そりゃおまんま食い上げですわ…。
- 実際の業務とツールなりなんなりの間を結びつけるのが、仕事でもありますね。
ツールの使用は適材適所
- なんでもツールは…自分もどうかと思います。
万能薬より専門薬
80:20の法則
- 所得の話はえげつないですね…。
その他
- 80:10:10 もいろいろな場面で適用されてるんじゃない…？
7.6 ジョシュアツリーの法則
名前がないものは見えない
- この話、ノンデザイナーズ・デザインブックでも読みました！…と思ったら、出典でした。
名前を知ることで存在を知る
- 特徴は覚えてても…名前を忘れちゃうんですよね……。それでも一応見えるんだけども。
- 繰り返し使うしかないかぁ…。
- 名前を知ることで、存在を認識し、共有できるのだったら…チームで読書会をするのは理に適っているのでは…！
ユビキタス言語を使用する
- そう…わかるんだけど、メンテナンスが……><
バベルの塔
- この話、おもしろい解釈だとは思う…。
7.7 セカンドシステム症候群
２番目のリリースは機能過多
- そうですね…。
慣れると「多機能主義」へ
- これも確かに…。
ユーザーを考える
- うーん、いつもやってるつもりではありますが…昔どうしてたっけ…？
- いつのころからか、だれがどんな場面で使うのかをイメージするようになってました。
- ウチの会社では、リソースが少ないこともあって、同じように考えてくれてると思うんですが。
- …ほかの環境のときには気をつけないとダメかも。
セカンドシステム以降症候群
- 無駄な多機能化……撤退が大変だから……。
- 使う場面をとにかく意識してます。
フィーチャー・クリープ
- シンプルさ…これにつきますね。
7.8 車輪の再発明
既にあるのに作る
- 標準ライブラリにあるのに作っちゃう…？それは…なかなかないかも…。
「車輪を知らない」「車輪を作りたい」
- 「車輪を知らない」…は現状だとどうにもならないかなぁ…。よく調べるしかない…。
- 仲間が増えれば、その分目が増えるので…期待。
- 「車輪を作りたい」…個人でやります！
「車輪」以外に注力する
- 車輪以外にすることいっぱいあるんですよ、そもそも…。
車輪を再発明すべき時
- ビジネスの核なら…そもそも革新的な何かがあるんじゃ…？実装しない理由がよくわかんない…。
- 学習は学習だから…やるよね。
7.9 ヤクの毛刈り
本当の問題にたどり着かない
- ja.wikipedia.org
- ヤク…そういえばちゃんと知らないや…。
- 大きく言えば牛の仲間で、バイソンと近い、と。
- アジアの山奥にいる…え？
- ja.wiktionary.org
- なんか2つの意味が書かれてますね…。
- 本で紹介されてないのは、問題を解決するために一見必要のない行為。
- なんか2つの意味が書かれてますね…。
- ヤクはアメリカでは全く身近じゃないそうで…それゆえにジョークになったのかも。
トラブルは芋づる式
- トラブルなんだから…芋づるだし、フラストレーションはたまりますよね。
早々に切り上げる
- 適当なところで、立ち止まって考えなおすのは大事ですね。
「ヤクの毛刈り」に立ち向かう
- 最近はissueベースだし、毎朝の共有が必然的に考え直したり、書き留めたりするきっかけになってて…悪くないです。
プログラミングの「ヤクの毛刈り」
- 思考ループは…まぁ、ありますね…。
- 回ってきたなと思ったら、メモを始めてます…。
あとがき
ケアリング
- コードを読む人、めっちゃ気をつけてる…。
- 長く務めることが多いので、結局自分であることが多いのも、その理由ではあります。
- コードを読む人、めっちゃ気をつけてる…。
道徳法則
- 「使いやすい」はいつも気をつけています。
- お問い合わせが来て、結局自分のところに質問が来るから…というのもあります。
- 「使いやすい」はいつも気をつけています。
メソテース
- issueやpull requestに背景というか何を解決したいとかいう情報をなるべく盛り込むようにしています。
- それを書くようにすることで、バランスを取るための情報を集めている感じです。
