パスワードを忘れた? アカウント作成
6512685 story
プログラミング

既存のコードの質を依頼を受ける前に確かめる方法は? 117

ストーリー by headless
難題 部門より
danceman 曰く、

Ask Slashdot: How To Avoid Working With Awful Legacy Codeより

私は10年ほどソフトウェアエンジニアとして仕事をしているが、新しいソフトウェアを一から作る仕事を依頼されることはほとんどないため、仕事の満足度は既存のコードの質に左右される傾向がある。既存のコードの中には出来のいいものもあるが、出来のよくないものがほとんどだ。そのため、面接時に「最新の技術が使われているか」「コードレビューを実施しているか」「テスト駆動開発を実施しているか」といった質問でコードの質を確認するのだが、それでも最悪な出来のコードに出会うことがある。最悪なコードを避けるため、/.erならどのような質問をするだろうか。コードの質を事前に確認するよい方法が他にもあればお教えいただきたい。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2012年10月27日 17時25分 (#2260425)

    ドキュメントのまとめ方である程度傾向は判断出来る
    詳細仕様・テスト仕様の改版履歴とレビュー結果報告だけでも見ればずいぶん傾向は見える。
    更にchangelogを見せてもらえれば言う事無し。

  • 確かめるまでもない。 (スコア:5, すばらしい洞察)

    by tarosuke (2403) <webmaster@tarosuke.net> on 2012年10月27日 19時32分 (#2260517) 日記

    どこかの誰かが手に負えなくなったからこそそういう仕事が発生したんだ。
    最初に作った奴の手に負えるならそいつに発注されてるさ。
    そして手に負えなくなった原因は...あとはわかるな?
    既存コードの修正依頼なんてのにマトモなコードはないと思ったほうがいい。
    # 少なくとも最初の会社で請けてたのは100%そうだった。

  • >最悪なコードを避ける
    のでは無く、最悪なコードを見かけたらそれを最高に書き換えるのがプロの仕事。
    既に動いてる部分は触ってくれるなというクライアントも居るが、
    保守性の向上とか潜在バグの回避とか幾らでも説得材料はあるし。
    • by miyuri (33181) on 2012年10月27日 18時14分 (#2260463) 日記

      糞な業務を蹴るのも、プロの仕事の一つ。

      親コメント
    • by YF19 (12943) on 2012年10月27日 17時56分 (#2260445) 日記

      >のでは無く、最悪なコードを見かけたらそれを最高に書き換えるのがプロの仕事。

      うーん、リファクタリングもやりすぎると、ただの「アーティスト気取りの困ったチャン」だと思うんだけど?

      最近関わったプロジェクトで、何個かアプリ納品したけど、一個飛び抜けて「異質な実装」してあるものがあって、かえって叩かれました。
      設計を説明してる最中の引き継ぎ先の目線がマジに痛かった。俺が実装したんじゃねえのにな(怒)

      保守性の向上の中には既存のアプリと同等であるという部分も無いと無意味だと思うの?www

      親コメント
    • by Anonymous Coward on 2012年10月27日 17時22分 (#2260423)

      >保守性の向上とか潜在バグの回避とか幾らでも説得材料はあるし。

      それで説得できるケースってあるの?
      客にとって大事なのは、動いてる部分の維持保障とコストの増大を防ぐことだよ。
      その辺の説得材料をどう数値化してる?

      親コメント
      • by Anonymous Coward on 2012年10月28日 10時07分 (#2260724)

        同意。作り直すというモチベーションだけではビジネスにならないですね。直近の開発コストもそうですが、ソフトウェアのユーザにとってのメリットが提示できないと改修は難しい印象です。

        再設計を主眼に置いた案件を獲得したことは何度かありますが、そのときは追加したい機能を建て増しするコストと、再設計した上で機能を追加するコストを天秤にかけて、後者をお客さんに選んでもらいました。コストの中に保守性や潜在バグに関する話も入りますが、商談の中心ではなかったですね。

        親コメント
    • by Anonymous Coward on 2012年10月27日 20時04分 (#2260549)

      最悪なコードにぶつかった事が無い人かしら、羨ましい。

      ●500行の関数が短く見える
      ●コメントに嘘が混ざっている
      ●入出力パラメータの意図がはっきりしない
      ●コピペされたコードが散在し、コピペのうちの数行が異なっている、異なっている意味が分からない
      ●ポリシーがわからない、あるのかないのかわからない、書いた奴がどの程度馬鹿なのか馬鹿じゃないのか分からない
      ●一見バグに見えるコードが本当にバグの状態にあるのか信じられない
      ●その状態で多くの人がメンテしてきて、もう誰が何をどういう意図で書いてるのかわけがわからない

      まあ、全てを兼ね備えたプロジェクトがあったわけじゃないけど、1件だけパーフェクトに近いのがあったなあ。。。

      親コメント
      • by Anonymous Coward on 2012年10月28日 4時11分 (#2260685)
        ●5000行の関数が短く見える
        ●コメントの90%はコメントアウトされた修正前の古いコードか、コーディング規約で決められたテンプレート(中身はない)
        ●モジュール間のデータのやりとりは基本的にグローバル変数なので入力パラメータも出力パラメータもない
        ●コピペされたコードが散在し、完全に一致している。指摘しても修正工数がないのでそのまま、さらにもう一つコピペが作られる
        ●最初に書いた設計者は天才だったようだ。明確なポリシーにもとづく教科書に載せたいくらい鮮やかな実装がそこにあった。ただし、外注だった彼はもういない。それを修正した何人ものプロパーはみんなアホ。完全に元のコードを破壊している
        ●どう見てもバグに見えるコードは本当にバグっているが、それが仕様で正しい
        ●だから誰もが自分の責任範囲を極小化することだけにキュウキュウとしている。個別部分の意図は痛いくらい分かるが、全体としては意味をなしていない。
        親コメント
      • by Anonymous Coward on 2012年10月27日 23時10分 (#2260629)

        なんだ,うちの会社のコードの品質って最底辺かと思ってたけど,世間でよくあるレベルの「最悪なコード」だったのか.

        親コメント
      • 某Linuxデバイスドライバーを開発してもらった時のエピソード。ソースコードを納入してもらったんだけど、怪しげな書き方をしているところがありました。でもテストするとちゃんと動く。

        一晩くらい悩んだら、どうして動くのか理解できました。少しロジックを変えれば意図がはっきりするという問題はあるにせよ、納入コードにちょっとコメントを追加してcheck inすればいいの話。後で同僚に解説したら「そんなの読み解けない」と言われた書き方でしたけど。(笑)

        正式納品前に、そのコード担当者と打ち合わせがありました。もっとやさしく書けるのに、どうしてそんなに難しいコードを書くのですか?答えが「言われてみると、どうしてちゃんと動くか分かりません」だって。で、客側のこっちが「あなたのコードはこんな風に動いています」と説明する羽目になりました。(苦笑)

        なお、この取引先って日本を代表する企業の名前を冠に戴いた企業。N○Cホゲホゲや東○ホゲホゲみたいな会社です。

        --
        vyama 「バグ取れワンワン」
        親コメント
    • by Anonymous Coward on 2012年10月28日 11時26分 (#2260743)

      > のでは無く、最悪なコードを見かけたらそれを最高に書き換えるのがプロの仕事。

      では無いなあ。趣味の世界なら結構なんだが、営利の世界の話ではそれ無いわな。志向としては大変結構だけど、現実的ではない、って話ね。

      この話でもリファクタリングマンセーな人がいる様だけと、リファクタリングでカバー出来る範囲って、アルゴリズムかコーディングのレベルまでじゃない?糞プログラムって、要件とかアーキテクチャ段階から腐っているのも多くて、そういうのにはリファクタリングは有効とは言えないと思うよ。プログラムの外部I/Fを変更するとか、外部I/Fを変更は変更しないけどスクラップ&ビルドとかまで、リファクタリングに含めるなら話は別だけどね。

      > 保守性の向上とか潜在バグの回避とか幾らでも説得材料はあるし。

      そういう理由でメンテをオーダーしてくるお客が居れば、そこのプログラムは糞プログラムで無い可能性があるよね。普通お客が気にするのは外部品質であって、良好な保守性とか潜在バグの少なさの様な内部品質なんか気にしていない。個人的には内部品質軽視には反対なんだが、世の中そうなっているから仕方がない。

      まあ今みたいに「お客が怒り出さない程度の最低の(内部)品質」なんて方針でソフト屋が商売してると、そのうちしっぺ返しを食うだろうけどね。

      親コメント
    • by Anonymous Coward

      判りやすくリフォームで例えると
      「木造二階建てのボロ家を三階建てにしてくれ、ただし増築分の資材と最低限の工賃しか出さない」
      みたいなクライアントが多いから避けてるんだろ。
      大黒柱が腐ってるからって安易に取り替えて崩壊したら誰が責任取るんだよ・・・

      • 似たようなことを思った。

        汚いコードを汚いまま放置しているクライアントは、コードの品質に金を出さないからこそ
        汚くなった。そういったクライアントが今更コード品質に金を出すようになるとは考えにくい。

        その仕事に見合う金さえ出せばやってもいいよ。
        だけど彼等の提示する金額は桁が3~4桁以上少ないんだよ。

        親コメント
  • by Anonymous Coward on 2012年10月27日 17時48分 (#2260442)

    何を使ってるか、どれくらい前から使ってるか、どんな風に使っているかも聞いておく…

  • > 1. 10 以下であればよい構造 > 2. 30 を越える場合,構造に疑問 > 3. 50 を越える場合,テストが不可能 > 4. 75 を越える場合,いかなる変更も誤修正を生む原因を作る フリーソフトもあるし http://www.campwoodsw.com/sourcemonitor.html [campwoodsw.com] プロならコード見ればどんなやつが作ったかまで一目でわかると思うけどね。
  • 我慢しなさい (スコア:0, オフトピック)

    by Anonymous Coward on 2012年10月27日 16時35分 (#2260394)

    > 新しいソフトウェアを一から作る仕事を依頼されることはほとんどないため

    その程度の人と見なされてるんじゃないの?

    • Re:我慢しなさい (スコア:5, 参考になる)

      by Anonymous Coward on 2012年10月27日 17時52分 (#2260443)

      逆だよ、出来ない奴に最悪のコード渡したら、よりひどくなって収拾がつかない。
      低レベルの奴に難易度の高い仕事回すほうがどうかしてるだろ。しがらみがない分、修正より一から作るほうが簡単だもの。
      だから、出来る人と見なされている彼に出来の悪いコードの修正が集まってくるんだよ。

      そう思わんと人生やっとれんわ・・・

      親コメント
      • by YF19 (12943) on 2012年10月27日 18時07分 (#2260455) 日記

        同感。いわゆる業務アプリ系メインでやってると、改修案件が大半を占める。

        でもって、既存の出来の悪さがそのまま成果物の質を左右してくれるんで、やる度に気分が悪くなるのも確か。

        「それは元からある仕様です」この台詞を素直に受け取ってくれる人はほとんどいません。
        で、勝手に直したら、それはそれで問題になるし、事前に指摘して、直さない方針になっても、お客さんは怒るしwww

        親コメント
    • by Anonymous Coward

      既存システムの変更なのに、ソースがカオスで、
      社内ではどうにも手の施しようがない案件の依頼とかあります。

      #外注にまわってくるのはそんなのばかり。火消しや人身御供も。

  • by Anonymous Coward on 2012年10月27日 16時35分 (#2260395)

    確実な方法は、
    ソースの一部を見せてもらうこと。
    一目瞭然です。

    #部分的には勉強になるときもあるが、
    #元ソースの出来がよかったためしがない。

    • by Anonymous Coward on 2012年10月28日 2時47分 (#2260676)

      ある程度の規模のシステムならソースなんて全部読んでいられない。
      ごく一部のダメコードが広範囲に影響する事もあるし。

      それより、開発ツールを聞いて、コード解析レポートを提出させて、「テストの」デモをさせた方がいい。
      アプリのデモだけでは駄目。
      ちゃんと動く部分しか見せないから。

      xUnitを使っていれば、コードカバレッジがわかる。
      静的コード解析ツール(Code Sniffer, Mess Detector等)を使っていれば、コード規約違反やダメコードの有無がわかる。
      CIツール(Jenkins等)を使っていれば、テストが自動化されているかどうかがわかる。

      あと質問者はコードについてだけ聞いてるけど、実際にはミドルウェアも気にしないと駄目。
      とっくに開発が終わってたりコミュニティが小さいフレームワークやストレージエンジンを使ってると、保守ができない。

      親コメント
    • by Anonymous Coward

      契約する前に見られることはまずない。
      契約するかどうか決めるのに質を見たいというのだから採用できない案かと。

      • by Anonymous Coward

        逆に自分のサンプルソースを見せて相手の反応を試してみては
        先方のエンジニアも呼んで

        案外自分の方がひどかったりしてw

  • by Anonymous Coward on 2012年10月27日 16時43分 (#2260402)

    「動くこと」だけは保証するけど、コードの質を保証するもんじゃないでしょ。

    コードレビューだって、自分の仕事とかかわってこない部分の他人のコードは、さほど真剣に読まないよな。
    書いた本人が取り組んでいる問題の深さのレベルに、そう簡単に到達できるとは思えないし。
    そんな暇あったら自分の仕事を進める。

    • by flied onion (36971) on 2012年10月27日 20時37分 (#2260566) 日記
      それはお客様向け動作確認テストをしただけであって、テスト駆動ではないです。

      テスト駆動は、
      仕様をテストという形でコードに起こす。
      テストは自動化されているのでいつでも繰り返しテストができる。
      テストがいつでもできるので、リファクタリングというコード品質改善プロセスを安心して行える。
      リファクタリングが済んだら次の仕様をテストに起こす。
      次の仕様をクリアする段階で既にあるコードに手が入り、問題が発生しても(既にあるコード向けの)テストを実行すればクリアできる。
      です。

      コード書いてて、これちゃんとうごくんだっけと別窓で簡単な確認コード書いた経験があるなら、それをもっと体系的に製造プロセスに盛りこまれたような感じです。
      そしてその確認コードが動く限りメソッドの抽出などのリファクタリングを行っても、自分の欲しい部品であり続けてる(壊れてない)。壊れてないことが確認できる方法があるんだからリファクタリングに取り掛かりやすい。リファクタリングしているからメンテナンス性が向上される。ここまで含めなければテスト駆動開発とは言えません(習熟中で不完全な場合は仕方ないですけどね)。

      あと、テスト駆動用に書いたテストですべてがテストされるわけではないので、普通のテストもしますね。(『そこを指して「動くこと」だけは保証するけど』なんでしょうが。)
      誤解を恐れず言えば、アプリケーションが動くことまではカバーしません(どこまでのテストコードを書くかはチームによるでしょう、最近はメソッド単体ではなく、併せて一連の動作のテストも書くといいという話も出てますし)。

      もちろん理想と現実はありますが、それでもテストコードが少しでもあると全くないとでは全然違うと最近よく思います。

      # 中途半端だと全部グリーンじゃない状態で放置されてたりすることもあったり。
      --
      # yes, fly. no, fry.
      親コメント
      • by Ryo.F (3896) on 2012年10月28日 10時17分 (#2260725) 日記

        それが「コードの品質」ってことなんだよね。ソフトウェア開発における「品質」ってのは、一般に理解されている品質とはちょっと意味が違っていて、仕様通りに実装されているかどうか、を指す。達人的に超絶コーディングされている、という意味ではない。

        テスト自体が仕様なのであれば、テスト駆動で「品質」を保証できるってことになる。
        一方、仕様自体にバグがあれば、コードの「品質」はクリアしてるのに動かないってこともありうる。

        もっとも、テストに書ききれない仕様やコーディング規約ってのはあるかも知れないので、テスト駆動だけで「品質」をすべてカバーできるわけじゃないだろうね。

        親コメント
        • by firewheel (31280) on 2012年10月29日 7時39分 (#2261171)

          >ソフトウェア開発における「品質」ってのは、一般に理解されている品質とはちょっと意味が違っていて、
          >仕様通りに実装されているかどうか、を指す。達人的に超絶コーディングされている、という意味ではない。
          むしろ逆じゃね?
          仕様書通りに作ってさえいれば、どんなに糞コードでも「高品質」であるなんて行ってる奴の方が珍しいと思う。
          あなたがSI的オレオレ品質定義に染まってるだけではないかと。

          普通はもっと広義で品質という単語を使ってると思いますよっと。

          親コメント
          • by Ryo.F (3896) on 2012年10月29日 8時35分 (#2261186) 日記

            あなたがSI的オレオレ品質定義に染まってるだけではないかと。
            普通はもっと広義で品質という単語を使ってると思いますよっと。

            はい。私も最初からその様に言ってますね。「普通は」「達人的に超絶コーディングされている」ようなものを品質が高いと評する、と。

            しかしながら、SI業界をはじめとするISO 9000 [atmarkit.co.jp]が通用するような業界では、「品質」と言えば、仕様通りにモノが作られていることを指します。敢えて言うなら、「SI的オレオレ品質定義」ではなく、ISO 9000的定義でしょうか。

            なお、ISO 9000的定義では、場合によっては、仕様よりも精度が高すぎることすら高「品質」ではない、と判断されます。精度は費用に返ってきますし、費用も含めて設計されているからです。

            仕様書通りに作ってさえいれば、どんなに糞コードでも「高品質」であるなんて行ってる奴の方が珍しいと思う。

            それならば、どう書けば「糞コード」でないかを明示すべきですね。普通は、コーディング規約とかでやるんじゃないですか。
            職人みたいに「見て盗め」じゃダメです。個人的にはそうしてほしいですが。

            親コメント
    • by Anonymous Coward

      結局、コードの品質を保つために実施している施策はありますか?程度だよね。

      #プロジェクトの途中で、面接して人を集めだしている案件なんて、地雷臭しかしない。

      • by Anonymous Coward on 2012年10月27日 17時00分 (#2260411)

        結局、コードの品質を保つために実施している施策はありますか?程度だよね。

        #プロジェクトの途中で、面接して人を集めだしている案件なんて、地雷臭しかしない。

        なるほど。

        「御社の有給休暇消化率の時間変化をグラフで示してください」
        「一人当たりの残業時間数を示してください。え? 『書類上は』残業ゼロ?」
        「御社社員一人が同時に抱えている案件数はいかほどでしょうか?」
        「御社営業担当は、御社の事業内容をしっかりと理解して案件を契約して来ていますか?」
        「御社社長は、どの畑からの出身でしょうか」
        「一人当たり、どれだけのワークスペースが割り当てられてますでしょうか。
         島型オフィスで、隣とひじがぶつかるような環境ですか?スペーサで一人ずつ個別の環境になってますか?」
        「コンパイル環境が一人ひとつ以下とか、順番待ちで作業がとまるようなライセンス契約とかはないですよね。」

        これらにまともな回答が戻ってくる企業なら受けても大丈夫、って
        そんな企業から外部に発注するわけない

        親コメント
        • by nmaeda (5111) on 2012年10月27日 19時41分 (#2260532)

          >「御社営業担当は、御社の事業内容をしっかりと理解して案件を契約して来ていますか?」

          さすがに事業内容は知っているさ。自社、つまり、技術者それぞれの専門や能力、スケジュールを把握しているかでしょうね。
          典型的な無能な営業は、安請け合いするか、何も出来ないというか、どちらかだから。

          もちろん、外注に廻すにしても、社内の技術者に中身を把握してもらって、打ち合わせにも出席してもらわないと、営業だけでは価格や納期も設定できないし。できれば外注管理も担当して欲しいし。

          >「一人当たり、どれだけのワークスペースが割り当てられてますでしょうか。
          > 島型オフィスで、隣とひじがぶつかるような環境ですか?スペーサで一人ずつ個別の環境になってますか?」

          島型だと、レイアウト変更が自由なので便利だよ。機材が必要な時は机を二つ使ったり。仕事をし出せばどうせ周りは目に入らないし。

          >そんな企業から外部に発注するわけない

          ん? 社内だけでこなせる量の仕事しか取ってこれない営業なら、それは問題では?

          受注量に山谷があるのは自然なことだし、社内の技術者にもそれぞれの専門(得意)分野もあるのだから、年間を通せば、外注に出す仕事が一定量ないと遊びが出来ることになる。

          親コメント
        • by Anonymous Coward

          何の話をしてるんですかね?

    • "メンテのしやすさを考えたコードになってる可能性が高い"
      と予測するのはあながち的外れではないんちゃうかと

  • グーグルやfacebookに憧れてるようなボーズがCEO(笑)をしているような自称WEBクリエイター会社だけ

typodupeerror

普通のやつらの下を行け -- バッドノウハウ専門家

読み込み中...