ルールズ・オブ・プログラミング読書会vol.26
https://scrapbox.io/files/655372c161a776001bf71cc6.jpeg
開催日時
2025年1月14日(火) 19:30~21:00
開催URL
参加人数
3人
ウォーミングアップ
ルール11 2倍よくなるか
単純な経験則
二倍よくなるか
2倍よくなるなら作り直すこと許容する
仕事じゃなければ「こっちの方がかっこいい」で選択することがある
仕事でも「こっちの方がきれい」で選択することはある
計測可能な場合
3人月分
わりと軽いコストに見える
3人でやって1か月
100人月でもやるの?
その100人月を別に割り振った時の品質の高さと天秤にかける
100人月が100人月でおさまることない
1人でやったら8年の作業!
3人月くらいが見積れる最大?
1週間で見積って2週間で出来たら御の字
一番確実な見積もりは一度作って完成させる
2倍よくなるかも知識がないとわからない
曖昧な便益の扱い
OfficeやiOSを2倍よくできるの?
今までめちゃめちゃ積みあがったものをさらに2倍よくするって難しくない?
ものさしをさそうとすること自体に価値がある?
Officeでも起動時間が1/2になったから価値があるのでは
↑もともと0.1秒で立ち上がるものが0.05秒になってもうれしくない
この判断基準はいつ適応する話なのか
なにかきっかけがあって迷った時の判断基準
設計上の限界に達して行き詰ったとき
問題になっていない時にはこの判断基準は出てこない
0.1秒起動はすでに十分早くて問題にならない
作り直しは、小さな問題の修正にうってつけの機会だ
Gitでは1つのコミットに1つの問題解決を行うべき
パッチパッチでごまかしてきたけどごまかしきれなくなったら作り直すイメージ
積もり積もって作り直すと2倍よくなる
パッチでテストケースを通してきたが、作り直しで根本的に直してテストケースを通す
フィボナッチ数列の例
n=1,n=2, 3<=nの時という感じでif文で分けるよりも一般項で書いた方がすっきりする
if文で分けて増やしていくのがインクリメンタル
一般項で表すのが作り直し
速度がこっちの方が早いから採用
副次的にn=1,n=2のif文が消せる
この一文だけ話の流れとまったく違うこと言ってる
コミットの粒度についての議論
とりあえずめちゃくちゃにコミットしてからリベースして成形していく
一度出口までのルートを見つけてからコミットを整理する
マイクロコミット
git add -pの話
eで途中の変更のdiffを作る
git add -pを途中で抜けるのめんどくさい
ルール12 大きなチームには強い規制が必要
次回ここから
お悩み雑談室
作業見積もりってどうしてます?
未着手状態ならカン
過去の経験からの推測ではある
着手してよければその進捗の傾きから推測する
バグ修正の場合はひらめき
ひらめかなければ進まない
根本原因を調べる
見つけたからと言って直せるとは限らない
インタフェースの責任を調べてここだ、という場所で修正する
モジュールの気持ちになって考える必要がある
私の考える正解と異なる場合がある
アルゴリズムのバグだと実際に計算して確かめる
ログ出力すると出ないバグ
別スレッドで定期的に変数をprintしたりした
ログ出力自体が重かったケース
ログ消したら早くなった
わかんないからどんどんログを足してさらに遅くなったという笑い話
通信が10msとかめちゃめちゃ短時間で終わった
最適化で計測範囲がずれた結果だった