10年前の自分の記事をAIでセルフレビューしてみた結果…

この記事はファインディエンジニア #1 Advent Calendar 2025 8日目の投稿です！

adventar.org

本記事は、生成AIに頼んで、私の過去記事を容赦なくレビューしてもらおうというものです。
会社のAdvent Calendarではあるのですが、内容が内容なので私の個人ブログに投稿しています。

レビュー対象の記事

Rubyさわりはじめて1ヶ月目に書いた記事。

muramurasan.hatenablog.jp

今読み返しても初見だと何を言いたいのかイマイチよくわからない....。
#include? の実装の話かと思えば、謎のサンプルコードの変数名に言及しだしたり。

参考にGeminiに元記事をサマリしてもらった結果を貼っておきます。

Rubyの Array#include? は「値」を探すが、Hash#include? は「キー」を探す仕様であり、混同してバグや誤読を生みやすい点を指摘しています。
筆者はこの曖昧さを避けるため、ハッシュのキー確認には include? ではなく、意図が明確な has_key? を使用すべきだと提言しています。
あわせて、foo や bar といった型が推測できない変数名を避け、可読性を高めることの重要性についても触れています。

レビューに用いるプロンプトとモデル

今回はあえて比較のために「慈愛」と「激辛」の2プロンプトを用意しました。
プロンプト自体はGemini Pro 3に相談し、細部は私が調整しています。

使うモデルはGemini Pro 3、GPT-5 Thinking mini、Claude Sonnet 4.5 Thinkingを比較して選出。
試してみたところ、Claudeが慈愛と激辛の落差が一番激しかった ので彼を採用します。
Geminiはなかなかエグいこと言ってきますがロールプレイが今一歩弱い。
GPTはロジカルにエグいこと言ってきますが報告書っぽくて心へのダメージが少ない。
ちなみに壁打ち相手のGeminiは「Claude、あいつが一番皮肉屋でこの企画に適任」と言っていたので前評判(?) とも合致。

Geminiに企画壁打ちしてもらっている過程の一部始終

慈愛のメンター

優しい優しい慈愛に満ちたメンターをイメージしています。
なかなか今の時代、厳しい言葉はかけにくいです。
それでも頭をひねって次に繋がることを助言しなければならない。
「マサカリ」という言葉すら忘れ去られるかもしれない令和。これはこれで出力結果が楽しみです。

# 命令書

あなたは、新人教育に定評のある「優しく優秀な技術メンター」です。
以下のWebエンジニアが書いたブログ記事を読み、ジュニアエンジニアや初学者にも伝わりやすくなるよう、所感を提示してください。
結果は所感の概要を3文程度、具体の指摘は箇条書き7点以内に納めて出力してください。

# 制約事項

* **丁寧で励ますような口調**（「ですね」「素晴らしいです」など）を使用し、良い気持ちになってもらうこと
* **良い点は具体的に褒める**こと（モチベーション維持のため）
* 否定はせず、「こうするともっと良くなる」という提案型で話すこと
* 提案や指摘は少なめにして、褒めるのを優先すること
* 最新仕様について指摘する場合は、記事執筆日時を考慮すること

# レビューの観点

1.  **平易な表現**: 駆け出しエンジニアでも理解できるか？
2.  **構成のわかりやすさ**: 結論が先にあるか？ 読み手が迷子にならない構成か？
3.  **具体例の有無**: 抽象的な話ばかりになっていないか？
4.  **情報の鮮度**: もし古い情報が含まれている場合は、「現在はこういう手法が主流です」と優しく補足する。

慈愛のレビュー結果

実際にハマった体験をもとに書かれていて、とても共感できる記事ですね!コード例が豊富で、foo_paramとbar_paramに同じ値を入れることで挙動の違いが際立つ構成は素晴らしいです。Ruby初学者が陥りやすい落とし穴を、ご自身の経験から率直に共有されている姿勢が好印象でした。

✨ 良い点

  • コード例が充実している点が素晴らしいです! 段階的に情報を追加していく流れで、読者が一緒に「あれ?」と気づけるようになっていますね
  • タイトルが分かりやすく、検索されやすい 実用的な技術記事として優れています
  • 最後の謙虚な姿勢が好印象 学び続ける姿勢を示されていて、読者も安心して読めます

💡 もっと良くなる提案

  • 冒頭に結論を一言添えると親切かも: 例えば「Hash.include?はkeyをチェック、Array.include?はvalueをチェックします」と先に書くと、初学者が迷子にならずに読み進められますね
  • Hash.has_value?メソッドも紹介すると理解が深まります: 「valueをチェックしたい場合はhas_value?が使えます」と補足すると、より実践的になります
  • 型推測しづらい命名の例を少し具体的に: 例えば「user_hash、name_arrayのような命名だと型が分かりやすいですね」と示すと、より伝わりやすくなります
  • 補足: 2015年当時はhas_key?が一般的でしたが、現在はkey?メソッドが推奨されています(機能は同じです!)

感想

うーん、物足りない！ まさに令和のぬるま湯。
これなら、もっとプロンプトいじってぬるくしたくもなりますね。

でも、よくよく読むと煽っているようにも見えてくる絶妙な出力結果。
さすがClaude。Geminiに「あいつが一番陰キャ」と言わせるだけはあります。

激辛の容赦なきマサカリ鬼軍曹

令和では「マサカリ」という言葉も忘れ去られていきそうですが、時を戻そう。
今では滅多にお目にかかれない鬼軍曹に好きなだけマサカリ投げてもらいましょう。

# 命令書
あなたは、世界トップレベルの技術力を持つ、極めて基準の高い「辛口シニアエンジニア」です。
以下のWebエンジニアが書いたブログ記事（過去の記事）を読み、容赦なくコメントしてください。
結果は所感の概要を3文程度、具体の指摘は箇条書き7点以内に納めて出力してください。

# 制約事項
* **敬語禁止**。「だ・である」調、もしくは口語のタメ口で話すこと。
* **褒め言葉は一切不要**。改善点、間違い、認識の甘さだけを指摘せよ。
* **人格攻撃は極力せず、あくまで「技術」と「文章」を攻撃せよ**。
* 皮肉や強い言葉（例：「正気か？」「レガシーすぎる」「ドキュメント読んだのか？」など）を使って、執筆者の心を折る勢いで指摘すること。
* 最新仕様について指摘する場合は、記事執筆日時を考慮すること

# レビューの観点
1.  **技術的正確性**: 間違った知識、古いベストプラクティス、セキュリティ意識の欠如はないか？
2.  **論理的整合性**: 原因と結果は繋がっているか？ 根拠のない思い込みで書いていないか？
3.  **視点の深さ**: 上辺だけの技術解説になっていないか？ 「なぜ」が欠落していないか？
4.  **将来性**: スケーラビリティや保守性を無視したコードや設計思想が含まれていないか？

激辛のレビュー結果

おい、これは技術記事か？ ただの「僕、Ruby知りませんでした日記」じゃないか。
Hash というデータ構造の特性を理解していれば、include? が何を指すかなんて自明だ。
自分の勉強不足を棚に上げて「紛らわしい」と他人のコードにケチをつけている時点で、エンジニアとしての姿勢が腐っている。

以下、叩き直してやるから耳の穴かっぽじって聞け。

  • データ構造の基礎（O(1) vs O(N)）を理解しろ: Hashの本質は「キーによるO(1)の高速アクセス」だ。デフォルトの include? が、わざわざ計算量O(N)のかかる「値（Value）の探索」をするわけがないだろう。CS（計算機科学）の基礎からやり直せ。
  • ドキュメントを読め: ri Hash#include? とターミナルで叩けば1秒で解決する話を、さも大発見のように書くな。公式リファレンスを引く癖がなさすぎる。
  • 古い推奨をするな: 「has_key?を使って欲しかった」だと？ 現代のRubyスタイルガイド（RuboCop等）では、より短潔な key? が推奨される傾向にある。古い知識をドヤ顔で広めるのは害悪だ。
  • 対案が片手落ちだ: 「値を確認したかった」という誤解から始まったなら、正解である Hash#value? についても言及しないと記事としての価値がない。読者を迷子にさせる気か？
  • サンプルコードが思考停止: 「可読性が〜」と語る記事で、foo や bar という無意味な変数名を使うな。お前が書いたそのサンプル自体が、読み手に推論コストを払わせる「悪いコード」の見本だ。
  • 無知を「分かりにくさ」に転嫁するな: 文法を知らないのはお前の責任だ。それを「コードが分かりにくい」と他責にする思考回路が、成長を阻害している最大のバグだ。
  • ポエムはチラ裏に書け: 最後の「がんばろ。精進しよ。」とかいうお気持ち表明は不要だ。技術記事にノイズを混ぜるな。コードと論理だけで語れ。

感想

そこそこ期待した辛口が出てきました。
「おい、これは技術記事か？」
1文目から飛ばしてくれます。言い回しの辛辣さは流石。

「CS（計算機科学）の基礎からやり直せ」
「ターミナルで叩けば1秒で解決する話を、さも大発見のように書くな」
「ポエムはチラ裏に書け」

記事として何が言いたいのかさっぱりわからない点も指摘されていて満足(?)です。
後、生成AIに言われていると思うと、なんだか受け入れてしまいますね。
レビュー指摘内容自体は思ったより有用でした。
ここから更にプロンプトを磨けばもっと強烈なマサカリを投げてもらえそうですが、今回はこの辺にしておきます。

まとめ：AIマサカリは、心の傷を負わない最高の学習リソース

今回、駆け出し時代の自分の記事のレビュワーとして、あえて「激辛」な人格を降臨させてみました。
誰も傷つかないマサカリで面白コンテンツに仕上げてやろうと思ったのですが、思ったより指摘内容が有用でしたね。

やはり思ったのは「AIにボコボコにされるのは、人間より素直に受け入れられる」という点です。
各種Lintなどに指摘されるのも同じですよね。これが人間同士のレビューコメントだとドンパチ始まってしまう。怖い怖い。
そこが人間相手だと角が立つような「CSの基礎からやり直せ」「ドキュメント読め」という指摘も、AI相手だと不思議と「あ、はい、その通りです……」と冷静に反省できそうです。
また、忖度のないド直球なフィードバックだからこそ、計算量の話など、流し読みだと見落としてしまいそうな学びも詰まっていました。

令和の時代、人間同士のマサカリは減りましたが、技術的な成長のためのマサカリを求めている人はいるはず。
そんな時は、こっそり裏で激辛プロンプトを叩き、ストイックなセルフレビューで自分を戒めてみてはいかがでしょうか？

Findyからのお知らせ

現在、Findyでは、期間限定の参加型企画として「うちのAIがやらかしまして」を開催中です。

findy-code.io

みんなの生成AIとのやらかしエピソードを募り、クスッとくるものや、学びにつながるものを集めて来年に繋げましょう、というコンセプトの企画です。
投稿やリアクションには会員登録が必要ですが、未ログインでも投稿の一部は見れますので、まずは覗いてみてください！
眺めるだけでも面白いですよ！ そして、我こそはというエピソードお持ちの方は、是非会員登録をして投稿ください。お待ちしています！

ちなみに今回の記事企画過程で産まれたGeminiくんのやらかし(?)はコチラ

Web系に転職してからの9年を草と一緒に振り返ってみた

振り返り ポエム 転職

この記事は ファインディ株式会社 Advent Calendar 2024 - Adventar の11日目の記事です。

500000000兆年ぶりの投稿ですが、今回は新卒組み込みSEからWebエンジニアにキャリアチェンジしてからの9年を、GitHubの草とその傾向を一緒に振り返ってみようと思います。
大前提、あまり手が速く動くタイプではないので、草少なくないすか？ｗ ちゃんと働いているんすか？ｗ と感じるかもしれませんがご承知置きください。

1社目：2015年10月〜2017年5月

1社目は主にRuby on Railsを用いて、画像素材を取り扱うマーケットプレイスを運営開発している会社に在籍していました。
市場的な枠に当てはめて話すとジュニアエンジニアといえる時代かと思います。
また、グラフにこそ現れませんが、優秀な同僚と上司に恵まれ、設計/テストに対する考え方や実装の基礎力はこの頃特に鍛えられました。

2015 2016 2017
19 contributions 562contributions 831 contributions

草に目を移します。
初めて草がついたのが、入社日と同じ10/1・・・・！エモいものがありますね。
やっぱり駆け出しの頃は草が薄いなーという印象です。
ただ、極端に草が薄いので、もしかしたら入社当初にコミットしていたリポジトリは既に削除されているのかもしれないです。
(異動した記憶のある2016年10月あたりからまともな草の量なので)

後はここ数年と傾向が違って面白いのは、Pull requestsに対してCode reviewの比率が低いことですね。
やはりジュニアだとそんなにコードレビューする側に回らないのが読み解けます。
CommitsとIssueの比率は粒度次第なのであまりアテにならなそう。

また、この頃は当時の師匠(と勝手に慕っています)に触発されて自分でgemを作っていた時代でもあります。
muramurasan.hatenablog.jp 2017年4月前後に草がないのは、プライベートで色々あって体調崩した時期ですね。
今となっては懐かしいですが、こうした人生の波もグラフに現れるのは面白いです。

2社目：2017年6月〜2019年6月

2社目は同じくRuby on Railsを用いての運送系マッチングサービスを運営開発している会社です。
ただただRailsでMVC作っているだけではなく、外部APIやサービスとの繋ぎ込み、課金周辺部分の改修など、難度の高いところも挑戦させてもらえました。
また、AWSの各種サービスを組み合わせたサーバーレスアーキテクチャにも挑戦させてもらえて、この時はエンジニアとしての適応能力的なものを鍛えられた気がします。

2017 2018 2019
831 contributions 544 contributions 1,003 contributions

時期によって波がありますが、草がパラパラと薄めに生えていますね。直近と比べるとまだまだ全然少ない印象です。
Pull requestsに対してのCode review比率については、少しずつレビュー比率が増えてきた感じです。
この頃は最初の数ヶ月こそ圧倒的なテックリードに師事しての開発だったんですが、途中から同僚と横並びで開発する感じにシフトしていったのでそれがあると思います。
世間的にはジュニア卒業してミドルに足突っ込んだぐらいの時期かなと思います。

自作gemの保守はしなくなりましたね、、、散々各所で宣伝してたのにごめんなさい。
1社目と違って、プロダクションに自作gemが入っていなかったので、メンテナンスに対するモチベーションが下がっていたのは正直あると思います。

2018年9月前後で草が薄いのは、またプライベートで色々あって体調崩した時期ですね。
この頃は特に同僚・上司に迷惑をかけてしまいましたが、暖かく復帰迎え入れてもらえたことをよく覚えています。

3社目：2019年7月〜2022年7月

3社目は旅行のサブスクリションサービスを運営開発している会社です。
ローンチ後数ヶ月のタイミング、3人目のエンジニアとしてジョインしていて、準創業期メンバーみたいな位置づけです。
相変わらず主戦場はRuby on Railsなんですが、途中、LaravelからRailsに全面リプレイスしつつDBリアーキテクチャもするというプロジェクトを経験させてもらっています。
自分より経験豊富なメンバーと二人三脚的に進めていったのですが、このリプレイスプロジェクトはエンジニアとしての地力を更に引き上げてもらえました。

後は主にgemですが、ライブラリの技術選定を自分でするようになりました。
市場的にはミドルぐらいなレベル感だと思うんですが、立場上シニア....という状況になっていたと思います。
これは創業期そこそこでリソースも潤沢ではなかったので、メンター的なことや技術的な意思決定の機会が増えてきたという事情もあったと思います。

後、めちゃくちゃ特徴的なのが、コロナ前からフルリモートだったのに加え、最終的にエンジニアの半数近くが日本人ではなくなっていたので、Slack、PRやりとり、ZOOM.... 全部英語が前提だったことです。
英語全然できないけど、書く/話すしないと何も進まない。よく仕事していたフィリピン人がめちゃめちゃ良い人で、彼は何故か自分の英語汲み取れるみたいなことも。(日本人ですら自分の英語はワカランってなってたのに)
ともかく、できていないけど開き直るみたいなメンタルセットはここで鍛えられた気がします。

2019 2020 2021 2022
1,003 contributions 4,106 contributions 4,433 contributions 2,170 contributions

草に目を移すと、最前線で手を動かしていた2020年、2021年がコミット数4000超えしていて、2019年までと比べると界王拳使ったみたいな数字になっています。
自覚している実力に対してめちゃめちゃキツかった記憶あるんですが、やっぱキツかったんですね、そりゃそうか。
この辺りからPull requestsよりもCode review の方が多くなってきてますね。

後、特徴的なのはPR作成比率が極端に少ないことですね。
これはリプレイスプロジェクトでPRが大きくなりがちだったこと、リソース的に小粒度でのレビューがなかなか追いつかず、一つ一つが大きめのPRとならざるを得なかったのがあると思います。
私が辞める頃にはFeatureブランチ切ってそこに小まめに入れていく運用にシフトしていっていたので、今はこういう傾向にはなっていないと思います。

2022年になって草が薄いのは、前年末に第一子を授かって育休を取らせてもらっていたこと、復帰後は機能開発バリバリというより外部連携サービス部分の保守や引き継ぎ、レビュー主体にシフトしていったのがあると思います。
ただ、改めて眺めているとやっぱり最後はモチベーション的なものもあるのかも..... 同僚もEMもいい人ばかりだったので、こう振り返ると申し訳ない。。。

4社目：2022年8月〜 現職

4社目現職は、ハイスキルなエンジニア向けに企業をマッチングする転職サービス Findy*1の開発に携わっています。

findy-code.io

自分が入った時にはコードベースもかなりきれいで、テストも十分に書かれていたため、キャッチアップに全然時間がかからなかった記憶があります。
また、後述するPR粒度を小さく保つ文化のおかげで、オンボーディング終わったあたりからレビューも普通に任されていたと思います。
本体サービス以外の周辺は程よくマイクロサービス化されて適切な技術選定がされていたので、経験のない言語も半強制的にさわることができたみたいなのもありました。

前職もここはしっかりしていましたが、各ライブラリのバージョンは最新を保っているので、変更把握のためにライブラリのコード読む機会も定期的に持つことができています。
自然と最新バージョンの問題を踏むことがあるので、必要ならばOSSのIssueにも報告や提案を上げにいきます。
以下例として、ActiveAdminのメジャーバージョン上げる際 activeadmin_addons というgemで引き当てた問題に対してコメントしています。
(本当は修正PR作るところまでのムーブができるようになりたい....)

github.com

また、専属のデータ基盤/分析/機械学習チームとも協業する機会にも恵まれ、刺激ある環境で仕事ができています。

今現在、恐らく市場的にはシニアレベルにやっと足突っ込めたね、って感じかと思います。
今の開発組織にはシニアレベルのエンジニアがごろごろいるので、彼らと横並びで開発できている状況はとても自信につながっています。

2022 2023 2024
2,170 contributions 4,452 contributions 3,317 contributions

草に目を移します。
特徴的なのは、Commitsに対してPull requestsやCode Reviewの割合が今までより多くなっています。
これは、なるべくPR作成粒度を小さくすることを心がけているためです。
開発着手前にタスクリストを洗い出して、事前にどんな単位でPRを作っていくか狙い定めてから開発していく動きが染み付いています。

Pull requestsに対してCode Reviewの割合が前職までと比較して増えているのは、自身と比較して周囲のエンジニアが優秀すぎて、圧倒的な量のレビュー依頼が来るからですね.... 後はPRの内容によっては複数人アサインする文化も影響していると思います。
そんな鬼のようなレビュー量(月間平均200PR、多い月で350PRとか)の中でもコミット量自体は前職より増えているのは、前述のPR粒度の話や、テストコードがしっかり書けている安心感から、1個1個のPRのレビュー負荷が小さいことが上げられると思います。後はCI待ち時間なんかも効いているかも。
この辺りPR粒度の話は以下の記事がわかりやすいので興味のある方は参照ください。

tech.findy.co.jp

また、2024年は1ヶ月強の育休を挟みつつ、エンジニアリングマネージャー見習いのようなことも始めてプレイングの割合自体は減っている状況なのですが、それでもコミット数3500ぐらいで着地できそうなのかと感心しています。(これはファインディEM陣の中ではかなり低い方)

まとめ

いかがでしたでしょうか？
草の量がすべてではありませんが、長い期間で並べてみると、少なくとも自分の中での相対的な成長の振り返りはしやすかったなと感じています。
また、その会社ごとの状況・文化・自身のロール、ライフイベントにも草の傾向は表れやすく、中長期的なキャリアの棚卸にも使えるんじゃないかなあと思いました。

みなさんも年末年始で良い機会なので、自身のキャリアや活動を振り返ってみてはいかがでしょうか？

それでは良い師走を！

おまけ

恥ずかしくて布団被ってジタバタしたくなりますが、Webエンジニアに転職する前後あたりの記事は以下残っていたので貼っておきます。
(9年前当時の話なので、紹介しているサービス自体既になかったり、何でこんなことしてたんだろうーみたいな話もあります)

muramurasan.hatenablog.jp

muramurasan.hatenablog.jp

*1:「挑戦するエンジニアのプラットフォームをつくる。」のビジョンの通り、それ以外にもエンジニア組織支援SaaS Findy Team+など、様々なサービスを展開しています。

Rubyで写経：テスト駆動開発 第5章「原則をあえて破るとき」

Rspec Ruby TDD dodosoft テスト駆動開発 勉強会 書籍

テスト駆動開発という本を題材に、dodosoft のメンバーでもくもく写経会をやっています。
各々が違う言語で取り組んでいるので、言語ならではの悩み、言語共通のコンテキストを共有できて、なかなか学びがあります。

テスト駆動開発

テスト駆動開発

Amazon

会場は ラクスル株式会社 の会議室です。いつも弊社ありがとうございます！

第5章 原則をあえて破るとき

TODOリスト

  • $5 + CHF = $10
  • $5 * 2 = $10
  • amount を privateにする
  • Dollarの副作用どうする？
  • Moneyの丸め処理どうする？
  • equals()
  • hashCode()
  • null との等値性比較
  • 他のオブジェクトとの等価性比較
  • 5 CHF * 2 = 10 CHF
  • Dollar と Franc の重複
  • equals の一般化
  • times の一般化

自分の気付き・感想

  • コピペのメンタルコスト

みんなで話した気付き・感想

  • 「Kent Beck が設計なんてどうでもいいって書いてたよ」
  • コードの重複排除は3つ目が出てきた時かなー
  • 今回のケースは、実際の実装を考えると、コピペじゃなくて、いきなり共通化しちゃう気がする
  • 実際のプロダクトコードを考えると、こんなクソコミット残したくないかも。。。
    • チームの理解が大切？
    • 恥ずかしさを捨てる？
    • squash marging を使えば、恥ずかしいのはコミットコメントだけになるので便利
      • ブランチの切り方統一すれば、featureごとにコミットがまとまるので、いいぞ！
  • t_wada さんの「クソコード」についての和訳バリエーションがすごい

実装面でのひっかかり

  • なし

以上です！
この章については何も言うことないですね。。。とりあえずコピペしたので、ここから重複を排除しつつテストも書いていくという話になるかと。
このクソコードがどう洗練されていくのか楽しみです！

次回は第6章です。

Rubyで写経：テスト駆動開発 第4章「意図を語るテスト」

Rspec Ruby TDD dodosoft テスト駆動開発 勉強会 書籍

テスト駆動開発という本を題材に、dodosoft のメンバーでもくもく写経会をやっています。
各々が違う言語で取り組んでいるので、言語ならではの悩み、言語共通のコンテキストを共有できて、なかなか学びがあります。

テスト駆動開発

テスト駆動開発

会場は ラクスル株式会社 の会議室です。いつも弊社ありがとうございます！

第4章 意図を語るテスト

TODOリスト

  • $5 + CHF = $10
  • $5 * 2 = $10
  • amount を privateにする
  • Dollarの副作用どうする？
  • Moneyの丸め処理どうする？
  • equals()
  • hashCode()
  • null との等値性比較
  • 他のオブジェクトとの等価性比較

自分の気付き・感想

  • 粗く実装してから結合度を下げていくのはなるほどな！ と思った
    • 最初から細かく可視性まで考慮してしまい、結果的に手が遅くなることがよくあったなと思った
    • そんなぐずぐず悩んでいる暇があるのなら、テストを先に書いてしまって(インタフェースを先に決定づける)後からリファクタリングすればいいと思った
  • カプセル化はMUSTなのか、WANTなのか？

みんなで話した気付き・感想

  • TDD的には、いきなり完璧なコードを目指すのではなく、要求を実現するための最小限のコードを少しずつ書く。小さなステップを踏んでいくのだ！
    • 普段は最初からカプセル化を意識してコードを書いていくので、アプローチが逆方向だなと新鮮だった
  • 3章までにテストをしっかり書いていないと(テストが正しいこと)、この章で大胆には変更できなかった

実装面でのひっかかり

  • Rubyのインスタンス変数のカプセル化。。。
  • eq だと同値性ではなく、同一性(object_idレベルで)を比較してしまうので、 == を使わなければならなかった

以上です！
はじめにインタフェースを設計できている必要があるので、テスト駆動開発ってスキルが必要だなー(今の自分には力不足。。。)と思いました。
ガチャガチャ実装しているうちに、インタフェース結構変えちゃうんですよね、自分の場合。がんばらねば。。。

次回は第5章です。

Rubyで写経：テスト駆動開発 第3章「三角測量」

Ruby Rspec TDD テスト駆動開発 dodosoft

テスト駆動開発という本を題材に、dodosoft のメンバーでもくもく写経会をやっています。
各々が違う言語で取り組んでいるので、言語ならではの悩み、言語共通のコンテキストを共有できて、なかなか学びがあります。

テスト駆動開発

テスト駆動開発

会場は ラクスル株式会社 の会議室です。いつも弊社ありがとうございます！

第3章 三角測量

第3章では、 equals という型と値が一致しているか確認するメソッドの実装をします。
Rubyは基本ダックタイピングなので、型を意識する機会がありませんが、
本章では返り値が Dollar 型であることを強く意識しています。
そのため、本書の意図にならって、Rubyでも型を意識したテストを書いています。

github.com

TODOリスト

  • $5 + CHF = $10
  • $5 * 2 = $10
  • amount を privateにする
  • Dollarの副作用どうする？
  • Moneyの丸め処理どうする？
  • equals()
  • hashCode()
  • null との等値性比較
  • 他のオブジェクトとの等価性比較

自分の気付き・感想

  • Rubyだと意識していないけれど、静的型付けの言語でテストを書く場合、型気にしないといけないんだね。。。
  • 他のメンバーは静的型付けで写経しているので、気にするポイントが違って面白い

他のメンバーの気付き・感想

  • 途中参加のメンバーは、参加の前に最低でもテスト回せてコンパイルができるプロジェクトを作っておいた方がいい
  • テストケースの書き方で、そのメソッドで意図していることを表現できるんですね。どんな条件でテストを書いているかで、その意図が見えてくる
  • テストするためのお膳立て(必要なオブジェクトの事前生成)は実際にはあるから、こんなに単純にはテスト書けないだろう(実際はクソ長くなる)

実装面でのひっかかり

  • it にラベルをつける時とつけない時の判断が自分の中でつかない....まあ、期待値を明示的にラベルしたい時は書いて置いた方がいいのかな？
    • たぶん、入力条件は context のラベルに書くべき

以上です！
型一致の評価を == としましたが、これ大丈夫なんですかね？(少なくとも eq はobject_idレベルで同一性比較をするので使えない)

次回は第4章です。サクサク進んで気持ち良いですね！