アカウント名:
パスワード:
> 同僚の書く酷いコード、どうやって気づかせる?気づいても直らないかも。
気づかせるだけなら、スマートなコードを書いて比べさせればいいと思う。メンテナンスのしやすさ、修正が来たときの直しやすさ、良く使うならクラス化とか、そういうのは比べさせれば、とりあえず気づくと思う。一番いいのはダメージが大きくてもハッキリ言うこと。
でも直らないんじゃなかろうか。私は人並みにしかコードが書けませんが、人並み以下のコードを指摘しても直った試しがないです。
自分もそう思います。この人は1にしか対処できない人で、複数が見えないのだと思います。
1にしか対処できないので、世界をそれで対処可能な様に再定義しないと生きて行けないので、自然と再定義能力に富み、頭がいいと思われているだけかも、知れません。
あきらめて、(本家の)私さんがそのソースの全面的権限を得た時に、リファクタすればよいだけでは?
#人間の認識形態の問題になったら、なんであれ、直らないと思います。
> あきらめて、(本家の)私さんがそのソースの全面的権限を得た時に、リファクタ> すればよいだけでは?
分野にもよるんだろうけど、リファクタリングの機会って多い?「動いているコードは修正するな」なことが多いので、ベースがクソコードだと、それに対する機能追加・bug fixもadhocになりがち。
テストコードの資産が十分にあればリファクタリングしても比較的安全なんだろうけど、クソコードに対するテストコードが十分とは考えにくい...
「ベースがクソコードだと」という条件は、とうの昔にリファクタリングが必要になったにもかかわらず、それは長期間してこなかった結果だから。
そこまで行ったら既に手遅れ。#まるで「末期癌で、もはや手が付けられません。」状態。
もしやるならば、それは「リファクタリング」ではなく「作り直し」。
「リファクタリングの必要があるか?」なら、この場合は「必要があった」だろう。「リファクタリングする機会があるか?」なら「無いことも多い」。
なぜならば、リファクタリングする必要がある時に、それに気付かず手をこまねいているだけで、手遅れになるまで放置する無能なマネージャーがゴロゴロしてるから。
その昔「プレイングマネージャーって"Praying Manager"じゃね?」というのを見て、なるほどと思った。
なぜマネージャーが気付かないんですか?マネージャーがコードレビューしないから?コードの質は誰が把握してるんです?警告は誰が行う事になってるんですか?
#なんだろう、自分で書いていてなぜか胃の辺りが痛い…
ある中小企業での話。
>なぜマネージャーが気付かないんですか?マネージャーがコードレビューしないから?コードレビューどころかコードが読めません。上がってる報告も理解できないと豪語してました。
#というか、コードが読めるマネージャーって、日本に実在するんですか?#せいぜい「プログラミング言語の文法の基礎が分かる」程度では。#ちょっと難しいコードになるとお手上げで、コードの善し悪しを判断するなんて夢のまた夢。
>コードの質は誰が把握してるんです?おそらく私だけでしょう。私以外は誰一人読めなかったので、質が悪いことは他のメンバーも薄々気がついていたでしょうけど。
>警告は誰が行う事になってるんですか?特に決まっていませんでした。でも読めるのが私だけだし、そもそもコレを作った人たちは既に退職ずみなので後の祭り。前任者の負の遺産は、そりゃあ酷い物でした。
でもこういうことって、日本では増えてるんじゃないかな。ただでさえ若者の数が減り続けてるのに、その上IT業界のブラックさがネットで共有されて、新卒就職活動の常識になり、優秀な人材がIT業界を目指さなくなれば、IT業界の人材の質は年々悪化する一方だから。体感的にもそんな感じしませんか?
#絶対ACだ。
静的解析ツールとか使おうよ。利用費用は高いけど。潜在的なバグも減るよ。
静的「解析」ツールを使った所で、「バグが減る」わけないじゃん.減らすのは結局プログラマーの仕事なんだよ。解析ツールは何もやってくれない。せいぜいバグ候補をリストアップするだけ。
しかもこれはいたる所に不具合のあるスパゲッティプログラムの場合だから、バグの十や二十を見つけるのに手間はかからん。難しいのは「見つける」ことではなく「治す」こと。
それに静的解析ツールは、バグではない警告もわんさか出してくれるから、そのレベルのコードだと、意味の無い警告の山で役に立たんわ。
下手を打っても無駄な仕事が増えるだけ。#参考までに http://srad.jp/~YoR/journal/561405 [srad.jp]
この前、PL/SQLで、長いトップレベルBEGIN〜END;の一部をカットして引数なしの新設PROCEDUREにペーストするだけをしました。理由は、その一部分で何度も使う、そこだけでしか使わないカーソルを定義したかったからです。
(引数で引き回したり、変数名の変更をしたりの)大げさなリファクタリングでないやつでも、それなりに役立つと思います。
あと、
自分が、「そのソースの全面的権限を得た時に」と言ったのは、「その位してもOKな改修時」を想定していたので、もちろん、なんの件名も無く修正するのは絶対禁忌だと思います。
そういう変更って、コード書いている人がどういいう意図でそう記述しているかを確認しないと怖くないですか?
貴方の知らない技術的な意図があるのかもしれないし、意味の無いことであればそれを気づかせる必要がある。
>この前、PL/SQLで、長いトップレベルBEGIN〜END;の一部をカットして>引数なしの新設PROCEDUREにペーストするだけをしました。
の様な修正方法なら、「現行通り」だとおもいます。「現行通り」なら「知らない技術的な意図」が有っても問題ないと思います。
#そうでない変更なら、たしかに怖いです。
>>この前、PL/SQLで、長いトップレベルBEGIN〜END;の一部をカットして>>引数なしの新設PROCEDUREにペーストするだけをしました。
>の様な修正方法なら、「現行通り」だとおもいます。>「現行通り」なら「知らない技術的な意図」が有っても>問題ないと思います。
いや、Oracleの場合はたったそれだけでなにか変な現象が発生することがあるの。出会ったことない?
昭和の終わる時代にコーティングした事が有りますが、(PL/M-86)当時コンピュータ専門校卒が書いたコーテングがメニューの一つしか作成してないし、コメントは無し。(メニュー自体実装無い!)単独プログラムとしてはエラー無く動くので、本人は気づいていないでしょう。3日2夜費やしてメニュー項目を追加し、フラグジャンプに変更しました。(分岐処理部分はすべて書き直しプログラムを追加)その後他の部署に移動しましたが、本人は当初どうするつもりだったんだろと今でも疑問。
coating?コーテング?
多分ディスクトップパソコンでプログラミングしてたんだろうな。
>多分ディスクトップパソコンでプログラミングしてたんだろうな。うちの卓袱台は丸いから我が家で書いたのなら間違っていない記述かもしれない>>Disktop
気付かせる動機がわからない。彼の仕事は彼の仕事。私の仕事は私の仕事。私が彼の上司でなければ、無視すればいいだけ。上司だったら?命令すればいいだけ。
その次はわかるね?
気付かせる動機がわからない。
チーム開発だったら、糞コード書かれたら自分達にも影響するから直して欲しい、ってのは判るでしょ。
それに、ずっと“彼”が保守するなら良いけど、そうじゃなければ他人がそのコードを見ることになるし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
気づいても直らないかも。 (スコア:5, すばらしい洞察)
> 同僚の書く酷いコード、どうやって気づかせる?
気づいても直らないかも。
気づかせるだけなら、スマートなコードを書いて比べさせればいいと思う。
メンテナンスのしやすさ、修正が来たときの直しやすさ、良く使うならクラス化とか、
そういうのは比べさせれば、とりあえず気づくと思う。
一番いいのはダメージが大きくてもハッキリ言うこと。
でも直らないんじゃなかろうか。
私は人並みにしかコードが書けませんが、人並み以下のコードを指摘しても直った試しがないです。
Re: (スコア:0)
自分もそう思います。この人は1にしか対処できない人で、複数が見えないのだと
思います。
1にしか対処できないので、世界をそれで対処可能な様に再定義しないと生きて
行けないので、自然と再定義能力に富み、頭がいいと思われているだけかも、
知れません。
あきらめて、(本家の)私さんがそのソースの全面的権限を得た時に、リファクタ
すればよいだけでは?
#人間の認識形態の問題になったら、なんであれ、直らないと思います。
Re: (スコア:0)
> あきらめて、(本家の)私さんがそのソースの全面的権限を得た時に、リファクタ
> すればよいだけでは?
分野にもよるんだろうけど、リファクタリングの機会って多い?
「動いているコードは修正するな」なことが多いので、ベースがクソコードだと、
それに対する機能追加・bug fixもadhocになりがち。
テストコードの資産が十分にあればリファクタリングしても比較的安全なんだろうけど、
クソコードに対するテストコードが十分とは考えにくい...
Re:気づいても直らないかも。 (スコア:2)
「ベースがクソコードだと」という条件は、
とうの昔にリファクタリングが必要になったにもかかわらず、
それは長期間してこなかった結果だから。
そこまで行ったら既に手遅れ。
#まるで「末期癌で、もはや手が付けられません。」状態。
もしやるならば、それは「リファクタリング」ではなく「作り直し」。
「リファクタリングの必要があるか?」なら、この場合は「必要があった」だろう。
「リファクタリングする機会があるか?」なら「無いことも多い」。
なぜならば、リファクタリングする必要がある時に、それに気付かず手をこまねいているだけで、
手遅れになるまで放置する無能なマネージャーがゴロゴロしてるから。
その昔「プレイングマネージャーって"Praying Manager"じゃね?」というのを見て、なるほどと思った。
Re:気づいても直らないかも。 (スコア:1)
なぜマネージャーが気付かないんですか?マネージャーがコードレビューしないから?
コードの質は誰が把握してるんです?
警告は誰が行う事になってるんですか?
#なんだろう、自分で書いていてなぜか胃の辺りが痛い…
Re:気づいても直らないかも。 (スコア:1)
ある中小企業での話。
>なぜマネージャーが気付かないんですか?マネージャーがコードレビューしないから?
コードレビューどころかコードが読めません。
上がってる報告も理解できないと豪語してました。
#というか、コードが読めるマネージャーって、日本に実在するんですか?
#せいぜい「プログラミング言語の文法の基礎が分かる」程度では。
#ちょっと難しいコードになるとお手上げで、コードの善し悪しを判断するなんて夢のまた夢。
>コードの質は誰が把握してるんです?
おそらく私だけでしょう。
私以外は誰一人読めなかったので、質が悪いことは他のメンバーも薄々気がついていたでしょうけど。
>警告は誰が行う事になってるんですか?
特に決まっていませんでした。
でも読めるのが私だけだし、そもそもコレを作った人たちは既に退職ずみなので後の祭り。
前任者の負の遺産は、そりゃあ酷い物でした。
でもこういうことって、日本では増えてるんじゃないかな。
ただでさえ若者の数が減り続けてるのに、その上IT業界のブラックさがネットで共有されて、
新卒就職活動の常識になり、優秀な人材がIT業界を目指さなくなれば、IT業界の人材の質は
年々悪化する一方だから。
体感的にもそんな感じしませんか?
#絶対ACだ。
Re: (スコア:0)
静的解析ツールとか使おうよ。利用費用は高いけど。潜在的なバグも減るよ。
Re: (スコア:0)
Re: (スコア:0)
静的「解析」ツールを使った所で、「バグが減る」わけないじゃん.
減らすのは結局プログラマーの仕事なんだよ。
解析ツールは何もやってくれない。せいぜいバグ候補をリストアップするだけ。
しかもこれはいたる所に不具合のあるスパゲッティプログラムの場合だから、
バグの十や二十を見つけるのに手間はかからん。
難しいのは「見つける」ことではなく「治す」こと。
それに静的解析ツールは、バグではない警告もわんさか出してくれるから、
そのレベルのコードだと、意味の無い警告の山で役に立たんわ。
下手を打っても無駄な仕事が増えるだけ。
#参考までに http://srad.jp/~YoR/journal/561405 [srad.jp]
Re: (スコア:0)
この前、PL/SQLで、長いトップレベルBEGIN〜END;の一部をカットして
引数なしの新設PROCEDUREにペーストするだけをしました。
理由は、その一部分で何度も使う、そこだけでしか使わないカーソルを
定義したかったからです。
(引数で引き回したり、変数名の変更をしたりの)大げさなリファクタリングで
ないやつでも、それなりに役立つと思います。
あと、
自分が、「そのソースの全面的権限を得た時に」と言ったのは、「その位
してもOKな改修時」を想定していたので、
もちろん、なんの件名も無く修正するのは絶対禁忌だと思います。
Re: (スコア:0)
そういう変更って、コード書いている人が
どういいう意図でそう記述しているかを確認しないと怖くないですか?
貴方の知らない技術的な意図があるのかもしれないし、
意味の無いことであればそれを気づかせる必要がある。
Re: (スコア:0)
>この前、PL/SQLで、長いトップレベルBEGIN〜END;の一部をカットして
>引数なしの新設PROCEDUREにペーストするだけをしました。
の様な修正方法なら、「現行通り」だとおもいます。
「現行通り」なら「知らない技術的な意図」が有っても
問題ないと思います。
#そうでない変更なら、たしかに怖いです。
Re: (スコア:0)
>>この前、PL/SQLで、長いトップレベルBEGIN〜END;の一部をカットして
>>引数なしの新設PROCEDUREにペーストするだけをしました。
>の様な修正方法なら、「現行通り」だとおもいます。
>「現行通り」なら「知らない技術的な意図」が有っても
>問題ないと思います。
いや、Oracleの場合はたったそれだけでなにか変な現象が発生することがあるの。出会ったことない?
Re: (スコア:0)
昭和の終わる時代にコーティングした事が有りますが、(PL/M-86)
当時コンピュータ専門校卒が書いたコーテングがメニューの一つ
しか作成してないし、コメントは無し。(メニュー自体実装無い!)
単独プログラムとしてはエラー無く動くので、本人は気づいていないでしょう。
3日2夜費やしてメニュー項目を追加し、フラグジャンプに変更しました。
(分岐処理部分はすべて書き直しプログラムを追加)
その後他の部署に移動しましたが、本人は当初どうするつもり
だったんだろと今でも疑問。
Re: (スコア:0)
coating?
コーテング?
Re: (スコア:0)
多分ディスクトップパソコンでプログラミングしてたんだろうな。
Re: (スコア:0)
>多分ディスクトップパソコンでプログラミングしてたんだろうな。
うちの卓袱台は丸いから我が家で書いたのなら間違っていない記述かもしれない>>Disktop
Re: (スコア:0)
気付かせる動機がわからない。
彼の仕事は彼の仕事。私の仕事は私の仕事。
私が彼の上司でなければ、無視すればいいだけ。
上司だったら?命令すればいいだけ。
その次はわかるね?
Re: (スコア:0)
チーム開発だったら、糞コード書かれたら自分達にも影響するから直して欲しい、ってのは判るでしょ。
それに、ずっと“彼”が保守するなら良いけど、そうじゃなければ他人がそのコードを見ることになるし。