00:01
最近、子供が産まれまして、いろいろバタついていて、なかなか収録をしませんでした。
あとですね、冬なんですよね、今って。冬って寒いんですよ。寒いと、あのー、全然活動できないんですよね。
多分体質的に低血圧らしくて、まあ低血圧が理由なのか、ちょっと医学的なあれはよくわかんないんですけど、
まあ私個人としては特に、とにかくその、冬だと活動したくない。なるべく早めに寝ることによって、
体が寒い、体が冷たいという状態を回避したいというものがあって、まあちょっと収録をサボっていました。
で、あのー、そうですね、結構忙しいんですよ。
ということでですね、今回は、プルリクエストのディスクリプションというタイトルでやっていこうと思います。
一言で言えば、ちゃんと加工、以上って感じなんですけど、
あのー、プルリクエストのディスクリプションってね、結構大事だと思うんですよね。
ペアプルとかMOBでやっていれば、そのペアの中、MOBの中で、
ナレッジが共有されていたり、コンテキストが共有されているので、
それはなぜかというと、普段からそういう会話をしていて、こういうタスクをやるぞっていうのが共有されているからで、
まあ、めちゃくちゃ良いことなんですよね。
個人との対話みたいな、そういうのがあるじゃないですか、と。
このプルリクエストのディスクリプションというのは、
個人との対話をしていて、こういうタスクをやるぞっていうのが共有されているからで、
コミュニケーションってめちゃくちゃ大事だと思うんで、
それはそれで良いんですよ。本当に良いと思うんです。
ただですね、コードに落とし込む時というか、コードに限らずなんですけど、
何かしらの成果物を残す時って、やっぱりこれ、後世に伝わるんですよね。
後世って結構大げさな言い方なんですけど、
後世に伝わる時って何かしらの成果物を残す時って、
やっぱりこれ、後世に伝わるんですよね。
後世って結構大げさな言い方なんですけど、
3ヶ月後の誰か、自分も含めですね。
あるいは1年後の誰か、もちろん自分も含めですね。
未来の人たちがね、気にする可能性があるんですよね。
気にしないかもしれないですけど、気にする可能性もあるんですよね。
実際、何か問題が起きた時って調査するじゃないですか、と。
バグが出ました。
じゃあバグが出て、
それはどこら辺のコードで発生してるんだろうって見て、
なるほど、こういうことかと。
こういうことかと思って、
そのコード、そもそもこれはなぜこういうことをやっているんだろうかと。
このif文、if文ですよ。
03:02
条件ですよね。
ほとんどのプログラミング言語に備わっているifというやつですよね。
それってめちゃくちゃ重要なんですよね。
そのifっていうのが記述されていて、
どうもそれがフォルスになったがゆえに、
ifの中のコードじゃなくて外側のコードが走って、
さらにその後別のことが起こって、例外を吐いたとか。
そういうことが起きるわけですよね。
つまりそのifがもしtrueだったら何も問題は起きないわけで、
フォルスになっちゃったと。
じゃあなんでifがtrueじゃなくてフォルスになっちゃったんだろうねとか、
そもそもそのifって何のために定義したんだろうねみたいなのがすごく気になるじゃないですか。
それを気にしないと多分ちゃんと調査ってできないと思うんですよね。
それを気にして、
ブレイムするわけですよ、gitブレイムとか。
そうすると修正のコミットハッシュが現れて、
それをさらに遡っていくこともできるわけですよね、gitブレイムって。
で遡っていくと、
最初にそのifを導入したコミットというのが見つかると。
そのコミットのメッセージを見てみると、
特に何もないんですよね。
でもコミットハッシュを使うと、
GitHub上でプルリクエストの検索ができるわけです。
これGitHub使わなくてもGitLabとかでも確かできたはず。
BitBucketは知らないです。
最近そういえばBitBucketって使ってる人どれくらいいるんでしょうね。
全然現役だと思ってるんですけど、あんまり聞かないなと。
まあいいや、とにかく今GitHubを使ってるんでGitHubってことにしますけど、
GitHubでそのコミットハッシュを使ってプルリクエストを検索すると、
そのプルリクエストにたどり着くことができてめちゃくちゃ便利ですよね。
でGitHubのプルリクエスト上で、
その変更の背景とかを見てみるわけですよ。
そうすると、あんまり細かいこと書いてないとかそういうのあるんですよね。
よくってタスクを管理しているツールのリンクが貼ってあるとか、
ジラなのかもしれないし、別の何かかもしれないですよね。
アサナなのかわかんないですけど、そういったリンクがあってそこをたどってみると、
そこをたどってみると、やっぱり何もないっていうのはあるわけですよね。
で、そうですね。何もない。
さらにそこからたどって、そのタスクを参照している別のタスクみたいなのを遡っていったり、
あるいはスラックとかを使っているのであれば、
06:03
そのタスクとか、あるいはもともとのプルリクエストのリンクとかで、
スラック上でそのままリンクをペタッと貼って検索をすると、
そのリンクを使ったやりとりみたいなのがたまたまヒットすることがあると。
そのあたりでようやく、あ、なるほどっていうのがわかる場合もあれば、
やっぱりわかんないなっていう場合もあると。
この時点でだいぶすり減らしてるんですよね。
何でしょうね。調査している時って単純に何でやったんだろうって知りたいだけなのに、
それを知るためだけにめちゃくちゃすり減らしてるって生産的じゃないですよね。
もしかしたら、今、AIですよ。
AI時代に突入しまして、2025年はAIエージェントだの、なんだの、言われていると思うんですけど、
そういうのがあることによって、そのAIがいろんなツールにアクセスして、
こっちが単純な質問、この変更なんでって聞くだけで、
今私がやった作業を全部代行してくれて、
背景をちゃんと説明してくれるみたいな未来が来るんだったらいいんですけど、
来るのかな。とりあえず来ない前提で行くと、
やっぱプルリクエストのディスクリプションってちゃんと書いた方がいいんじゃないかなって思うんですよね。
ここまでの労力やりたくないし。
コミットメッセージに書いてあると多分、何でしょうね、
GitBrainの段階でだいぶわかるから楽なんですけど、
100歩譲ってプルリクエストでいいと思うんですよね。
コミットメッセージもそこは議論の余地があるというか、
私はまずプルリクエストに書かれていれば基本いいかなとは思っています。
コミットメッセージも非常に厳格にやりたいっていう組織もあると思うんで、
そこについては全然いいぞ頑張れっていう感じではあるんですけど、
コミットメッセージに書いてあるのとプルリクエストのディスクリプションに書いてあるのが、
だいたい一致してくるんでね、
そうなってくると片方に寄せてもいいかなっていう気はしますね。
で、万が一GitHubから別のホスティングサービス、
バージョン管理のサービスに移る可能性が全然あるんだったら、
自前のGitの方に、つまりコミットメッセージの方に情報を寄せればいいんですけど、
だいたいの場合ホスティングサービスを変えることってないから、
私としてはプルリクエストに書いておけばいいかなっていう気がします。
AIの話とかでいろいろ揃えたんですけど、
09:04
とにかくこういう未来の自分とか他の人が問題に遭遇した時に、
そういう理由を知りたくなることがあるわけですよ。
そのプルリクエストがその調査対象になるかならないかはわからないんですけど、
わからないからこそ、ちゃんと書いておけばいいんじゃないのっていう気はしますよね。
さっきのAIの話にしても、結局AIエージェント君、
ちょっとどういうものか私はわかんないですけど、
情報がそれなりに豊富にあれば、
AIエージェント君も間違いなくこうやって理由を推定できるはずなんですよね。
制度っていうのか、ちょっと言葉の定義がわかんないですけど、
より正しい形でコンテキストを汲み取って、
最初に質問した人に回答ができるはずなんですよね。
そういう点でも、プルリクエストのディスクリプション、
ちゃんと書いておけばいいんじゃないのって気がしますよね。
それこそAI時代なんだから、AIに書かせるとかでもいいと思うんですけど、
AIに書かせるパターンって、
特にGitHubで最近だとディスクリプションをコーパイロットに
ジェネレートさせるみたいなことができるようになりましたよね。
あれなんですけどね、
ちょっとまだコンテキストを含めるみたいなのが難しくて、
というか、もともとのコミットメッセージのコンテキストをただなぞって、
変更内容こうだよみたいな風になってました。
これは2025年2月9日時点での結果なので、
もしかしたら進化はしてるかもしれないですけど、
ここから先、とにかくですね、
コンテキストまだAI君はそこまで組み取ってくれないですよね。
というか、そもそも当たり前なんですよね。
人間の心の中まで組み取れるほどのものにはまだなってないはずなんですよね。
人間の心の中を組み取れるっていうことは、
いよいよ人間の脳にチップが埋め込まれてる未来な気がするんですけど、
いずれ来るんですかね、そういう時代が。
わかりませんが、プレリクエストのディスクリプションをちゃんと書きたいよねと。
ペアプロとかですね、モブプロやってて、
私もちょっと反省点があるんですけど、
基本的に私はほぼほぼナビを最近はするんですよね。
事情は言わないでおきますけど。
プレリクエストのディスクリプションを書くっていう時に、
書いてもらってるんですけど、
素人目線というか、
素人っていうのは私のチームに関わっていない人。
12:04
私のチームが取り組んでいるタスクに関わっていない人が見た時に、
これわかるかなっていう風には結構思うことあるんですよね。
でもそれを言ってると結構長文になりそうな気がするので、
それはそれで言いづらいなっていうところがあって、
とりあえずこれでいいかっていう感じでやってるんですけど、
私としてはもうちょっと丁寧に書こうかなって思ってはいるんだけど、
そこをどういう風にやっていこうかなというのは今悩んでいるところです。
悩みっていうかね、いやいいんですけどね。
どのタイミングで言うかっていうのもありますからね。
これもめちゃくちゃ余談なんですけど、
プレリクエストのディスクリプション、
これは私のチームに限らず、
全体的な傾向を見て私の独断で話すことなんですけど、
プレリクエストのディスクリプションが薄い人ほど、
結構プレリクエストを出すなっていう印象があるんですよね。
それはなぜかっていうのは正直わかんないですけど、
推測するに、例えばコードの変更がめちゃくちゃ小さいとかね、
それはそれでめちゃくちゃ有意義ですよね。
有意義なんだけど、でもなんかめっちゃモヤモヤしますよね。
あとコードの変更が小さくないパターンもある。
めちゃくちゃ何か書いてるなみたいな。
なんかリファクタリング以上みたいな、
そういうプレリクとかあったりするんですけど、
まあリファクタリングか、なるほどなぁと。
例えばリファクタリングって言葉結構一人歩きしているような気がしていて、
本当にそれはリファクタリングなのかみたいな変更とかもたまにありますよね。
リファクタリングって最近私ちょっとすごく怖くて使いづらい言葉だなっていう気がしていて、
本当にそれはリファクタリングなのかなみたいな。
正確な定義はマーティンファウラーの本にもあるような気がするんですけど、
そうなんですよね。リファクタリングって言ってて、
例えばテストと一緒に修正しちゃうとかね、よくありますよね。
でもそれは事情があると思うんですよ。
そういう事情だからね。
たぶんそれでまとめてやった方が効率がいいとかいろいろあると思うし、
全然否定されるべきものではない。
それをリファクタリングって言っていいのかっていうのがまた別問題で、
だから挙動を変えずにちょっと読みやすくしましたみたいな、
15:02
そういう感じですよね、もはやリファクタリングって。
そうなってくると読みやすいって、
それはあなたの主観でしょうとかどうせ言われるんですよね。
リファクタリングって言っておくと主観性が薄れるんですよね。
わかんないですけど。
だけど実際主観ですからね。
というかリファクタリングも基本主観じゃねえかっていう話もあるし、
プログラミングという活動そのものが主観的なものな気もしますよね。
一昔前だとプログラマーというのはアーティストと同じような、
今もそうなのかわかんないですけど扱いを受けて、
アーティストっていうことはつまりクリエイティビティを発揮するということで、
クリエイティビティを発揮するということはつまり主観だとは思うんですよね。
それでいいとは思うんですよね。
それでいいんだけど、
じゃあリファクタリングってさも科学的な響きを感じるんですよね。
それこそマーティンファーラーがパターンにしていることからもわかる通り、
いかにもガイドライン、いかにも偉い人が言っているものだからいいものだみたいな感じなんですけど、
違う気がするんだよなと。
最近タイディファーストって出ましたけど、
あの言葉が今ちょうどいい気がしますよね。
私はコンマリが好きなんで、
タイディファースト、タイディ、来た、きちんとするってことだろと。
やっぱりスパークジョイですよ。
コンマリの精神でやっていきたいですよね。
結構話は逸れたんですけど、
プリクエストのディスクリプションちゃんと書きたいよねというところで、
今回は終わりにしようかなと思います。
それではまた。
