引き継いだプログラム、「自分のもの」にするには ? 82
ストーリー by reo
読む価値の有無に関わらず読まねばならん事もある 部門より
読む価値の有無に関わらず読まねばならん事もある 部門より
あるAnonymous Coward 曰く、
本家「Learning and Maintaining a Large Inherited Codebase ?」より。
この仕事に就いてから、比較的大きなプログラム (3 ～ 4 万行程度) を何度か引き継いだことがある。元々の開発者らは、自分の書いたコードでもあるし (その仕様や動きを) よく理解していたが、自分はそこまでとは言えない。実際、プログラムに修正を入れる際は修正そのものよりも修正を入れるべき正しい位置を探すのに多くの時間がかかってしまう。
このように引き継いだプログラム、どうやったら理解できるようになるのだろうか ? 元の開発者らほどこのプログラムを「理解」できないのは自分の力量の問題ではなく、仕方がないことなのだろうか ?
本家 /. には「一から作り直したくなるだろうが、それは絶対に避けるべきだ。汚く見えるコードにも、全て理由があったりするものだ。開発時の相談や議論、意思決定までの過程にいなかったからコードが理解できないのである。一から作り直しても、そういった問題への理解は深まったりはしない。苦労してバグを直したり、修正を入れたりしてこそ分かるようになるものであるし、そうやって分かるようになれば作り直す必要もなくなる」といった経験からくるコメントなどが多く寄せられている。
やはり「ドキュメントも無く、元の開発者に質問できないのだとすれば、時間をかけてコードを読み砕くしかない」のだろうか ? /.Jer は引き継いだプログラムをどうやって「自分のもの」にしている ?
仕様化テストの出番 (スコア:3, 参考になる)
そんなことする時間なんて与えられないよ! とか言われそうな気もしますが、他人が書いた製品の仕様を理解するのに、仕様化テストは役に立ちました。
仕様化テストのおかげでバグを大量に発見し、それで忙しくなりましたが…。
レガシーコード改善ガイド
http://www.amazon.co.jp/dp/4798116831 [amazon.co.jp]
web でも一部読めます。
http://codezine.jp/article/corner/308 [codezine.jp]
Re:仕様化テストの出番 (スコア:1)
属人化 (スコア:3, すばらしい洞察)
属人化しないことが求められているのに、結局、属人化してしまう。
話が違うのか？
いつまでも呼び出されたり、聞かれたりしたくないよね？
Re:擬人化(おふとぴ:-１) (スコア:1, すばらしい洞察)
擬人化に空目した自分はもう駄目かもしれない。
#しつけのなってないコードたんを一人前のレディに教育だ! と思えば思い入れで自分ものに出来るかもしれない。。。かな?
Re:擬人化(おふとぴ:-１) (スコア:1)
中古は。。。(ry
# 実際には創造性が無いので中古しか扱えないし、指導してもらってます。
マクロの基本は検索置換(by y.mikome)
Re: (スコア:0)
属人化をどう考えるかは立場かによりますね。
経営者や管理者にとっては属人化はデメリットなのでしょうが、末端の技術者にとって
切り捨てられない為の重要な手段だと思います。世界のためには不都合でも、自分のた
めには武器なのです。
そうしないと自分の仕事がどんどん安い人たちに置き換えられてしまいますし。
Re:属人化 (スコア:2, 興味深い)
自分にしかわからないようなコードを書いてると評価が低くなるのが普通では？
評価が下がったら給料も下がるし解雇(もしくは契約更新せず)もあるのでは？
Re:属人化 (スコア:2, すばらしい洞察)
Re:属人化 (スコア:1)
悪戦苦闘した結果、身体やら精神やらを壊して休む羽目になって、
再び評価を下げてしまうんですね。
# 下がると戻らないともいう
Re:属人化 (スコア:1, 参考になる)
> そうしないと自分の仕事がどんどん安い人たちに置き換えられてしまいますし。
そんな小細工しても、『実物とソースがあればオフショア受けまっせ！』なんて
言ってる連中もいるらしいので、（本当に可能で事実だとしたら）無駄では？
『ソースがあれば』について余談：
開発チーム内にもソースを見せないド阿呆が居たことがあります。
そいつのモジュールがどう考えてもおかしいので、ディスアセンブルしてバグ
指摘したことが・・・。なにやってたんだろうね。
Re: (スコア:0)
Re: (スコア:0)
属人化の定義にもよるけれど、「属人化しないこと」は目的ではない。
「属人化するな」の多くが、プログラミングのできない奴の戯言だったりするんだよな。
また、多くの「属人化していないコード」というのが、日本の現場では
「極めて品質の悪いコード」と同義だったりするから、
「手段の目的化は辞めろ」と言いたくもなる。
引き継ぐとはこういう事 (スコア:3, おもしろおかしい)
/* 2010/02/16 そもそも不要のため削除 開始 by 細野 */
/* 2001/08/10 バグのため削除 開始 by 坂本 */
/* 1996/10/23 仕様変更のため追加 開始 by 高橋 */
/* i++; */
/* 1996/10/23 仕様変更のため追加 終了 by 高橋 */
/* 2001/08/10 バグのため削除 終了 by 坂本 */
/* 2001/08/10 バグ修正のため追加 開始 by 坂本 */
/* i--; */
/* 2001/08/10 バグ修正のため追加 終了 by 坂本 */
/* 2010/02/16 そもそも不要のため削除 終了 by 細野 */
Re:引き継ぐとはこういう事 (スコア:1)
ドウシテオレハ、ココニイルンダ！
Re: (スコア:0)
作り直すのは自分のものにした後 (スコア:2, 参考になる)
プログラムの現状とあるべき姿をよく理解しないと、代替品なんか作れないね。
作り直してもいいけど、それはプログラムを自分のものにしてから。
つまり、自分のものにする代替にはならない。
そもそも論 (スコア:3, 興味深い)
(COBOLプログラムの簡単なメンテだと言われて引き受けたものの、インラインで言語仕様が非公開＆サポート窓口なしのアセンブリ言語が出てきて頭を抱えたことがあるのでID)
Re:そもそも論 (スコア:1)
Oracle Pro*C/C++ や Pro*COBOLのプリコンパイラが吐いたソースは、謎の英数字の羅列が続いてたりして、インラインアセンブラっぽく見えなくもない。
-------- tear straight across --------
Re: (スコア:0)
理解したいなら素直に要求仕様とソースを読めばいい。
どんなに汚いコードでもそこに書いてあるとおりに動くのだから。
むしろ書いた本人以外のほうが、思い込みがない分だけ動作を正確に理解できるはず。
「汚くて理解できない。ゼロから書き直したほうが早い。」
などと言う奴に限ってゼロからはコードが書けない。
そんな奴にメンテを任せると状況はどんどん悪化する。
Re: (スコア:0)
ソースが汚い場合でもソースが読めないのは作成者より読解者の肉体的能力が劣っているのかな？という感じはする。
そういう作成者はソースが汚かったり、作業手順が非効率でも不便なままなんとかしてしまうサバイバル的能力があるというか。
変更履歴 (スコア:2)
を知る為にも履歴管理されていると助かります。
修正時の影響範囲の抜けとかね。
だからと言って、書いたコードを消すな！という作法を押し付けているんじゃないからね。
前世紀の慣習と思いたい。
Re: (スコア:0)
/* 2006.11.10 再度復活 Tanaka */
//#if 0
/* 2005.12.07 I/F変更により下記処理追加 Suzuki */
if ( m_*** == XXXX )
{
xxxxxxxxxxxxxx;
}
/* 2006.11.20 △△△対策 Tanaka */
else if ( m_*** {
xxxxxx;
}
/* 2005.12.15 フェイルセーフ追加 Suzuki */
{
xxxxxx;
}
//#endif
混沌の歴史が分かるのは良いけど、いい加減消させてよ。
消えていった人の名前だらけだよ。
※フィクションです。
Re:変更履歴 (スコア:2, 参考になる)
開始位置だけ分かっても、終了位置が分からないと
管理番号＋STARTと管理番号＋ENDで挟み込んでおく物さ
ま、同じところで何度も修正されると分け分からなくなるけれども
海外本社の某社では変更履歴は仕様書のみで、ソースには残さない
せいぜいが確認に使ったdiffリスト位だった
＃仕様書の変更漏れが複数見つかりパニックになっていたな
Re: (スコア:0)
{
/* 履歴ばっさり消したコード */
}
/* ただのコメントアウトだから規約違反じゃないよね */
// foo(){
// /* 2006.08.01 ○○仕様変更。下記削除 Sato */
// /* 2006.11.10 再度復活 Tanaka */
// //#if 0
// /* 2005.12.07 I/F変更により下記処理追加 Suzuki */
// if ( m_*** == XXXX )
// {
// xxxxxxxxxxxxxx;
// }
// /* 2006.11.20 △△△対策 Tanaka */
// else if ( m_*** {
// xxxxxx;
// }
// /* 2005.12.15 フェイルセーフ追加 Suzuki */
まずは (スコア:1, おもしろおかしい)
// coded by ○○
と自分の名前を入れよう。
こうすることで自分のものになった感が高まり、解読もスラスラ進むように、、
Re:まずは (スコア:1, おもしろおかしい)
作った覚えの無いソースに、
// yyyy年xx月xx日 Anonymous Coward 新規作成
って書かれた俺が通りますよ。 そこコピペすんなｗ
Re:まずは (スコア:1)
まず全てのソースコードの先頭に「未開拓モジュール※」とコメントを入れて、コードの内容を掌握したものからそのコメントを消していく、というメソッドで。
# ※
Lv5以下の社員全員にデスマーチ！
readonly (スコア:1, 参考になる)
という話をするとあんなの使えるかとかなんとかと決まって言われるのですが、
そういった自称(emacs|vi|秀丸|とかいろいろ)マスターの人に限って、
問題の個所を探すのに時間がかかったり探し当てても違っていたりして、
いろいろなトラブルのもとになったりするわけです。
「それはそいつが(emacs|vi|秀丸|とかいろいろ)の使い方を知らないんだよ」
ええ、その人も最初同じことを言ってましたよ。
もちろん本当に早い人もいて、そういう人はサクサクやってくれます。
このあたりは見栄で使ってる若いモンより使い込んでる古参のおっさんの方が確実だったりしますな。
「いや俺これしかわかんないからさ……」
とか言いながらズバババッ！とそれは見事なものです。
Re:readonly (スコア:3, 参考になる)
ひどいときは、2.でやっと本物の main() を発見したり。
あと地味ですが unifdef(1) が便利なこともありますね。
多分に偏見が混じっていますが、IDE使っているヒトの作業を観ると、上に書いたような分析で、
何度も同じ事を繰り返しているように見えてしまいます（それで頭に入れているのかもしれません）。
まぁ、道具は道具でしかないので、、最後は野性のカン。
一旦空にしてから (スコア:1)
確認しつつ元のコードを詰めてますね。
で、ついでに仕様書書いたりコーディングスタイル直したり
実験的に改良してみます。 (スコア:1)
自分なりに、こうしたら良いのでは、という改良をしてみます。
もちろん、元のソースコードは、保存しておいて、自分の実験バージョンを作ります。
改良によって起こった障害などを追いかけている間に元のコードの意味が分かってきます。
ただお経を読むみたいにソースを眺めても、殆ど大事なことは分かりません。
1万行を超えるようなプログラムは引き継いだことありませんが (スコア:1, 参考になる)
その資料をもとに自分の好きなように書き直し、書き直したところが元のコードのどのあたりに相当するのかをコメントしておきます。
# 書き直す場合、1から書き直すのでなく非効率なところを効率的に～とかやってると楽しめます:)
# 非効率なところってのはコーダの癖が出ているものなので、理解を深めるためには悪くありません。
大体1～3割程度進めると元のコードのコーディングスタイルに慣れてきて読めるようになっているため、そこで手を止めます。
元のコードをコピーしたものにたっぷりとコメントを入れておきます。
可能であれば仕様書を起こします。ここまで作ったものは全て自分の環境にだけ置いておきます。
大抵バグや構造上の制約が見つかるため、テキストでいいのでメモしておき
これだけはチームの誰もがアクセスできる共有スペースに置いておきます。
# グローバル変数使いまくりの場合は自分のものにはできないと諦めた方がいいです。
# オブジェクト指向でもインスタンス変数をグローバル変数的に使っているものも諦めたいです。こちらのほうが難易度高いです
grepとかコンパイルとか使って部分分けする (スコア:1)
修正する場所を見つけるには、それに近そうな場所をgrepして見つける。
文字列とか、APIとか検索のヒントになりそうなキーワードはたくさんあるはず。
そんで、検索に引っかかったところらへんにブレークポイントを立てまくる、
IDEがなさげな、コンパイル言語だったら、適当に書き換えてわざとコンパイルエラーださせて依存関係とか特定する。
コンパイラもないLLだったら、die とか スタックトレースとかをバシバシ埋めていって依存を調べる。
そうやって、ここら辺はこんなことをしている、こっちらへんは何をしているとか大まかに把握する。
5万行のソースでも、5つの部分に分けられるんだったら1万行のソースだし、残りの4万行は見なくていい。存在を忘れる。
んで、修正に必要な箇所が入っていそうなところがあったら、そこをピックアップしてその中でまた細分化して大まかに把握する。
これを何度か繰り返すと、全体が少しづつ見えてくると思う。
あとは、我慢の限界を超えたところから少しづつ書き換えていけばいいと思うよ。
by rti.
あえて自分のものにしない (スコア:0)
前任者が自動テストの環境を作っているなら、自動テストが通るくらいの確認はしますが。。。
「すべてを把握した後に修正」なんて無理に決まってるので場当たり的にやるしかない。
仕事であれば、元の開発者に逃げられた管理者が悪いに決まってる。
Re: (スコア:0)
>元の開発者に逃げられた管理者が
ということは、本来なら全てのこーどを元開発者がメンテし続けろと？
Re:あえて自分のものにしない (スコア:2, 興味深い)
未来永劫開発者が管理するんでなきゃ、開発者は自分以外の人間がメンテしやすく作ってるべきだよね。
そうでないコードの場合、そんな人間に開発させた管理者が悪い。レビューでの指摘を怠った管理者が悪い。
あんた何を管理してたんだって話。
あっスケジュールか。
Re: (スコア:0)
同感です。
市販ソフトでも時々開発者に逃げられたから開発終了ってのが有りますが
（別のソフトは売っているから開発部門が消えたわけではない）
そういった方面への考慮が欠けている会社も有るんですかね？
そもそも、デスマーチで一時的に大量に人員を投入して作ったシステムだと
メンテ担当者は他人が作ったばかり弄っている筈なんで、ノウハウが
無いなんて事は無い筈なんですがね。
頑張ったら負け (スコア:0)
＞修正に必要な部分以外読まない。手を入れない。そして、不具合が出ないように祈る。
日本企業での処世術としてはこれが大正解ですね。
責任感なんて持って仕事に取り組むと、潰れるまで全責任を押し付けられるだけだから。
>仕事であれば、元の開発者に逃げられた管理者が悪いに決まってる。
なんだけどね。
彼ら管理者は、仕事は三流でも責任逃れ「だけ」は一流だったりするから。
なるほどね。 (スコア:0)
男にはな… (スコア:0)
Re:男にはな… (スコア:2, おもしろおかしい)
そして、coreをはき出すんですね。
Re:男にはな… (スコア:1)
必要になるまで何もしない (スコア:0)
引き継いだプログラムを自分のものにしている間にも他の業務が発生するので
そんな暇はなく、結局改修案件の度に時間をかけることになるんだ
時間がもらえたならソース読んどけ。ドキュメントには大抵嘘か表面的なことしか書いてない。
Re:必要になるまで何もしない (スコア:1)
=^..^=
Enjoy Computing, Skiing, as much as Horse Racing.
だからドキュメントを書けと (スコア:0)
「お渡ししたコードの動作が仕様です」
「あ、でもそのコードにはバグがあります」
それは問題の本質ではない (スコア:3, 興味深い)
「今回はメンテナンスしやすいようにと思い、ドキュメントは沢山書かせました。」
「ただしドキュメントとソースは一致していません。」
「ドキュメントも毎日の様に変更されたので、どのバージョンに準拠して書かれたコードなのかは誰にも分かりません。」
「ドキュメントに含まれてない仕様も多数存在します。」
「また、その分コードを書く時間が減って、コメントとかデバッグの時間が無くなりました。」
プログラムを書いたことがない素人ほど、ドキュメントで問題解決できると勘違いするんだよね。
「しかし、情報が依然まともに伝わって来ないし行かないので、デバッグはなかなか進まなかった。
隣の部隊に届く仕様書と時間差があって、マイナーバージョンで５ぐらい遅れているのだ。
そのくせテスト時には、俺たちブロックにバグが多い事を責め立てられる。」
http://mssi.blog29.fc2.com/blog-entry-830.html [fc2.com]
基本 (スコア:0)
十分な引き継ぎ期間と工数をもうけて、しっかり引き継ぎをする。
引き継ぎ後も、前の担当者とも常時連絡可能なE-mailアドレスと電話番号を聞いておく。
前の担当者に逃げられたなど言語道断。
さらには引き継ぎ資料もなければコメントもない担当者も全員逃げたようなスパゲッティ
プログラムの場合は、全部棄てて一からやり直すのが一番の近道。
＃日本有数の技術力を誇る大企業(笑)でも、そういうレベルの問題で製品が自然消滅した
＃くらいだから、日本の経営者のアホさ加減は救いようがない。
Re:基本 (スコア:2)
Re:基本 (スコア:1)
オフショアの話かな？それが英語くらいなら「勉強しろ」だと思う。
オフショアに出すような場合は、関係者全員が共通言語（ほとんどは事実上英語になる)くらいを学んで
いなければ仕事は進まない。また、そういう共通言語の有ることがフショア先を決める要件の一つにもなる。
共通言語もない所をオフショア先として決定したのだとしたら………、それはもう経営者レベルの失敗だな。
しかし日本では経営者の失敗は公式に認められることは滅多にない。
ちなみに共通言語があったからと言って、意味不明なコメントが無くなるとは限らない。
それは非英語ネイティブ同士ならもちろん、日本語ネイティブ同士が日本語で書いた時でさえ存在する………。orz
＃コメントの書き方も、属人的スキルの一つなんだよね。
Re:うちの場合はこんなんだけど・・・他所は違う？ (スコア:2, 興味深い)
仕様書なんて飾りです。エライ人(≒経営患部)にだけは、それがわからんのです。
「仕様書があれば開発が上手くいく」なんて、人月と同様に神話や都市伝説なんだけどね。
日本は開発スタイルやコンピューターサイエンスまでガラパゴスなのかな？