アカウント名:
パスワード:
糞な業務を蹴るのも、プロの仕事の一つ。
どうい。素直に見積もればいいんだけどね。お断り価格になるから。
>のでは無く、最悪なコードを見かけたらそれを最高に書き換えるのがプロの仕事。
うーん、リファクタリングもやりすぎると、ただの「アーティスト気取りの困ったチャン」だと思うんだけど？
最近関わったプロジェクトで、何個かアプリ納品したけど、一個飛び抜けて「異質な実装」してあるものがあって、かえって叩かれました。設計を説明してる最中の引き継ぎ先の目線がマジに痛かった。俺が実装したんじゃねえのにな（怒）
保守性の向上の中には既存のアプリと同等であるという部分も無いと無意味だと思うの？ｗｗｗ
> 設計を説明してる最中の引き継ぎ先の目線がマジに痛かった。俺が実装したんじゃねえのにな（怒）
「既存のコードから・・・と類推されます」とか「頂いた資料より・・・・」とか説明で言えばいいじゃん。客に勘違いさせている時点で正しく説明できていない。
火種は消しとけ
>火種は消しとけ
確かにねｗｗｗ
思わず、実装段階で俺がチェック出来る立場に居たらって思ったよ。俺も大勢いる要員の一人で、リーダーが自社要件とか言い出して逃亡したから、俺が説明に回ったんだよ。
内容チェックしたのが当日の朝だったから、もう死刑囚の気分だった（苦笑）
#俺も相手に同意して一緒に怒りたかったけど、俺は納品する側の人間だからねｗｗｗ
保守性の指標のひとつは「他とそろってる」ですからねえ
レベルが一定範囲内のほうがまだメンテしやすいです。ここで、下限だけではなく、上限もあるのがポイントです。
＞保守性の向上とか潜在バグの回避とか幾らでも説得材料はあるし。
それで説得できるケースってあるの？客にとって大事なのは、動いてる部分の維持保障とコストの増大を防ぐことだよ。その辺の説得材料をどう数値化してる？
同意。作り直すというモチベーションだけではビジネスにならないですね。直近の開発コストもそうですが、ソフトウェアのユーザにとってのメリットが提示できないと改修は難しい印象です。
再設計を主眼に置いた案件を獲得したことは何度かありますが、そのときは追加したい機能を建て増しするコストと、再設計した上で機能を追加するコストを天秤にかけて、後者をお客さんに選んでもらいました。コストの中に保守性や潜在バグに関する話も入りますが、商談の中心ではなかったですね。
完全に同意、これで説得されるお客てどういうお客なのか悩みますね。
外注慣れしていないと、こういうロクロ回転系の熱弁にほだされて、１回は騙されるんじゃないですかね。
最悪なコードにぶつかった事が無い人かしら、羨ましい。
●500行の関数が短く見える●コメントに嘘が混ざっている●入出力パラメータの意図がはっきりしない●コピペされたコードが散在し、コピペのうちの数行が異なっている、異なっている意味が分からない●ポリシーがわからない、あるのかないのかわからない、書いた奴がどの程度馬鹿なのか馬鹿じゃないのか分からない●一見バグに見えるコードが本当にバグの状態にあるのか信じられない●その状態で多くの人がメンテしてきて、もう誰が何をどういう意図で書いてるのかわけがわからない
まあ、全てを兼ね備えたプロジェクトがあったわけじゃないけど、1件だけパーフェクトに近いのがあったなあ。。。
>●5000行の関数が短く見える>●コメントの90%はコメントアウトされた修正前の古いコードか、コーディング規約で決められたテンプレート(中身はない)
日立系列の仕事か・・・
え、日本IBMじゃないんですか
なんだ，うちの会社のコードの品質って最底辺かと思ってたけど，世間でよくあるレベルの「最悪なコード」だったのか．
某Linuxデバイスドライバーを開発してもらった時のエピソード。ソースコードを納入してもらったんだけど、怪しげな書き方をしているところがありました。でもテストするとちゃんと動く。
一晩くらい悩んだら、どうして動くのか理解できました。少しロジックを変えれば意図がはっきりするという問題はあるにせよ、納入コードにちょっとコメントを追加してcheck inすればいいの話。後で同僚に解説したら「そんなの読み解けない」と言われた書き方でしたけど。(笑)
正式納品前に、そのコード担当者と打ち合わせがありました。もっとやさしく書けるのに、どうしてそんなに難しいコードを書くのですか?答えが「言われてみると、どうしてちゃんと動くか分かりません」だって。で、客側のこっちが「あなたのコードはこんな風に動いています」と説明する羽目になりました。(苦笑)
なお、この取引先って日本を代表する企業の名前を冠に戴いた企業。N○Cホゲホゲや東○ホゲホゲみたいな会社です。
「そんなの読み解けない」
ごめんなさい。「そんなの、私の解説なりコメントがなければ、読み解けない」に訂正です。
# 書き散らしよくない、よく校正するよろし。_ _;;
> のでは無く、最悪なコードを見かけたらそれを最高に書き換えるのがプロの仕事。
では無いなあ。趣味の世界なら結構なんだが、営利の世界の話ではそれ無いわな。志向としては大変結構だけど、現実的ではない、って話ね。
この話でもリファクタリングマンセーな人がいる様だけと、リファクタリングでカバー出来る範囲って、アルゴリズムかコーディングのレベルまでじゃない？糞プログラムって、要件とかアーキテクチャ段階から腐っているのも多くて、そういうのにはリファクタリングは有効とは言えないと思うよ。プログラムの外部I/Fを変更するとか、外部I/Fを変更は変更しないけどスクラップ＆ビルドとかまで、リファクタリングに含めるなら話は別だけどね。
> 保守性の向上とか潜在バグの回避とか幾らでも説得材料はあるし。
そういう理由でメンテをオーダーしてくるお客が居れば、そこのプログラムは糞プログラムで無い可能性があるよね。普通お客が気にするのは外部品質であって、良好な保守性とか潜在バグの少なさの様な内部品質なんか気にしていない。個人的には内部品質軽視には反対なんだが、世の中そうなっているから仕方がない。
まあ今みたいに「お客が怒り出さない程度の最低の（内部）品質」なんて方針でソフト屋が商売してると、そのうちしっぺ返しを食うだろうけどね。
判りやすくリフォームで例えると「木造二階建てのボロ家を三階建てにしてくれ、ただし増築分の資材と最低限の工賃しか出さない」みたいなクライアントが多いから避けてるんだろ。大黒柱が腐ってるからって安易に取り替えて崩壊したら誰が責任取るんだよ・・・
似たようなことを思った。
汚いコードを汚いまま放置しているクライアントは、コードの品質に金を出さないからこそ汚くなった。そういったクライアントが今更コード品質に金を出すようになるとは考えにくい。
その仕事に見合う金さえ出せばやってもいいよ。だけど彼等の提示する金額は桁が３～４桁以上少ないんだよ。
ものによるかな。特にスレッドセーフ、例外セーフを考慮されてないものを後から対応させるのは容易ではないです。
リファクタリングとか夢想してもなぁ。コードがきれいか汚いかとか、まともなコメントがあるかどうかなんてより、まともなUTコードがあるかどうかのほうが100倍大事。まともかどうか判断するのも大変だけどね。
既存コードの潜在バグなんて放っておくに限る。酷いコードを放ってあるようなところがお客様の動作条件とか把握していると思う？「最高のコード」が「予想外」の環境で、お客様に被害を与えたら、どうすんの？被害を増やすことが「プロの仕事」？
最悪なコードを見かけたらそれを最高に書き換えるのがプロの仕事。既に動いてる部分は触ってくれるなというクライアントも居るが、保守性の向上とか潜在バグの回避とか幾らでも説得材料はあるし。
「顧客が本当に欲しかったもの」をむやみに捻じ曲げるのはプロの仕事ではありませんね。
# 営業としては優秀なのかもしれませんが、全社的に見るとただの放火魔…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
発想が、ちょっと駄目かな (スコア:2)
のでは無く、最悪なコードを見かけたらそれを最高に書き換えるのがプロの仕事。
既に動いてる部分は触ってくれるなというクライアントも居るが、
保守性の向上とか潜在バグの回避とか幾らでも説得材料はあるし。
Re:発想が、ちょっと駄目かな (スコア:5, すばらしい洞察)
糞な業務を蹴るのも、プロの仕事の一つ。
Re:発想が、ちょっと駄目かな (スコア:1)
どうい。
素直に見積もればいいんだけどね。お断り価格になるから。
Re:発想が、ちょっと駄目かな (スコア:4, 興味深い)
>のでは無く、最悪なコードを見かけたらそれを最高に書き換えるのがプロの仕事。
うーん、リファクタリングもやりすぎると、ただの「アーティスト気取りの困ったチャン」だと思うんだけど？
最近関わったプロジェクトで、何個かアプリ納品したけど、一個飛び抜けて「異質な実装」してあるものがあって、かえって叩かれました。
設計を説明してる最中の引き継ぎ先の目線がマジに痛かった。俺が実装したんじゃねえのにな（怒）
保守性の向上の中には既存のアプリと同等であるという部分も無いと無意味だと思うの？ｗｗｗ
Re: (スコア:0)
> 設計を説明してる最中の引き継ぎ先の目線がマジに痛かった。俺が実装したんじゃねえのにな（怒）
「既存のコードから・・・と類推されます」とか「頂いた資料より・・・・」
とか説明で言えばいいじゃん。
客に勘違いさせている時点で正しく説明できていない。
火種は消しとけ
Re:発想が、ちょっと駄目かな (スコア:1)
>火種は消しとけ
確かにねｗｗｗ
思わず、実装段階で俺がチェック出来る立場に居たらって思ったよ。
俺も大勢いる要員の一人で、リーダーが自社要件とか言い出して逃亡したから、俺が説明に回ったんだよ。
内容チェックしたのが当日の朝だったから、もう死刑囚の気分だった（苦笑）
#俺も相手に同意して一緒に怒りたかったけど、俺は納品する側の人間だからねｗｗｗ
Re: (スコア:0)
保守性の指標のひとつは「他とそろってる」ですからねえ
レベルが一定範囲内のほうがまだメンテしやすいです。
ここで、下限だけではなく、上限もあるのがポイントです。
Re:発想が、ちょっと駄目かな (スコア:2, すばらしい洞察)
＞保守性の向上とか潜在バグの回避とか幾らでも説得材料はあるし。
それで説得できるケースってあるの？
客にとって大事なのは、動いてる部分の維持保障とコストの増大を防ぐことだよ。
その辺の説得材料をどう数値化してる？
Re:発想が、ちょっと駄目かな (スコア:1)
同意。作り直すというモチベーションだけではビジネスにならないですね。直近の開発コストもそうですが、ソフトウェアのユーザにとってのメリットが提示できないと改修は難しい印象です。
再設計を主眼に置いた案件を獲得したことは何度かありますが、そのときは追加したい機能を建て増しするコストと、再設計した上で機能を追加するコストを天秤にかけて、後者をお客さんに選んでもらいました。コストの中に保守性や潜在バグに関する話も入りますが、商談の中心ではなかったですね。
Re: (スコア:0)
完全に同意、これで説得されるお客てどういうお客なのか悩みますね。
Re: (スコア:0)
外注慣れしていないと、こういうロクロ回転系の熱弁にほだされて、１回は騙されるんじゃないですかね。
Re:発想が、ちょっと駄目かな (スコア:1)
最悪なコードにぶつかった事が無い人かしら、羨ましい。
●500行の関数が短く見える
●コメントに嘘が混ざっている
●入出力パラメータの意図がはっきりしない
●コピペされたコードが散在し、コピペのうちの数行が異なっている、異なっている意味が分からない
●ポリシーがわからない、あるのかないのかわからない、書いた奴がどの程度馬鹿なのか馬鹿じゃないのか分からない
●一見バグに見えるコードが本当にバグの状態にあるのか信じられない
●その状態で多くの人がメンテしてきて、もう誰が何をどういう意図で書いてるのかわけがわからない
まあ、全てを兼ね備えたプロジェクトがあったわけじゃないけど、1件だけパーフェクトに近いのがあったなあ。。。
Re:発想が、ちょっと駄目かな (スコア:2, おもしろおかしい)
●コメントの90%はコメントアウトされた修正前の古いコードか、コーディング規約で決められたテンプレート(中身はない)
●モジュール間のデータのやりとりは基本的にグローバル変数なので入力パラメータも出力パラメータもない
●コピペされたコードが散在し、完全に一致している。指摘しても修正工数がないのでそのまま、さらにもう一つコピペが作られる
●最初に書いた設計者は天才だったようだ。明確なポリシーにもとづく教科書に載せたいくらい鮮やかな実装がそこにあった。ただし、外注だった彼はもういない。それを修正した何人ものプロパーはみんなアホ。完全に元のコードを破壊している
●どう見てもバグに見えるコードは本当にバグっているが、それが仕様で正しい
●だから誰もが自分の責任範囲を極小化することだけにキュウキュウとしている。個別部分の意図は痛いくらい分かるが、全体としては意味をなしていない。
Re: (スコア:0)
>●5000行の関数が短く見える
>●コメントの90%はコメントアウトされた修正前の古いコードか、コーディング規約で決められたテンプレート(中身はない)
日立系列の仕事か・・・
Re: (スコア:0)
え、日本IBMじゃないんですか
Re:発想が、ちょっと駄目かな (スコア:1)
なんだ，うちの会社のコードの品質って最底辺かと思ってたけど，世間でよくあるレベルの「最悪なコード」だったのか．
こりゃ駄目と思った実例 (スコア:1)
某Linuxデバイスドライバーを開発してもらった時のエピソード。ソースコードを納入してもらったんだけど、怪しげな書き方をしているところがありました。でもテストするとちゃんと動く。
一晩くらい悩んだら、どうして動くのか理解できました。少しロジックを変えれば意図がはっきりするという問題はあるにせよ、納入コードにちょっとコメントを追加してcheck inすればいいの話。後で同僚に解説したら「そんなの読み解けない」と言われた書き方でしたけど。(笑)
正式納品前に、そのコード担当者と打ち合わせがありました。もっとやさしく書けるのに、どうしてそんなに難しいコードを書くのですか?答えが「言われてみると、どうしてちゃんと動くか分かりません」だって。で、客側のこっちが「あなたのコードはこんな風に動いています」と説明する羽目になりました。(苦笑)
なお、この取引先って日本を代表する企業の名前を冠に戴いた企業。N○Cホゲホゲや東○ホゲホゲみたいな会社です。
vyama 「バグ取れワンワン」
Re:こりゃ駄目と思った実例 (スコア:1)
ごめんなさい。「そんなの、私の解説なりコメントがなければ、読み解けない」に訂正です。
# 書き散らしよくない、よく校正するよろし。_ _;;
vyama 「バグ取れワンワン」
Re:発想が、ちょっと駄目かな (スコア:1)
> のでは無く、最悪なコードを見かけたらそれを最高に書き換えるのがプロの仕事。
では無いなあ。趣味の世界なら結構なんだが、営利の世界の話ではそれ無いわな。志向としては大変結構だけど、現実的ではない、って話ね。
この話でもリファクタリングマンセーな人がいる様だけと、リファクタリングでカバー出来る範囲って、アルゴリズムかコーディングのレベルまでじゃない？糞プログラムって、要件とかアーキテクチャ段階から腐っているのも多くて、そういうのにはリファクタリングは有効とは言えないと思うよ。プログラムの外部I/Fを変更するとか、外部I/Fを変更は変更しないけどスクラップ＆ビルドとかまで、リファクタリングに含めるなら話は別だけどね。
> 保守性の向上とか潜在バグの回避とか幾らでも説得材料はあるし。
そういう理由でメンテをオーダーしてくるお客が居れば、そこのプログラムは糞プログラムで無い可能性があるよね。普通お客が気にするのは外部品質であって、良好な保守性とか潜在バグの少なさの様な内部品質なんか気にしていない。個人的には内部品質軽視には反対なんだが、世の中そうなっているから仕方がない。
まあ今みたいに「お客が怒り出さない程度の最低の（内部）品質」なんて方針でソフト屋が商売してると、そのうちしっぺ返しを食うだろうけどね。
Re: (スコア:0)
判りやすくリフォームで例えると
「木造二階建てのボロ家を三階建てにしてくれ、ただし増築分の資材と最低限の工賃しか出さない」
みたいなクライアントが多いから避けてるんだろ。
大黒柱が腐ってるからって安易に取り替えて崩壊したら誰が責任取るんだよ・・・
Re:発想が、ちょっと駄目かな (スコア:1)
似たようなことを思った。
汚いコードを汚いまま放置しているクライアントは、コードの品質に金を出さないからこそ
汚くなった。そういったクライアントが今更コード品質に金を出すようになるとは考えにくい。
その仕事に見合う金さえ出せばやってもいいよ。
だけど彼等の提示する金額は桁が３～４桁以上少ないんだよ。
Re: (スコア:0)
ものによるかな。
特にスレッドセーフ、例外セーフを考慮されてないものを
後から対応させるのは容易ではないです。
Re: (スコア:0)
リファクタリングとか夢想してもなぁ。
コードがきれいか汚いかとか、まともなコメントがあるかどうかなんてより、まともなUTコードがあるかどうかのほうが100倍大事。
まともかどうか判断するのも大変だけどね。
既存コードの潜在バグなんて放っておくに限る。
酷いコードを放ってあるようなところがお客様の動作条件とか把握していると思う？
「最高のコード」が「予想外」の環境で、お客様に被害を与えたら、どうすんの？
被害を増やすことが「プロの仕事」？
Re: (スコア:0)
「顧客が本当に欲しかったもの」をむやみに捻じ曲げるのはプロの仕事ではありませんね。
# 営業としては優秀なのかもしれませんが、全社的に見るとただの放火魔…。