アカウント名:
パスワード:
>私のコードに対する苦情は、彼の経験が浅く、コードが何をしているのかを理解していないのが原因だ。
果たしてそうだろうか?
学生の頃にプログラミングを勉強しだした時、他人が書いたたくさんのプログラムソースを読むことをした。素敵なコードはわかりやすく、勉強しはじめのビギナーでも読むことができた。しかし、汚いコードは、何をしているのかわかりにくい。
他人が読んだときに分かりにくいコードは、長い期間が過ぎると、書いた本人も読みにくくなってしまう。他人が読みやすいコード、それは自分がわかりやすいコードでもある。
経験が豊富な人でも、読むのに苦労するソースは汚いソース。汚いソースを指摘するのは、経験の浅い深いでは関係ないんだよね。
でも「三項演算子は使い慣れてない」とか「do...whileは他で実現できるから不要」とか言われてもな。
(その人にとって)読みにくいソース=(一般的に見て)汚いソース ではないから実際のコードを見て見ないことにはどっちの意見も話半分にせざるをえないです。
> 実際のコードを見て見ないことにはどっちの意見も話半分にせざるをえないです。
真理だと思います。^^
では、なぜ彼の経験が浅いと、貴方のコードは理解出来ないのでしょうか?
一般論としては「技術レベル(含業界経験則)の未熟」と「貴方個人の慣習(独自性)への不理解」があると思われます。
前者は彼の努力を期待してしかるべきですが、後者は貴方のコミュニケーション能力の問題です。
後者に対する要求を完全に拒否したいならば、貴方は他者とコードを元にコミュニケーションを必要とされる仕事を選ぶべきではありません。
経験が浅いが優秀と評価される者が酷いと言うようなコードって、おそらく本当に酷いコードだと思うんですよ。そして相談者はコードが酷いということは否定してませんので、この事はコレクトだと思います。
なので、噛み砕くと相談者は「経験浅く優秀な者が酷いコードに嫌気がさし理解する作業を拒否するが、どうやったら従わせることができるだろうか?」という事でしょうね。
#そう考えると嫌な相談だ・・・
問題の新人さんはまずは、自力でコードを書き直して見本を見せ、さらに自分に課せられた用件を期間内にこなすことができるのか?自力でできないならチームメイトの手を止めて対策をとらせるべきなのか、その場合でも十分期間内にプロジェクトは完了するのか?それとも何も成果物をださないのかを示すべきでしょう。
で、今回の質問者は、彼無しでプロジェクトを完了できるか判断し、彼無しでできるのなら、それで無視すれば済む話です。彼以外の代替が必要なら、それを調達する目処があるかどうかが問題でしょう。
必要なのはティーチングなんかの前に仕事の要件定義です。
>問題の新人さんはまずは、自力でコードを書き直して見本を見せ、さらに自分に課せられた用件>を期間内にこなすことができるのか?自力でできないならチームメイトの手を止めて対策をとらせ>るべきなのか、その場合でも十分期間内にプロジェクトは完了するのか?それとも何も成果物を>ださないのかを示すべきでしょう。
それはプロマネの仕事では?
有望新人は「コードの危険性」を指摘し頑固ベテランは「コードの必要性」を説明し、プロマネやリーダーが複数観点での効率や安全性を考慮し線引きする。
職分や権限を超えて勝手に判断するのは、チームとして崩壊しますので止めましょう。
>で、今回
再起呼び出しとか、高速化のために工夫がなされたコードは、ビギナーの時に全く理解できなかったけどなぁ。
富豪的プログラミングで組まれたコードであれば、良いコード=読みやすいコードになるかもしれないけど、環境の制約、あるいは何かしらの目的を達成するために工夫されたコードってのは読みにくいことがあるので、結局はケースバイケースじゃないでしょうか。
まぁもちろん読みやすく書く努力はすべきでだと思いますが。
あと再帰呼び出しでスタックを使い尽くすと、問答無用で落ちちゃうはずじゃないかな。
末尾再帰はコンパイラがループに変換してくれますよ。それに、経験上、ツリーの探索を再帰を使わずに返って保守しづらいコードになります。ケースバイケースで再帰は使うべきかと思います。
そう言えば、自分の関わったプロジェクトでg++コンパイラの最適化オプションを最初O2で開発していたのを、デバッグしやすいようにとO0に変えたものがありました。もし再帰呼び出しを使ってたら大ごとになったかも。
間違えた。orz
(誤) それに、経験上、ツリーの探索を再帰を使わずに返って保守しづらいコードになります。(正) それに、経験上、ツリーの探索を再帰を使わずに書くと返って保守しづらいコードになります。
-- staygold
べつにいいじゃん
性能上必要なコーディングと表題の汚いコードは、全く別のものでしょ?
賛成!
わかりやすかったコードは素敵なコードで分かりにくかったコードは汚いコード
にしたかったって可能性も考えておこうなすてき・汚いってのが何をもって決まるのかを考えてみようね
素敵なコードなんて夢を見ていないで、無敵なコードを書け。それで万事解決する。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
素敵なコード (スコア:1)
>私のコードに対する苦情は、彼の経験が浅く、コードが何をしているのかを理解していないのが原因だ。
果たしてそうだろうか?
学生の頃にプログラミングを勉強しだした時、他人が書いたたくさんのプログラムソースを読むことをした。
素敵なコードはわかりやすく、勉強しはじめのビギナーでも読むことができた。
しかし、汚いコードは、何をしているのかわかりにくい。
他人が読んだときに分かりにくいコードは、長い期間が過ぎると、書いた本人も読みにくくなってしまう。
他人が読みやすいコード、それは自分がわかりやすいコードでもある。
経験が豊富な人でも、読むのに苦労するソースは汚いソース。
汚いソースを指摘するのは、経験の浅い深いでは関係ないんだよね。
Re:素敵なコード (スコア:5, すばらしい洞察)
でも「三項演算子は使い慣れてない」とか「do...whileは他で実現できるから不要」とか言われてもな。
(その人にとって)読みにくいソース=(一般的に見て)汚いソース ではないから
実際のコードを見て見ないことにはどっちの意見も話半分にせざるをえないです。
Re: (スコア:0)
> 実際のコードを見て見ないことにはどっちの意見も話半分にせざるをえないです。
真理だと思います。^^
両者ともにティーチング(主張に対する分析と理解と対応)が必要だと感じる (スコア:5, すばらしい洞察)
>私のコードに対する苦情は、彼の経験が浅く、コードが何をしているのかを理解していないのが原因だ。
では、なぜ彼の経験が浅いと、貴方のコードは理解出来ないのでしょうか?
一般論としては「技術レベル(含業界経験則)の未熟」と
「貴方個人の慣習(独自性)への不理解」があると思われます。
前者は彼の努力を期待してしかるべきですが、
後者は貴方のコミュニケーション能力の問題です。
後者に対する要求を完全に拒否したいならば、
貴方は他者とコードを元にコミュニケーションを必要とされる仕事を
選ぶべきではありません。
Re:両者ともにティーチング(主張に対する分析と理解と対応)が必要だと感じる (スコア:4, すばらしい洞察)
経験が浅いが優秀と評価される者が酷いと言うようなコードって、おそらく本当に酷いコードだと思うんですよ。
そして相談者はコードが酷いということは否定してませんので、この事はコレクトだと思います。
なので、噛み砕くと相談者は「経験浅く優秀な者が酷いコードに嫌気がさし理解する作業を拒否するが、どうやったら従わせることができるだろうか?」という事でしょうね。
#そう考えると嫌な相談だ・・・
Re:両者ともにティーチング(主張に対する分析と理解と対応)が必要だと感じる (スコア:1)
問題の新人さんはまずは、自力でコードを書き直して見本を見せ、さらに自分に課せられた用件
を期間内にこなすことができるのか?自力でできないならチームメイトの手を止めて対策をとらせ
るべきなのか、その場合でも十分期間内にプロジェクトは完了するのか?それとも何も成果物を
ださないのかを示すべきでしょう。
で、今回の質問者は、彼無しでプロジェクトを完了できるか判断し、彼無しでできるのなら、それで
無視すれば済む話です。彼以外の代替が必要なら、それを調達する目処があるかどうかが問題
でしょう。
必要なのはティーチングなんかの前に仕事の要件定義です。
Re: (スコア:0)
>問題の新人さんはまずは、自力でコードを書き直して見本を見せ、さらに自分に課せられた用件
>を期間内にこなすことができるのか?自力でできないならチームメイトの手を止めて対策をとらせ
>るべきなのか、その場合でも十分期間内にプロジェクトは完了するのか?それとも何も成果物を
>ださないのかを示すべきでしょう。
それはプロマネの仕事では?
有望新人は「コードの危険性」を指摘し
頑固ベテランは「コードの必要性」を説明し、
プロマネやリーダーが複数観点での効率や安全性を考慮し線引きする。
職分や権限を超えて勝手に判断するのは、チームとして崩壊しますので止めましょう。
>で、今回
Re:素敵なコード (スコア:2)
他人のコード読む練習にもなっていたと気付くのは、就職してからだったけど。
Re: (スコア:0)
再起呼び出しとか、高速化のために工夫がなされたコードは、ビギナーの時に全く理解できなかったけどなぁ。
富豪的プログラミングで組まれたコードであれば、良いコード=読みやすいコードになるかもしれないけど、
環境の制約、あるいは何かしらの目的を達成するために工夫されたコードってのは読みにくいことがあるので、
結局はケースバイケースじゃないでしょうか。
まぁもちろん読みやすく書く努力はすべきでだと思いますが。
Re:素敵なコード (スコア:2)
Re: (スコア:0)
あと再帰呼び出しでスタックを使い尽くすと、
問答無用で落ちちゃうはずじゃないかな。
Re:素敵なコード (スコア:2)
末尾再帰はコンパイラがループに変換してくれますよ。
それに、経験上、ツリーの探索を再帰を使わずに返って保守しづらいコードになります。
ケースバイケースで再帰は使うべきかと思います。
Re:素敵なコード (スコア:1)
でも、末尾再帰をループに変換してくれないコンパイラーというのもあってだな…
Re:素敵なコード (スコア:2)
そう言えば、自分の関わったプロジェクトで
g++コンパイラの最適化オプションを最初O2で開発していたのを、
デバッグしやすいようにとO0に変えたものがありました。
もし再帰呼び出しを使ってたら大ごとになったかも。
Re: (スコア:0)
間違えた。orz
(誤) それに、経験上、ツリーの探索を再帰を使わずに返って保守しづらいコードになります。
(正) それに、経験上、ツリーの探索を再帰を使わずに書くと返って保守しづらいコードになります。
-- staygold
Re: (スコア:0)
べつにいいじゃん
Re:素敵なコード (スコア:1)
性能上必要なコーディングと
表題の汚いコードは、全く別のものでしょ?
Re: (スコア:0)
賛成!
Re: (スコア:0)
わかりやすかったコードは素敵なコードで
分かりにくかったコードは汚いコード
にしたかったって可能性も考えておこうな
すてき・汚いってのが何をもって決まるのかを考えてみようね
Re: (スコア:0)
素敵なコードなんて夢を見ていないで、
無敵なコードを書け。
それで万事解決する。