同僚にコードがひどいと言われたら、どう反応すればいい？ 143
ストーリー by headless
泥沼 部門より
泥沼 部門より
「同僚の書く酷いコード、どうやって気づかせる？」というストーリーを先週掲載したが、ひどいと言われた側からのタレこみが本家で取り上げられている。
本家/.「Ask Slashdot: How To React To Coworker Who Says My Code Is Bad?」より
本家/.「Ask Slashdot: How To React To Coworker Who Says My Code Is Bad?」より
私は今の会社で10年以上働いており、いくつもの製品開発サイクルにかかわってきた。しかし、最近チームに加わった見習いの開発者が、私のコードの出来がひどいと言い出した。わが社のコードベースにはおよそ5万行のコードがある。私のコードに対する苦情は、彼の経験が浅く、コードが何をしているのかを理解していないのが原因だ。彼は頭がよく非常に有望であり、良い質問をしていると思う。しかし、どうすれば彼自身が誰よりも優れているという考えを捨て、時間をかけて内容を学ぶように説得できるだろうか。
そうかもしれないなぁ (スコア:5, おもしろおかしい)
Re:そうかもしれないなぁ (スコア:2)
＃そして、また別の修正時に勝手に直された所が実はバグって居ると発覚する事に。
まずは褒めるべき (スコア:5, すばらしい洞察)
たいていの企業では情報流通が過少になりがちです。つまり言うべき事を色々な理由で言わなかったり、それを伝えなかったりします。そういった事態は、その逆の事態より問題です。余計な事を言われたりした場合はそれを無視すればいいだけです。
私の方が経験があるので余計な事を言うなと言ったり、攻撃的になるのは望ましくない対応です。
忙しくそれを聞くに値しないなら、こう言った上でそう伝えるべきでしょう。
次に、どのような点で問題であるか、出来れば例を挙げて聞く事です。
もちろん、客観的になる必要があります。まずは自分の問題を直す事を第一に考えます。相手の問題を指摘するのはその後で構いません。
その指摘が妥当でないならどういう点に於いてかを言います。例えば、「君はこのように習ったかもしれないが、こういう書き方もあるのだ」とか。
それで納得しなければ仕方ありません。これは飽くまで自分のコーディングにおける問題の対処にあるのであって、不満解消の為ではありません。自分の方法が正しいなら、見習いはその内気づくでしょうし、それが意見対立の一種であるなら上司にあたる方の意見が優先されるべきです。
Re:まずは褒めるべき (スコア:1)
単に「自分が理解できない」ってだけなんじゃないのか？
自分が想定していないアルゴリズムを理解するのは困難。
見習いの引き出しが少ないってだけの気がする。
これを無条件に褒めることには慎重であるべきだと思うな。
他人を貶しているって自覚も無いみたいだし。
この件に当てはまるかは分からんが、
自分より器の大きい人の考えは理解出来ないから
器の小さな人ほど他人が劣っていると考えちゃうもんなんだよね。
聖帝コーディング (スコア:4, おもしろおかしい)
退かぬ! (文法やデザインパターン的に奇妙なコードを書き始めしまってもひるまない)
媚びぬ! (後で読む人の事を考えない、コメントも無い)
顧みぬ! (書き殴ったら読み返さない)
とか言ってみれ
言い返す (スコア:3, おもしろおかしい)
酷いって言う方が酷いんだぞー、と。
#子供の喧嘩か
耳が痛いときほど。。。 (スコア:3, 参考になる)
他の同僚も思っているかもしれません。
客もそのように思っているかもしれません。
むかついた時ほど、成長のチャンスです。
丁寧に説明してみたら。
指摘する彼からのなにかがあるかも。
また、あたりまえと持っているけど長年やっているから気づかないことも。
Re:耳が痛いときほど。。。 (スコア:1)
まったくその通り。
自分の根拠を示して、相手の書き方とその根拠を聞けばいい。
新たな発見を得られるかもしれないし、最低限、相手に自分の考え方を理解してもらえる。
どうしたらいい？と聞き返す (スコア:3)
読みやすさは個人の経験に寄るところなので、聞くしか無いですね。
（アーキテクチャ上の理由だったり、保守性の理由だったり、開発容易性の理由だったりなので、なんで？って聞き返します）
あと、設計書から実装を想像できないようなコーディングをしてしまう（必要になる）と、
これは甘んじて受け止めるしか無い。コードよりも設計書がひどいって話ですから。
＃実際に直すか直さないかは、予算の関係もあるので、修正は保留。
＃開発の規約によってできないこともありますし。
ほっとけ (スコア:3)
そのうち、「こんなひどいコードを書いたのは誰だ！」「去年の俺だ！」ってなれば、いやでもわかる。
蒸し返されたなぁ。 (スコア:2, 興味深い)
以前のストーリーで「言われてる側だろうなぁ」と書いた者です。
僕の場合は、とにかく「考えて」欲しかったんです。
単純に「嫌い」だ「分かりにくい」だと言われても、こちらも納得出来なくて。
だから、「考えてよ！分からなきゃ根本的な事から教えるからさ！」って言っても、
皆拒絶反応だったんですよ（プライド高いヤツ程）。
実際まともに動いてるんだから、調べてよ。
得手不得手あるのは分かるけど、
一通りパッと見ただけで「これじゃ分からん」って言われても・・・。
そんな感じでしたねぇ。
＃あー、また反論くらいそうだ・・・
Re:蒸し返されたなぁ。 (スコア:1)
＞どこが、どういう理由で悪くて、どう書くべきか、それで何が良くなるか、質問すれば良いと思いますよ。
その答えが、「見ても分からない」「多重配列なんてよく使うね。」なんですよ・・・。
僕が求めてるのは、解答までの道筋なのに・・・。
Re:蒸し返されたなぁ。 (スコア:1)
＞総合的には他者を見下していて話を聞かないので変な行動が多かったですね。
僕は他人を見下した覚えはないんですが・・・。そうなってたんですかね？
＞数行で済むような要件に複雑な多重配列を使ったロジックを書いて「僕のロジックに合わせてください」とのたまい
それはないわ。関数化すれば多重配列いらんし。
ってか、「僕のロジックに合わせて下さい」なんていう人いるんだ？
＃ま、僕は一人で書いてたから、そんな事のたまう相手すらいなかった・・・（泣）
Re:蒸し返されたなぁ。 (スコア:1)
＞なんとなく思い出して探してみた。
＞http://dochikushow.blog3.fc2.com/blog-entry-1898.html [fc2.com]
＞こういうことなんかねぇ
なんか凄く納得した。「なるほどねぇ」って思いながら読みました。
で、コミュニケーション能力のあるヤツは、上には話するけど（根回し）、
下には気に入ったヤツにしか話しないんだよね。
で、突然訳分からん話が降って湧いてくる。
で、僕が「何言ってんだ？今の状態で出来る訳ねーだろ」みたいな事言っても、
上だけでなく、洗脳しやすい下にも根回し済みなので、孤立する訳ですよ。
そんな事が何度も続いた訳ですよ、ええ。
でもさすがに、一度キレた事がある。
社内SEなので、社内のシステム（サーバとか）を管理しているのは僕なのだが、
その僕に一言の相談もなしに勝手にシステム更改の話を進めてやがった。
さすがに呆れかえったが、その頃はもう精神的に疲れていたので、
「もう勝手にしろや」って思って、OKしたんだわ。
ただね、そのシステム構成の話になった時、ソイツが言ったんだわ。
「一度ｘｘｘｘ（システム構成のインタフェースね）をやってみたかったんだよね～」
その一言で、堪忍袋の緒が切れた。
「ウチら（社内）のシステムは、お前のオモチャじゃねー！」って思って。
で、そこから会話に参加。で、ぶっ潰した。もちろん、冷静に淡々と追い詰めて。
（メインで管理する僕が何も聞いてないんだから、潰すのは簡単だった）
後でソイツに呼び出されて何かほざいてたけど、もちろんシカト。
「あ、話おわり？じゃ、戻るわ」で出て行った。
ま、この時点で「どっちかが辞めならなきゃならんな」とは思った。
それが僕になる事も想定済みだった。
その後に休職する事になるのだが、ま、その後の話はいっか。
＃すいません、また愚痴こぼしちゃった・・・
Re:蒸し返されたなぁ。 (スコア:1)
＞あなたは「正しいのは俺だから、お前らが理解しろ」としか言ってないように見える。
＞他人のせいにしてばかりでどうしたら理解してもらえるか考えて動かないのでは、どこ行っても同じだよ。
ふむ、なるほど・・・。そうだったかもしれないです。
「十年以上一人でやってきたんだ！俺の好きにさせろ！」
みたいになってたかも。冷静に考えると。
でもさすがに、管理してる人間に何も聞かずにシステム更改の話を進められると・・・。
ま、積もり積もったものが爆発した日だったなぁ。
Re:蒸し返されたなぁ。 (スコア:1)
＞コードとは別の文書が足りてないならいつまでも つっこまれ続けますよ。
そうですね。それはよく分かりました。
この間ドキュメント見てたら、2004年くらいまではちゃんとあったんですよ、ドキュメント。
それ以降、ぷっつりなくなってた。
理由は、「ドキュメントより先にこっちやって」がそこから永遠に続いたから・・・。
＞重要なのは、自分の過去のコードを追認するための規約書なんて書こうと思わないこと。
＞プロジェクトを成功させるためだけに 必要なことを、常にメンテし続ける覚悟を持って作る。
はい、常にメンテする覚悟は持ってました。実際毎日声掛けられたし。
風邪で休んでも電話がかかってきて、FTP経由でファイルやりとりしたことも・・・。
＞他に何がいるの？たったこれだけのことだよ。
＞設計書を除けば きちんと知識があれば 三日あればできるよ。分担すればその日のうちにできあがる。
ただ、その「分担」する相手が全くいなかったのですよ。僕がつぶれるまで。
＞知識は整理しさえすれば 未来の自分を含めた第三者がいつでも使えるようになる。
＞整理さえすれば 忘れちゃえばいいんだから、今それをやれば、あなた自身がすっきりする。
＞やるしかないでしょ。
そうですね、今やるっていうのもアリですね。
他の人（今メインでやってる人）に邪魔にならない程度に、やってみようと思います。
普通に対応すればいい (スコア:1, フレームのもと)
と逆に恥をかかせてやればいい。
Re:普通に対応すればいい (スコア:1)
この本家のACはガベージ・イン／ガベージ・アウトを熟読すべき (スコア:2, 興味深い) [srad.jp]
プログラマではありませんが、名言だと思いましたね。
モデレータは基本役立たずなの気にしてないよ
Re:普通に対応すればいい (スコア:2, すばらしい洞察)
この本家のACはガベージ・イン／ガベージ・アウトを熟読すべき (スコア:2, 興味深い) [srad.jp]
プログラマではありませんが、名言だと思いましたね。
さて、そういうコードの保守はどうするんでしょうかね…
Re:普通に対応すればいい (スコア:1)
＞さて、そういうコードの保守はどうするんでしょうかね…
そんなこまけーことはいーんだよぉ！
将来誰かが何とかしてくれるさ！
っていうのが、１２、３年程前にありましたね・・・。
＃僕は運良く普通に正月を迎えられましたが、大騒ぎだったよなぁ・・。
Re:普通に対応すればいい (スコア:2)
年内にテストを終わらせると、毎日遅くまで＋土曜まで出て作業してました。
＃が、昨日の時点でまだ終わっていないと言う・・・
Re:普通に対応すればいい (スコア:1)
> wolf03さん
あの頃は、ホント大混乱状態でしたね。
僕も半年前までは、関係あるチームに所属してて、
「正月帰れねーなぁ」って思ってたら異動したので（笑）。
＃当時は全国が停電するとか銀行の残高がなくなるとか、訳分からん噂も多かったですね（笑）
Re:普通に対応すればいい (スコア:1)
当時色々活躍していた MMR が、様々な予測を立ててましたねぇ。きっとその警告が聴いてたんですよ。
2038年に向けて、そろそろ MMR 活動再開？
Re:普通に対応すればいい (スコア:1)
プログラムも、そろそろ人に読ませるものとして教育すべきと思うのだが。
Re:普通に対応すればいい (スコア:2)
標準的な記法も早くから整備(PEP8)されていて、それに準拠することが多いです。
可能であればこういった「読みやすさ重視」の言語から入門させるのも一考に値するのでは無いかと思います
Re:普通に対応すればいい (スコア:1)
コンパイラは、書かれたとおりのコードをただ生成するだけですよ。
人の読めない指示書の妥当性をどうやって担保するのか。
「そもそも担保する必要などないのだ」を名言と思うならもう話はありませんが。
Re:普通に対応すればいい (スコア:1)
本当はひどくない→いいがかり
本当はひどい→的を射た指摘
どっちなんでしょうねぇ
＃必ずしもAにとって良だったとしてもBやCにとって良とはかぎらんでしょうに・・・
＃ああぁ、だから落としどころに困るのか
Re:本当にひどくてもひどくなくても (スコア:1)
> 大勢の前で恥をかかすとかなんとか、なんでいきなりそんなに感情的なんだろうって思うわ。
まったくですね。
原文みると、「When he comes to me with a complaint about the code」だから個人的に指摘してきたに過ぎない話なのに、いきなり大勢の前で報復とか、なんか怖い。
ベテランのスタイルが古臭いのはよくある話なので（自戒自戒）、若者の指摘も聞ける部分は聞いて、可能な部分は今風の設計にした方がいいと思うな。
素敵なコード (スコア:1)
>私のコードに対する苦情は、彼の経験が浅く、コードが何をしているのかを理解していないのが原因だ。
果たしてそうだろうか？
学生の頃にプログラミングを勉強しだした時、他人が書いたたくさんのプログラムソースを読むことをした。
素敵なコードはわかりやすく、勉強しはじめのビギナーでも読むことができた。
しかし、汚いコードは、何をしているのかわかりにくい。
他人が読んだときに分かりにくいコードは、長い期間が過ぎると、書いた本人も読みにくくなってしまう。
他人が読みやすいコード、それは自分がわかりやすいコードでもある。
経験が豊富な人でも、読むのに苦労するソースは汚いソース。
汚いソースを指摘するのは、経験の浅い深いでは関係ないんだよね。
Re:素敵なコード (スコア:5, すばらしい洞察)
でも「三項演算子は使い慣れてない」とか「do...whileは他で実現できるから不要」とか言われてもな。
(その人にとって)読みにくいソース＝(一般的に見て)汚いソース ではないから
実際のコードを見て見ないことにはどっちの意見も話半分にせざるをえないです。
両者ともにティーチング（主張に対する分析と理解と対応）が必要だと感じる (スコア:5, すばらしい洞察)
>私のコードに対する苦情は、彼の経験が浅く、コードが何をしているのかを理解していないのが原因だ。
では、なぜ彼の経験が浅いと、貴方のコードは理解出来ないのでしょうか？
一般論としては「技術レベル（含業界経験則）の未熟」と
「貴方個人の慣習（独自性）への不理解」があると思われます。
前者は彼の努力を期待してしかるべきですが、
後者は貴方のコミュニケーション能力の問題です。
後者に対する要求を完全に拒否したいならば、
貴方は他者とコードを元にコミュニケーションを必要とされる仕事を
選ぶべきではありません。
Re:両者ともにティーチング（主張に対する分析と理解と対応）が必要だと感じる (スコア:4, すばらしい洞察)
経験が浅いが優秀と評価される者が酷いと言うようなコードって、おそらく本当に酷いコードだと思うんですよ。
そして相談者はコードが酷いということは否定してませんので、この事はコレクトだと思います。
なので、噛み砕くと相談者は「経験浅く優秀な者が酷いコードに嫌気がさし理解する作業を拒否するが、どうやったら従わせることができるだろうか？」という事でしょうね。
＃そう考えると嫌な相談だ・・・
Re:両者ともにティーチング（主張に対する分析と理解と対応）が必要だと感じる (スコア:1)
問題の新人さんはまずは、自力でコードを書き直して見本を見せ、さらに自分に課せられた用件
を期間内にこなすことができるのか？自力でできないならチームメイトの手を止めて対策をとらせ
るべきなのか、その場合でも十分期間内にプロジェクトは完了するのか？それとも何も成果物を
ださないのかを示すべきでしょう。
で、今回の質問者は、彼無しでプロジェクトを完了できるか判断し、彼無しでできるのなら、それで
無視すれば済む話です。彼以外の代替が必要なら、それを調達する目処があるかどうかが問題
でしょう。
必要なのはティーチングなんかの前に仕事の要件定義です。
Re:素敵なコード (スコア:2)
他人のコード読む練習にもなっていたと気付くのは、就職してからだったけど。
Re:素敵なコード (スコア:2)
Re:素敵なコード (スコア:2)
末尾再帰はコンパイラがループに変換してくれますよ。
それに、経験上、ツリーの探索を再帰を使わずに返って保守しづらいコードになります。
ケースバイケースで再帰は使うべきかと思います。
Re:素敵なコード (スコア:1)
でも、末尾再帰をループに変換してくれないコンパイラーというのもあってだな…
Re:素敵なコード (スコア:2)
そう言えば、自分の関わったプロジェクトで
g++コンパイラの最適化オプションを最初O2で開発していたのを、
デバッグしやすいようにとO0に変えたものがありました。
もし再帰呼び出しを使ってたら大ごとになったかも。
Re:素敵なコード (スコア:1)
性能上必要なコーディングと
表題の汚いコードは、全く別のものでしょ？
コードの善し悪しは客観的であるべきで人間関係に求めるべきではない。 (スコア:1)
まず、可読性が問題なら、命名規約を含むコーディング規約が守られていることが
プロジェクトにおけるよいコードの唯一の判断基準であるべきで、規約によっても
「汚い」コードがあると感じられるなら、規約に不備があるということか、プロジェクト
についての認識が間違っているかどちらか、ということになります。
コードについてあれこれ言う前にプロジェクト管理者に話をつければすむことではないのかな。
保守性やテスト管理保守性、処理効率の問題を感じるなら、客観的データが出せるはずだから、
静的チェックでも動的チェックでもテストでも何でも書いて 示せばいいだけだと思います。
前回の話もそうだったんだけど、どうして人間関係の話になるのか いまいちよくわかりません。
Re:コードの善し悪しは客観的であるべきで人間関係に求めるべきではない。 (スコア:1)
>前回の話もそうだったんだけど、どうして人間関係の話になるのか いまいちよくわかりません。
私もそうですがプログラマと言う人種は自分こそが世界最高のプログラマだとうぬぼれている人が多いからではないでしょうか？
他人に指摘される→他人より自分が劣っていると言われているように感じる。
だから他人の意見に歩み寄れない人が多いのかと。
まあ、コミュニケーション能力に劣っているのだと言われればそれまでですが＾＾
コードの「ここがこうなってる理由」でも説明してやれ (スコア:1)
どちらが「わかってない」かはっきりするから。
コードレビュー (スコア:1)
それは都市伝説orz
異文化交流 (スコア:1)
異なる文化(コーティング規約)の人達と合同で開発を始めるとよく言われます。特に多いのが、三項演算子、do-while、例外処理の組み方(goto or エラー関数)辺りでした。最終的には、話し合ってお互いに良い所をマージして新しいコーティング規約を作りました。
でも、初めに文化の違いだと言ったら、切れられました。
Re:お互い様 (スコア:1)
当事者（見習い開発者の方）が降臨して来たのかと思いましたよ。
Re:当事者同士で納得いくまで話し合ってもらう (スコア:1)
誰も迷惑していないような。
むしろ、話のネタになってみんな喜んでるのでは？
＃そもそも、元のタレコミはアメリカの本家だよ
Re:じゃあ俺の代わりに書いてくれ (スコア:1)
批判返しとして良くある手だね
それやるととりあえず勝てることがあるけど評判落とすよ
前の課長がそれやりすぎがきっかけで総スカンくって人事に飛ばされちゃった
絶対？ (スコア:1)
class A {
protected:
~A() {}
public:
virtual void f() = 0;
};
class B : private A {
private:
virtual void f();
public:
A* a() { return this; }
};
とかやりませんか？
Re:絶対？ (スコア:1)
Re:絶対？ (スコア:2)
protectedな非virtualデストラクタの主な適用対象は、基底クラスにvirtual関数が全くない場合だと思います。基底クラスの分のvtableを完全に省略できることがその理由です。
この例だと基底クラスAはほかにvirtual関数を持っており（どのみちAのvtableが必要）、デストラクタを非virtualにする有難みがあまりないので、そこまでしなくてもいいのではかな（素直にAのデストラクタをvirtualにする）と私なら思います。
なお、protectedな非virtualデストラクタ自体は熟練というほどでもないテクニックだと思います。More Exceptional C++やModern C++ Designに取り上げられているようです（私は残念ながらどっちも読んだことがない）。最も単純な例がnoncopyable（More C++ Idioms/コピー禁止ミックスイン(Non-copyable Mixin) [wikibooks.org]）でしょう。