またもやーストーリー
とあるレビュー日和の日...
jflute:
(なんか、すっごいアバウトなメソッド名を見てしまった...)
jflute:
「このメソッド名ですが、少し曖昧で実処理を正確に表してないように自分には感じました。あえて曖昧にして隠蔽するとかシンプルさを優先しているとかであれば、それはそれで良いのですが...
例えば、"あれこれ" とか "これあれ" みたいな名前であれば読み手も素直に理解しやすいかなとは思うのですが、どうでしょう？」
お相手:
「あっそれ、後で直そうとテキトーに付けた名前でした。"あれこれ" いいですね、それにします」
またもやー
保留すること自体はGood
jfluteがよく言ってることですが、作り始めの最初から良い名前ってのはなかなか見つからないものです。
そのメソッドの処理の概要、呼び出す側のシチュエーション、周辺メソッドとのバランス、などなど...名前というのは識別をするためのものですから、実装の全体像がもう少しクリアになってきてからじゃないと良い名前が見つけられるわけないんですね。
なので、コードイメージがあやふやな最初から良い名前を付けようとしても、うんうん悩んで時間を使うだけでもったいないです。逆に、実装が進んでコードイメージがはっきりした後であれば、良い名前はすぐに見つかるものです。
だから、名前を保留すること自体はプログラミングテクニックだと思っています。
生真面目さがお茶を濁してる？
その保留の仕方が「それっぽい名前を付けてお茶を濁す」になりがちです。「見た目それらしい、でも意味が通じないメソッド名」を付けてしまうんですよね。
一時的にでもプログラムをぐちゃぐちゃにしちゃいけないという心理が働くのでしょうか？
コミットするまではソースコードはその人だけの実験場ですから、そんなこと気にしなくていいのに。
それっぽい名前は付けない
jflute自身がこうならないように気を付けていることがあります。
馴染んでしまうようなそれっぽい名前を付けない
馴染んでしまうから自分で見つけられないんです。
それっぽいだけでも名前を付けた気になって無意識で満足して忘れてしまうんです。
レビューで見つけてもらったらラッキーです。1年後に何じゃこの名前？ってなるのがオチです。
だからjfluteがやるのがこれ:
private void xxxxxxxxx() { ... }
メソッドは作るけれども、良い名前思い付かないと思ったらすぐにxボタンを押しておしまい。名前を付けません。考えない。すぐ次。
ひと目でも自己レビューすれば、いやでも後で絶対に見つかります。馴染まないですから。違和感ありまくり。
あと、すっごい保留した感が頭に残って忘れにくいんですね。名前を付けるという作業をしてないですから。満足感がないです。
万が一これでコミットしても、周りの人がすぐに見つけてくれますよ。
保留するなら徹底して保留する
教科書的にはtodoコメントだけど
保留するってことで言うと、todoコメントのような「IDEがマークを付けてくれるようなコメント」を残すがオーソドックスな手法もあります。
// TODO jflute 後でメソッド名を考える (2021/08/18) private FukuzatsuResult getValue() { ... }
これはこれでjfluteもよく使います。
DBFluteの補完テンプレートで _todo で「どん！」と補完されるようにもしています。jfluteの指であればほぼ一瞬です。
ただ、「コミットする前に直すような名前付けだけの保留」に使うには少々大げさかもです。説明要らないし。なので、実装のリズムを途切れさせないためにも、xボタンがぁぁぁ、はい次、って済ますんですね。
保留箇所探したかったら、(Eclipse) command+F => xxx... ですぐにその場所に移動します。renameするときは (Eclipse) alt + command + R ですぐに名前変更します。jfluteの指であればほぼ一瞬です。
メソッド名のレビューは勇気が要る
メソッド名に対してレビューの指摘を入れるって勇気が要りません？
処理が間違ってるとか、業務的に間違ってるとか、何か抜けてるとか、そういう指摘は機械的で簡単ですよね。
でも、メソッド名というのは、その人のデザインセンスに直結するものです。
あまり人のセンスに対してあれこれ言うのはしづらいもので。。。特にプログラマーはデザインを議論するのは苦手ですから。
だから、直し忘れの曖昧メソッド名でもレビュー通っちゃいがちなんです。
jfluteがレビューで指摘しちゃうのは、ＫＹだからです。
ラフスケッチプログラミング
プログラミングは、一行一行、完璧なコードを積み上げていかないといけないわけじゃないです。コミットする時に完璧であればいい...いや、本番にリリースするまでに完璧であればいいんです。
だから、実装中の目の前のコードは、まだラフスケッチ、全体の骨組み作ってからブラッシュアップしていくでも全然いいと思います。
リファクタリングはプログラミングの一部とも言えますから。
// リファクタリングは思考のツール
https://jflute.hatenadiary.jp/entry/20121202/1354442627
