【エンジニア】レビューの時に、「重箱の隅」をつついてもよい環境で働いたほうが良い

こういうのって、100%を目指さないで、97%を目指すという風な指標をもてば解決できる場合がほとんどだと思う。

バグが0件になるまでテストやってるところなんてなくて、
・バグが収束傾向にある
・些細なバグしか残ってないのが明白
・品質基準を設けていて、それを満たしている
みたいになってるかと思う。

また、HTMLだって、100%文法チェックに通らないとNGなんてやめて、97%OKならOKとしてるようなところ多いと思う。

レビューだって、同じだと思うけどね。
コードレビューも全コードやるところから、サンプリングでやるところまでいろいろあると思う。

重箱の隅をつつく問題

重箱の隅をつつく問題はコードレビューの現場でよく聞く。レビューの場で所詮「書き方レベル」の指摘が横行してしまうというやつ。

誰しも綺麗なコードを追求したい気持ちはあると思うし、自分もそうなんだけど、あまり良くないなと思ってやらない事にしてる。理由は3つ。

・時間の無駄
・指摘される側の精神衛生上よくない
・そもそも意味ない



細かい指摘でも修正してマージするまでには結構時間がかかる。コードを直し、手元でビルド・動作確認し、pushしてCIを回し、「修正しました」と報告し、LGTMが付いてやっとマージできる。このプロセスが日に何度も発生すると確実に時間を食ってしまうし、Nitsな内容を何度も何度も受けると精神的にも疲弊してしまう。それで生産性が下がってしまえばもっと大きな問題になる。
エンジニア立ち居振舞い:重箱の隅をつつかない - 面白コンテンツ探求日記


・レビュー時に指摘は自由にする
それぞれの指摘を採用するかどうかは、別

2つの観点がないところで働くと、辛いんじゃないかなぁと思う。

指摘されると、絶対に修正しないといけないみたいなことがまかり通ってるようなところだと、重箱の隅をつつくようなものは、「意味がない」したい気持ちになると思う。でも、なぜ重箱の隅をつついているのに、それを聞かなくてはいけないか?といえば、ある程度の正当性があるからですよね。

正当性がある程度では、修正すべきかどうかは別という現実路線のところでないと、働くのはつらいんじゃないかなぁと思う。

「デグレートする可能性があるので、修正するのは嫌です」みたいなのが通らない環境なんて、私はないと思うんだけど、そうでもないのかなぁ?!

厳密さがないところで働くのも、辛い気が・・

些細なところは将来何かのついでに直せばいいや、くらい気楽に考えるのも悪くないんじゃないかな。
エンジニア立ち居振舞い:重箱の隅をつつかない - 面白コンテンツ探求日記


なぜ些細なのに、その時に修正しないの?
でもって、将来の何かのついでに修正したら、デグレートする危険性が上がるような・・。だって必然性がないのに、ついでに修正するなんて・・・。

エンジニア立ち居振舞い:重箱の隅をつつかない - 面白コンテンツ探求日記

ソフトウェアエンジニアって書きなさい(重箱の隅) / しれっと直すのは良くないと思う

2016/11/14 16:27

たぶん、プロの多数派はこっちだと思う。

適当な仕事をしてるところで、重箱の隅をつついても、無意味っていう話と
重箱の隅をつつくのは無意味という話とは
ぜんぜん違う話だと思う。

後でしれっと直せるところは、多くの場合は適当な仕事をしてるところの類だと思う。

いろいろ

エンジニア立ち居振舞い:重箱の隅をつつかない - 面白コンテンツ探求日記

コードならともかく、要件定義書のてにをはを指摘し始める奴とかどうにかならんか

2016/11/14 21:41

限度を超えると、こまるね。

エンジニア立ち居振舞い:重箱の隅をつつかない - 面白コンテンツ探求日記

もうスケジュール的に直せないところでレビュー依頼きて重箱の隅つつくしかないケースもあるぞ / エンジニア立ち居振舞い:重箱の隅をつつかない - 面白コンテンツ探求日記

2016/11/14 19:26

そういう時でも安心して重箱の隅をつつける環境だといんだけどね。指摘は妥当だけど、動作に影響がないので修正はやめましょうみたいな・・・。

エンジニア立ち居振舞い:重箱の隅をつつかない - 面白コンテンツ探求日記

重箱の隅をつつけるコードは本筋は問題ない、いいコード。自分の問題は、指摘事項があるときに、その数が増えると重箱の隅をつつくような指摘が含まれてしまうこと。

2016/11/14 14:38

数が多いだけで、修正も簡単な場合が多いと思うんだけど。たんに、忙しい時に面倒だなぁ程度ので、重箱の隅をつつかれないコードを今度から書こうと思う人ほとんどなのでは?

エンジニア立ち居振舞い:重箱の隅をつつかない - 面白コンテンツ探求日記

統一感のある名前付けが必要ならばあらかじめ規約を公開するべきだし、統一感のある記法にしたければツールを導入すべき。そうすることでレビューのひっかかりも短縮するし、規約の間違いも改善される

2016/11/14 13:04

ルール(規約)がないものに関しては、趣味趣向なので、指摘されても採用する必要性はないと私は思うんだけど・・。

エンジニア立ち居振舞い:重箱の隅をつつかない - 面白コンテンツ探求日記


納期が超短いのにインデントルールがどうとかレベルの指摘くどくどする客に立腹したことはある。そんなん、後で全部スクリプト書いて整形できるんで、それより仕様と速攻で広告代理店に納品する方が先では?と思った

2016/11/12 19:20

客あしらいの技術の問題のような。
あと、後でスクリプトで整形するのは、ちょっと怖いかなぁと思う。

同じ、重箱の隅でも、価値ある指摘をするエンジニアは素晴らしい

機械的に適用して、指摘できるようなたぐいのものは、ほとんど価値がないと思います。
表現は難しいですが、重箱の隅でも、コードを安全にするたぐいの指摘は、個人的には素晴らしいかなぁと思う。

その手の指摘は、経験を積んでいる人は指摘内容がよくわかるが、そうでない場合は、たわいもない重箱の隅と勘違いしがちだとは思う。

ルールに苦しめられて、きちんと仕事をしてきた職場は・・

ルールをないがしろにしてよいとかいうことを採用せずに、ルール自体を現実に合うように見直してきたと思う。
ルールを守るという路線は守ってきたからこそ、きちんと仕事できる職場が継続できるわけです。

ルールは形式で会って、運用でカバーしたらいいよねという路線だと、だんだんダメになるんですね。
重箱の墨をつつかないだけでなくて、この程度ならもうイイか?みたいな感じになって、歯止めが効かなくなる傾向にあると思う。

そういうのは、実際にはテストしてないのに、テストデータだけねつ造するとか、数字を少し改ざんするとかそういうのと似てると思う。

最初は、絶対に大丈夫なんだけど、基準を満たせないのでどうすることもできないことに対する回避策であったものが、だんだん、楽する路線になってしまうというオチ。

スポンサーリンク

コメントを残す

メールアドレスは公開されません。
また、コメント欄には、必ず日本語を含めてください(スパム対策)。