リファクタリング ハーネス

ハーネスエンジニアリングで過去のフリーソフトをリファクタリングしてみました。

Transcript

1. @kanayannet リファクタリング ハーネス Gunma.web #60
2. 前提1 2007年くらいに ruby の勉強がてらに配布したblogがあった ruby 都度コンパイル型CGI フリーソフト 今時にしたい ただし、自分でコードを打ちたくない
3. どんなもん？ https://github.com/kanayannet/Weblog http://localhost:8888/cgi-bin/Weblog/weblog.rb
4. 前提2 「ハーネス エンジニアリング」とやらがある 「仕様駆動開発」との違いがイマイチ解ってない
5. そうだ こういう時こそ、勉強がてらにフリーソフトを修正してみよう ハーネスエンジニアリングで
6. まずは調べる
7. 成果物 rule plan まずはここからだな。
8. 何でやろうか？ 前回、cursor をみて良さそうだったので、cursor でやるか ハズレはないだろう。
9. plan, rule を作るか？ README.md に要件定義をざっくりと定義して... AI に 作らせた(雛形を期待)
11. ざっくりと要約すると... 横幅広げたい オレオレ記法やめたい markdown で書きたい 軽量FW(sinatra)にしたい RDB まではやりすぎ textファイルのまま trackback いらない...orz
12. 次の案内も出してくれる すげ〜
13. 作られた plan どんなもん？ https://github.com/kanayannet/Weblog/blob/harness_test/plan.md
14. 矛盾があると指摘してくれる うっかり trackback 要らない旨を書き忘れた
15. なかなかいい感じ..だが
16. 問題発生
17. 何をやっても pro plan 誘導...orz
18. 当日はとある画像 大人は嫌いだね！ 無料で使わせる気なんてない癖に！
19. 仕方なく... 課金(月額 4000円弱くらい)
20. 課金したので..色々用心するように 初期は composer 2.5 だった 固定にしたら高そうだし... AI model 色々迷ったけど..
21. Cursor の auto を発見 これがいんじゃね？ Balanced quality and speed とある
22. 使えるようになったので 気を取り直してnext
23. マイルストーンも作ってくれた
24. M0 穴埋めのクロスチェックもAIに
25. 無自覚にやっていたけど
26. 比較的うまくいく やり方 ステップを細かくして... 人とコミュニケーションを取るのに苦にならない粒と同じ 確認をまずはAIにする(チェックさせる) AI と認識合わせ 漏れがAIと共通認識であると確認 AI に直させる -> こっちでレビュー
27. こんなアルゴリズム while NG NG が消えるまで直させる next step
28. Red -> Green -> Refactoring... まるで...
29. 頭の使い方が TDD
30. お互い慣れてくると... 多少アバウトでもやってくれる
31. リアル会場ではとある画像 よしなに...
32. 注意 実際は、それなりに言語化して「よしなに」と言っても 勘違いしないくらいには定義してますw routing はこっち(人間)で入力 template file名を routing の命名に沿って入力させた
33. 漏れがないか？もクロスチェック
34. ご丁寧に対応表も用意してくれる
35. M0 finish M0 は要件定義 や 用語など決める plan, rule を仕上げるステージ plan や rule を 10回以上書き直している。 正直ここが一番長かった。 「すぐコード」に行きたがる方や「すぐ動くものが見たい」方はキツイかも..
36. M1 に進む... 無言の修正...orz 終わったとか次の指示がない..謎
37. エラー 終わったっぽいので起動するが...
39. さっきのは何だったんだ(謎) 今度は直してくれて、案内が出た
40. M1 は不具合との戦い
41. どうにか不具合の嵐を抜けて...M2 へ
42. 実は...ここから先は M1 のような不具合ラッシュはないです。 M2 予想: M1 でかなり癖を掴んだんじゃないのか？
43. これだけ M2 どのくらいで済んだか？
44. M2 finish
45. 不具合と思いきやこっちの見落とし M3 もあっさり完了
46. M4-M5 もあっさり完了して...
47. 動くようになったけど？
48. 要らないファイルがたくさんある
49. Git の調整も 削除もAIにやってもらった
50. 完成 http://localhost:9292/
51. 管理画面内 ボタンの歯抜けはあるものの markdown で動く状態w
52. やってみて感想 この規模感のフリーソフトでも、plan, rule はまあまあ長かった 不具合も普通に出るし、直すのもまあまあかかる 人よりは短めだったが...
53. 何年も使ってきた「秘伝のタレ」 が多いシステムはどうなるか？ クロスチェックが抜けたら..とんでもない方向に行きそう。 偽真な情報を見抜けるか？が鍵 Hallucination
54. 予想: 規模が大きい場合 全部を一気に入れること自体無理ゲーでは？ 人が plan を把握 input できなくなる認知限界が来そう サーバリソース管理、特殊処理を考慮してくれなそう あえて、汚く書かざるをえなかった処理 -> 負荷対策 更新系バッチ処理(常時更新は負荷がかかるので) -> 見落としそう
55. 人(AIも)は見落とすし、ミスをする と深く気づいている人は...今回の最初期のように...
56. 「分解」して進めるのでは？ サービスの区切れ目 疎結合で済みそうな箇所の特定 マイクロサービス化 適切に切る時の一つの手法 やりすぎてもよくないが... 狭間にある業務知識が増える transaction 費用++
57. コミュニケーション ハッキリと表面化してくる コーディングで苦戦するステージは少なくなる 苦戦するステージが移動する ドメイン(業務)知識を得る場所に すなわちコミュニケーション
58. まとめ 言葉による定義を...少しずつ進めることが大事 一気にやると人間が付いていけない 定義自体から少しずつ 感覚は... TDD に近いが、もう少し付け加えると...
59. TDD の進め方で ペアプロ・レビューしてる気分
60. 人との違いを言うと... 高速で読み込んで 高速で理解して 高速で書く 高速で直す input 外は察してくれない
61. 人と同じ部分 勘違いある 実装ミスもある
62. 少しづつ、インクリメンタルに...
63. まとめ2 AI を使いこなせる人になるには？ AI を使いこなせる人を増やすには？
64. 結局「受け身」の開発は向かない ここは今までと変わらなく見える 言われたことだけ実装... これだと厳しい
65. 今までよりも...
66. レビュー・テストのつまずきが目立つ コーディングのスピード感より 要件定義(ゴール)がボヤけていると
67. ドメイン(業務)知識を得るために コミュニケーション重要
68. 話を元に戻して...
69. 折角なので harness_test branch で切ってup https://github.com/kanayannet/Weblog/tree/harness_test
70. リアル会場ではとある画像 もっと「よしなに」やりたくなってきたw
71. ご清聴ありがとうございました。