アカウント名:
パスワード:
これは、みずほ証券が苦しい。
無理筋を通すため屁理屈をこねるしかない立場は判るが、そのためにソフトウェア工学を誤用してまで持ち出すのは見苦しい。一般には「ソフトウェア工学」が何なのか判らない人が多いので、これで要らぬ誤解が広まらないことを願う。
ソフトウェア工学的には「実装と仕様ドキュメントは整合している『べき』だが、現実にはそうではない」という立場。では、どうするか。仕様から実装への自動生成なり、実装から仕様へのリバースエンジニアリングなり、一貫性をできるだけ(100%は不可能)維持するためのソフトウェアプロセスなり、実装と仕様を一致させ
・コードの重複は良かれ悪しかれ。「コード重複が常に悪」と言い切れるのはかなり狭いドメイン。 例えば、サブルーチン化を抑えることは、変更の影響範囲がシステム全体に渡ることを防ぎ、 リグレッションテストのコストを抑制する効果がある。コスト(予算・工数)は有限というのがヒント。
何年も保守し続けていく必要があるものなら、コードの重複でしのげるのはその場限り。コストを後世にツケ回しているということを自覚すべき。70件以上もある類似関数の山に呆れながら共通の機能追加を行う羽目に遭ったことがあるが、「いくら何でも多すぎだから今本当に必要なのはどれ?」とメンテしていた人に訊いても何年にも渡って継ぎ足し継ぎ足しできたので誰も全体像を把握している人がおらず未回答。「明日・明後日という短期間で必要」というので、徹夜して全部に適用したけどそのうち注意力も散漫になってきたので、ミスを入れ込んだかもしれない。
> 何年も保守し続けていく必要があるものなら、コードの重複でしのげるのはその場限り。コストを後世にツケ回しているということを自覚すべき。
そんな当たり前の話は現場は皆知っている。今さら書くまでも無い。
問題はコストと工数。コストと工数が無限に出るなら、意識の高い技術者なら誰しも自分の作品を理想的コードに向けて仕上げたいと思うだろう。
感覚でものを言っても意味は無く、実際には感覚値を具体値に代えて様々な限られたリソースのトレードオフが選ばれる。例えば、上の「しのげるのはその場限り」についても、十分枯れたCOBOLのレガシーシステムでは「その場」という変数に10年とか代入される。コピペで10年しのげるならば、他に優先順位の高いチケットにリソースを回す方が正しい戦略だ。
一人の技術者が「リファクタリングしたいから」と自己満足のために主張しても、受け入れられるはずは無い。コピペで10年しのげてきたのは歴然とした事実なのだから、コピペの風習を無くしたいなら、その事実を上回るだけの具体的証拠を揃える必要がある。
なお、先に書いた通り、現場は皆コピペの風習を無くせるものなら無くしたいと願っているので、コピペ絶滅の戦略的に正しいストーリーが構築できたなら、大いに受け入れられることだろう。健闘を祈る。
コピペ部分に関して少なくとも今後10年一切改修せずにしのげる、あるいはしのげると予想されるなら誰も否定はせんよ。
実際にはそんな評価抜きにして単に面倒くさいからでコピペが多用されるのが問題なわけで。現状は現状として、この腐った現状を追認するしかできないものは学問の名に値しないわな。実際のソフトウェア工学はテスト自動化とかで退行テストコスト抑制とかの言い訳潰しの方策は出してるっしょ。
> コピペ部分に関して少なくとも今後10年一切改修せずにしのげる、あるいはしのげると予想されるなら誰も否定はせんよ。
その通り。予想されるから(少なくとも予算の決定権を持つ責任のスコープの広い人間には)否定されないわけ。それが実績に基づく現実的な判断であり、事実。
> 実際のソフトウェア工学はテスト自動化とかで退行テストコスト抑制とかの言い訳潰しの方策は出してるっしょ。
残念ながら、その類の研究はJavaがほとんど(JavascriptとC++が少し)。その技術がCOBOLに降りて来て実績を積むのは10年後かもしれないし、来ないかもしれない。しかし、実践者は今後数年以内に入手可能な技術で、目の前にある課題に取り組む必要がある。それが現実。
予算の決定権を持つ人間がコピペ部分に改修が必要になりそうか評価してるって? 面白い冗談言うね。
まぁ、テスト自動化ツール作るのに数年もかかるようじゃコピペに頼りたくもなるのもわかるけど、技術力無い現状を必死に肯定してみても進歩しないよ?
テスト自動化っていっても、CIなんて簡単な話は既に行われているけど、それはクローン潰しの役に立たんよ。
制約充足器を用いたテスト自動生成なら役に立つと有望視され、実際かなり研究投資されているが、それでもtoy problem用の研究レベルから、実践レベルまで降りてくるのにまだ数年かかる。ましてや、COBOLに降りてくるなんていつの話やら。
> 予算の決定権を持つ人間がコピペ部分に改修が必要になりそうか評価してるって? 面白い冗談言うね。
真っ当なら当然判断する。もちろん統計値のレベルで。10年後に1億円の損害が10%で発生すると見積もったリスクに対し、リファクタリングに年間12人月当てるぐらいなら、「そのリスクは取ってリファクタリングは却下」と判断するわけだ。
リファクタリングに工数を当てたいのなら、その判断に対して有効な統計値を携えたストーリーを描けるかが求められる。「従来は年間12人月かかると見積もっていたが、昨年の技術革新により見積もりが年間0.5人月に減ったからやるべき」とかな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
ソフトウェア工学の誤用甚だしい (スコア:1)
これは、みずほ証券が苦しい。
無理筋を通すため屁理屈をこねるしかない立場は判るが、
そのためにソフトウェア工学を誤用してまで持ち出すのは見苦しい。
一般には「ソフトウェア工学」が何なのか判らない人が多いので、これで要らぬ誤解が広まらないことを願う。
ソフトウェア工学的には「実装と仕様ドキュメントは整合している『べき』だが、現実にはそうではない」という立場。
では、どうするか。仕様から実装への自動生成なり、実装から仕様へのリバースエンジニアリングなり、
一貫性をできるだけ(100%は不可能)維持するためのソフトウェアプロセスなり、
実装と仕様を一致させ
コードの重複がコストを抑制する効果は近視的 (スコア:0)
・コードの重複は良かれ悪しかれ。「コード重複が常に悪」と言い切れるのはかなり狭いドメイン。
例えば、サブルーチン化を抑えることは、変更の影響範囲がシステム全体に渡ることを防ぎ、
リグレッションテストのコストを抑制する効果がある。コスト(予算・工数)は有限というのがヒント。
何年も保守し続けていく必要があるものなら、コードの重複でしのげるのはその場限り。コストを後世にツケ回しているということを自覚すべき。
70件以上もある類似関数の山に呆れながら共通の機能追加を行う羽目に遭ったことがあるが、「いくら何でも多すぎだから今本当に必要なのはどれ?」とメンテしていた人に訊いても何年にも渡って継ぎ足し継ぎ足しできたので誰も全体像を把握している人がおらず未回答。
「明日・明後日という短期間で必要」というので、徹夜して全部に適用したけどそのうち注意力も散漫になってきたので、ミスを入れ込んだかもしれない。
Re:コードの重複がコストを抑制する効果は近視的 (スコア:1)
> 何年も保守し続けていく必要があるものなら、コードの重複でしのげるのはその場限り。コストを後世にツケ回しているということを自覚すべき。
そんな当たり前の話は現場は皆知っている。今さら書くまでも無い。
問題はコストと工数。コストと工数が無限に出るなら、
意識の高い技術者なら誰しも自分の作品を理想的コードに向けて仕上げたいと思うだろう。
感覚でものを言っても意味は無く、実際には感覚値を具体値に代えて様々な限られたリソースのトレードオフが選ばれる。
例えば、上の「しのげるのはその場限り」についても、十分枯れたCOBOLのレガシーシステムでは「その場」という変数に10年とか代入される。
コピペで10年しのげるならば、他に優先順位の高いチケットにリソースを回す方が正しい戦略だ。
一人の技術者が「リファクタリングしたいから」と自己満足のために主張しても、受け入れられるはずは無い。
コピペで10年しのげてきたのは歴然とした事実なのだから、
コピペの風習を無くしたいなら、その事実を上回るだけの具体的証拠を揃える必要がある。
なお、先に書いた通り、現場は皆コピペの風習を無くせるものなら無くしたいと願っているので、
コピペ絶滅の戦略的に正しいストーリーが構築できたなら、大いに受け入れられることだろう。
健闘を祈る。
Re: (スコア:0)
コピペ部分に関して少なくとも今後10年一切改修せずにしのげる、あるいはしのげると予想されるなら誰も否定はせんよ。
実際にはそんな評価抜きにして単に面倒くさいからでコピペが多用されるのが問題なわけで。現状は現状として、この腐った現状を追認するしかできないものは学問の名に値しないわな。実際のソフトウェア工学はテスト自動化とかで退行テストコスト抑制とかの言い訳潰しの方策は出してるっしょ。
Re: (スコア:0)
> コピペ部分に関して少なくとも今後10年一切改修せずにしのげる、あるいはしのげると予想されるなら誰も否定はせんよ。
その通り。予想されるから(少なくとも予算の決定権を持つ責任のスコープの広い人間には)否定されないわけ。
それが実績に基づく現実的な判断であり、事実。
> 実際のソフトウェア工学はテスト自動化とかで退行テストコスト抑制とかの言い訳潰しの方策は出してるっしょ。
残念ながら、その類の研究はJavaがほとんど(JavascriptとC++が少し)。
その技術がCOBOLに降りて来て実績を積むのは10年後かもしれないし、来ないかもしれない。
しかし、実践者は今後数年以内に入手可能な技術で、目の前にある課題に取り組む必要がある。それが現実。
Re: (スコア:0)
予算の決定権を持つ人間がコピペ部分に改修が必要になりそうか評価してるって? 面白い冗談言うね。
まぁ、テスト自動化ツール作るのに数年もかかるようじゃコピペに頼りたくもなるのもわかるけど、技術力無い現状を必死に肯定してみても進歩しないよ?
Re: (スコア:0)
テスト自動化っていっても、CIなんて簡単な話は既に行われているけど、それはクローン潰しの役に立たんよ。
制約充足器を用いたテスト自動生成なら役に立つと有望視され、実際かなり研究投資されているが、
それでもtoy problem用の研究レベルから、実践レベルまで降りてくるのにまだ数年かかる。
ましてや、COBOLに降りてくるなんていつの話やら。
Re: (スコア:0)
> 予算の決定権を持つ人間がコピペ部分に改修が必要になりそうか評価してるって? 面白い冗談言うね。
真っ当なら当然判断する。もちろん統計値のレベルで。
10年後に1億円の損害が10%で発生すると見積もったリスクに対し、リファクタリングに年間12人月当てるぐらいなら、
「そのリスクは取ってリファクタリングは却下」と判断するわけだ。
リファクタリングに工数を当てたいのなら、
その判断に対して有効な統計値を携えたストーリーを描けるかが求められる。
「従来は年間12人月かかると見積もっていたが、昨年の技術革新により見積もりが年間0.5人月に減ったからやるべき」とかな。