高慢と偏見（7） 28日後……
2週間ほど経つと、わたしたちの書くコードは、別の世界のプログラマが作っているのかと思うほど様変わりしていた。
新部品調達システムのデータ構造そのものは、旧システムからそのまま引き継いでいるため、やや冗長なテーブルがいくつもできている。必然的にそれらを処理するロジックも冗長になってしまうのは避けられなかった。最初にコード体系を決めたとき、「データに意味を持たせてはいけない」という今なら常識ともいえる考えを、誰ひとりとして顧みようともしなかったらしい。おかげで、部品コードの先頭n文字で処理を分岐させる、というロジックが無数に発生することになった。
それでも、ある程度のパターンには分類できるから、1つのインターフェイスに対して、パターン数分の具象クラスを定義しておくことで、それほど面倒なコーディングをしなくてすんでいた。
三浦マネージャによって、それが禁止されるまでは。
三浦マネージャ以降は、インターフェイスを定義することは推奨されなくなった（実質的に禁止された）ので、どうしても、if ～ else if ～ のネストを使わざるを得なくなった。わたしも、何度かそのようなパターンをコーディングしたが、まだ幸運な方だった。メンバーの中には、100ぐらいのif ～ else if を書く羽目になった気の毒な人もいる。
わたしたちがこっそり作った「すでにできているクラス」は、いくつかの機能では有用だったものの、全体から見れば焼け石に水だった。こっそり新しい共通ロジックを作成して、「すでにできているクラス」に見せかける作戦は誰もが思いついたが、実行に移す間もなく三浦マネージャに先手を打たれた。三浦マネージャは、毎朝、すべてのソースファイルの一覧を作成して、前日との差分をチェックするようになったのだ。その情熱がどこから沸いてくるのか、はなはだ疑問だ。
「ったく、他にやることないのかね、あの人は」アツコさんは毒づいた。
もっとも、三浦マネージャがプロマネとしてダメダメだったかというと、意外にもそうではなかった。小宮山さんのときは遅れがちだった勤怠管理は1日も遅れずに処理されるようになった。今、誰が何をやっているかが一目で分かるような進捗管理表がグループウェアのトップページにおかれ、日に2回きちんと更新されている。テーブルレイアウトやコード表など、重要なドキュメントは変更が入るたびに更新部分が明示されたプリントアウトとなって全員に配布された。
また、これまでは、小宮山さんがシステム開発の苦労を知らない若手社員であるのをいいことに、現場の担当者は「○○機能もついでに載せてくれ」「××機能があると効率が上がるんだけどね」といったように追加要望をガンガン挙げてきていた。小宮山さんは小宮山さんで、負荷を検討することもなく片っ端からそれらを受け入れていて、スケジュール遅延の大きな要因になっていた。平良さんも同席することが多かったのだが、やはり子会社の社員の身では突っぱねることが難しかったようだ。
三浦マネージャは、そういった追加要望をほとんどシャットアウトしてくれた。自分がマネジメントしている以上、スケジュール遅延を最小限にとどめたかったのであって、わたしたちのことを考えたわけではなかったのだろうが、結果として開発メンバーの負荷が減ったのは確かだ。
オブジェクト指向には無知でも、プロジェクトのマネジメントに関しては、それなりに有能な人だということは確かだった。しかし自分の経験を絶対視して、人の意見にまったく耳を貸そうとはしないので、三浦マネージャに対するわたしたちの評価ポイントは低い位置にとどまっていた。
「中途半端に技術が分かるから、始末が悪いのよね」アツコさんはこぼした。「技術面は平良さんに任せておいて、その他の雑用を全部やってくれればいいのに」
6月が終わりに近づくにつれて、わたしたちのモチベーションは目に見えて低下していった。（三浦マネージャ以外の）誰にとっても読みにくく、効率も悪いコーディングを強制されるのは相当なストレスになる。わたし自身、気がつくと「なんでこんな無駄なことやってるんだろ」とぼんやり考えている自分に気付いて、ぞっとすることが何度もあった。
平良さんも、そんな雰囲気を見かねたのか、ある日、2枚のプリントアウトを手に三浦マネージャの席に向かった。なぜかわたしもついてくるように言われて、平良さんと並んで三浦マネージャの前に立った。
「これを見てください」
平良さんが三浦マネージャの前に置いたのは、なんとわたしがコーディングしたコードの抜粋だった。画面に表示されている一覧から1行を選択したときのロジックだ。
「川嶋さんがコーディングしたものですが、明らかに後の方がコーディング量が増えているのがお分かりかと思います」
「そうだね。それで？」
わたしは緊張しながら、2人のやり取りを見守っていた。
「どちらが読みやすいと思われますか？」
「そりゃあ、こっちだろう」三浦マネージャは当然というように『三浦マネージャ以後』のプリントアウトを指で叩いた。「何をやっているのか一目瞭然じゃないか。それに比べて、こっちは呼んでいるクラスの関数の中身をいちいち追わないと、何やってるか分からないだろう」
「xxxGetterのgetSimpleXxx というメソッド名から、何をやっているかは明らかだとは思いませんか？」
「思わないね。xxxGetter が何をやるものなのかは、中を見ないと分からないじゃない」
「いえ、適切な命名がされていれば、中を見る必要はないんですよ」
「いやいや、違うだろう。これが適切な命名かどうか、どうして分かるんだね？」
――普通分かると思うんだけどなあ。
「普通は分かると思いますよ」わたしの心を読んだように、平良さんが告げた。「本当に分からないのですか？」
三浦マネージャの顔に苛立ちがよぎった。
「百歩譲って適切だとしてもだね、この実装が正しいかどうか名前とJavaDocだけでは分からないだろう」
「もちろんです。しかし、どうして、使う方がそれを気にする必要があるんですか？」
「気にするに決まっているだろう。中身がはっきりしないものを、どうして信用しなきゃならんのかね？」
――平良さん、この人にそんなこと言ってもムダですってば。
「インターフェイスの実装を気にしなければいけないのは、実装する人だけです。使う人は、ただ使えばいいんです」
「だから、中身が分からないものを使う気にはなれないと言ってるんだよ」
「一般の消費者はエンジンの部品1つひとつの仕様を知らなくても車を運転できます」
「……」
「電話をかけるとき、携帯電話の部品の1つひとつの素性を気にしますか？ どのボタンを押せば電話がかけられ、メールが送れるかを知っていれば十分ではないですか？」
冷静な平良さんも、知らず知らずのうちに熱くなってしまったらしい。つい、新人エンジニアに教え諭すような口調になってしまっている。
――あ、ヤバい……気がする。
三浦マネージャは、それを自分への侮辱と取ったらしい。
「私が間違っているといいたいのかね？」
「はい、そのとおりです」と答えられれば、いっそさまざまな問題が解決されたのかもしれないが、さすがに平良さんも言葉をにごした。
「そういうわけではなく、今のプログラミングのスタイルは……」
「あのね、真にユーザーフレンドリーなシステムを作ろうと思ったらね、こんなふうにあちこち分離させてちゃダメなんだよ」三浦マネージャは、『三浦マネージャ以前』のプリントアウトを放り出した。「プレゼンテーション部とデータ部を1カ所でコーディングしてこそ、使い勝手のいいシステムができるんだ。そろそろ分かってくれないかな」
――そろそろ分かってほしいのはこっちなんですけどねえ。
「そういう意味でいうと、このシーサーとかいうフレームワークも本当はいらないんだよ。なんでわざわざプレゼンテーション部分とロジックを分離したりするんだ。効率悪いだろう」
――MVCまで否定するか。
「MVPだか何だかしらないけどね。JSPに何でも書けるんだから、1カ所にまとめてしまえば、誰でもメンテナンスしやすい画面になるものを、わざわざ分けるから複雑になるんだよ」
――JSPにロジック？ そんなの誰がメンテナンスするの？
「それはあまりにも時代に逆行しすぎています」平良さんは呆れたように言った。「メンテナンス性も……」
「あのねえ、わたしは君の会社の親会社の社員だよ」三浦マネージャは遮った。
「はあ？」
「つまり君の会社の社長より偉いってことだ。君たちプログラマの客と言ってもいい。わたしに嫌われたらどうなるか分かってるのかね？」
三浦マネージャは平良さんを、ついでにわたしもぎろりと睨んだ。
「君たち、生きていけなくなるよ」
――ヤクザか、こいつは。
平良さんは絶句している。
三浦マネージャは、わたしに注意を向けた。
「君、川嶋さんか。君も平良さんに同意見かね？」
「あの……」何と言えばいいんだ？
「まあいいけどね。君、結婚してるの？」
「はあ？」
――いきなり何言い出すんだ、このオヤジは。
「結婚だよ」
「いえ、してませんが、何か？」
バツイチのシングルマザーであることを、ここで言う必要はないだろう。
「君もね、経験者の言葉に耳を傾けることをおぼえた方がいいよ。たいていの男は素直な女性を好むんだよ。適齢期のうちに結婚したかったら、カッコつけて短いコード書こうなんて考えないで、読みやすいコードを書くことだね」
この程度で「セクハラ！」と騒ぎ立てるほどウブではないが、さすがに腹が立った。
――あんたの方針に従ったら、いい男が寄ってくるとでも言うのかよ？
よっぽど口に出して言ってやろうと思った。実際、口を開きかけたが、平良さんに機先を制された。
「お時間を取らせてすみませんでした」
平良さんは一礼すると、わたしに目で合図してその場を離れた。わたしも仕方なく踵を返した。
致命的なことを口走る前に、平良さんに助けられたのだ、ということに気付いたのは、自席に戻ってからだった。
（続く）
この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。
コメント
AC/DC
例のstaticおじさんが、
http://wonderfulsky.web.fc2.com/memo.html
こんなこと書いてるよ。
真っ向から反論できるだけの知識も技術力もないもんだから、誰も読まない自分だけのサイトでブツブツ言ってるわけだ。
みながわさんよ、あんたはもう何か書くのはやめた方がいいぜ。
恥をさらすだけだからさ。
って、不快な人の話題でコメント欄を汚してしまってすみませんです。
AC/DC
＞今のところ、このコラムコメントがないけどどうなることやら。
とか書いてるしね。
人のコメントを連続で削除したあげくに、ボロが出ないうちにコメント閉じたやつが言うことばかね。
みながわさんよ、あんたのコラムにどれだけコメントついてる？アクセスランキングに入ったこと何度ある？
年の暮れだってのに、変な人の話題ですまないね。
CMP
これ読んでて、気になることが・・・。
平良さんは「インターフェイスの実装を気にしなければいけないのは、実装する人だけです。使う人は、ただ使えばいいんです」
とはいっているけど、実装する箇所のコードレビューはしていない。
なので三浦マネージャの言う「中身がはっきりしないものを、どうして信用しなきゃならんのかね？」ということに理がある。
まぁ、実際はちゃんとレビューなどを行ってからでないと使用しないけど、ちょっと現実離れしてるんじゃないかなぁ。
まさか、「○○さんが便利そうなインターフェース作って公開してるから、それ使っちゃおうよ」とかで仕事してないよね？
CMPさん、どうも。
> まさか、「○○さんが便利そうなインターフェース作って公開してるから、それ使っちゃおうよ」とかで仕事してないよね？
してないです。
実装の方は、想像するに(笑)、
・コードレビューなりテストなりが済んでいる
・モックになっている
のどっちかでしょうね。
いずれにせよ、インターフェースを使えばいいのであって、その中身を気にする必要はあまりないわけです。
ということにしておきます。
みのがわ
CMPさん、
ライブラリ使うときに、いちいちライブラリの中身をコードレビューしたりしないでしょ? まあライブラリのドキュメントがいまいちアレなときに、ライブラリのソースが入手可能ならそれを追っかけて動作を確認する、みたいなケースはあるけど。
CMP
みのがわさんへ
私が感じたのはね、ライブラリやフレームワークは提供元がチェックした上でリリースしているけど、自分達の誰かが作成したインターフェースで且つレビューなどのチェックをしてないものに対して、どうして信用できるのかってことなのよ。
過去に同様のシステム開発した際に使用した実績のあるインターフェースならまだしも、開発中のものである以上はレビューしないとね。(1)から見てきて、そのような描写がなかったから、三浦マネージャのいうことにも一理あるよねってことが言いたかった。
実際にあったコードレビューの描写は、インターフェースを”使用している”ところだったし。
インターフェースの”中身”のレビュー後に行われた、”使用している箇所”のレビューだった場合の三浦マネージャの発言だったら「勉強しなおせ、ボケ！」だ。
通りすがり
読んでて気になった点は、平良さんの方も、結局宗教論争に持って行っちゃった点でしょうか・・・?
静的解析ツールに通すとかして複雑度とかコードの重複をきちんと数値化して、「これじゃまともに試験も保守も出来ません」って持っていかないで「こっちとこっちを比べてどうですか」というのはあまり意味がありませんよ。
とはいえ、一連の話を読んでいくにつけて、三浦氏はＣのプログラマとしても3流以下だというのは見て取れますけどね。多分Ｃならほとんどの変数をグローバル&1関数1000行とか言うコードを平気で書きそうな勢いですし・・・。
名無しさん
＞通りすがりさん
ツールを通すまでもなく*普通の*技術者なら誰が見てもどちらが可読性が良いか、メンテナンスが容易であるかは一目瞭然と判断したんじゃないですかね？
不幸にも進言する相手の思考が想像の範疇を越えていただけで…
＃そういう意味では平良さんの脇が甘かったのかもですが
というか、件のマネージャの発言内容がどこまで真実かは証明しようがないですが技術者以前の問題な気がします。
電気屋もどき
突然ですが、PLC(Programmable Logic Controller：電力線通信ではない)をご存知ですか?
装置制御に特化した産業用組込機器といった所でしょうか。
これの開発言語の国際規格としてIEC 61131-3というのがあります。
規格改定の中で「オブジェクト指向概念の導入」が議論されており、「導入自体への異論は無い」という報告があります。微妙な文言なのでどの程度導入されるかは分かりませんし、まだまだ先の話でしょう(C++0xが16進数になったように…)
残念な事に会議の中でもインターフェイスへの理解が足りない方々が多い様です。
何が言いたいかというと、主にPC等で利用されている言語「以外」でもオブジェクト指向の流れがあるという事です。この分野はPC関係からすると10-20年程度遅れて各種技術を取り入れていると言われています。
クリティカルな場面でも使われる物ですから、「実績」が無ければ議論すらされません。この様な分野でも評価されつつあるのです。
まぁ、仮に導入されても国内では使われないだろうなぁというのが今の感触。
何かもう「プログラムの文化」が違うみたいで、数値計算でもラダーという「グラフィカル アセンブリ言語」で処理した方が見やすいとか言う人がいる始末ですから。ラダーも論理演算の場合は直感的に理解しやすいので、適材適所だと思うんですけど。
制御に片足突っ込んだへたれ社内プログラマの嘆きでした
電気屋もどき
で、こっちが本題。
社内用に測定機器との通信ソフトを作った訳です。
「機器1」と、一部仕様が違う「機器2」が用意されてました。
他にGUIのデバッグもあるので適当な数値を返すモックもいるなぁと。
そこで、インターフェイスを決めてそれらしく継承関係を作るとこんな感じに
通信インターフェイス
├ モック
└ 機器1用 ─ 機器2用
後はインスタンス生成時にどれかを選択してインターフェイス経由で使う。
対象が何であれ、GUI側プログラム内でオブジェクトの操作方法は同じ。
(ちなみに機器は複数台接続)
ある意味、教科書的な造りですけど現実世界とOOPの対応は取れてます。
どこを抽象化するか認識できれば、面倒な事は無いと思うんですけどねぇ…
久々に覗いてみると面白いコラムになっていますね。
なんだか自分も経験があるのですが。(というか当事者か)
乗り遅れた感じでなんですが、ちょっと気になるのでコメントします。
>CMP
>私が感じたのはね、ライブラリやフレームワークは提供元がチェックした上で
>リリースしているけど、自分達の誰かが作成したインターフェースで
>且つレビューなどのチェックをしてないものに対して、どうして信用できるのか
>ってことなのよ。
この指摘はちょっとおかしいと思う。あとでCMPさん自身がおっしゃっていることですが、
当然自分達が開発した部分の動作保証はレビューやテストなどで、担保する必要がある。
しかしこれは、「提供元」が保証することであり、使う側としては、インターフェイス
仕様に照らし合わせて正しく使用していることさえ、確認すればよいこと。
コードレビューの段であればなおさらそうだと思います。
でないと三浦マネージャのようにすべて自分で書く必要が出てきますよ。
自分のところで機能を実装したら、当然その部分の評価が必要になります。
みんなが不幸になるやりかたでしょう。
(CMPさんは三浦マネージャのやりかたがよいと思っているわけではないですよね？)
「提供元」がメーカか、オープンソースか自分たちかなんてのは関係ないです。
モジュール(クラス、パッケージとかある機能を満たすためのひとまとまりのソフトウェア)の
責務をはっきりさせ、かつ疎結合にすることが大事だと思います。
CMP
TDaさんへ
＞しかしこれは、「提供元」が保証することであり、使う側としては、インターフェイス仕様に照らし合わせて正しく使用していることさえ、確認すればよいこと。
＞コードレビューの段であればなおさらそうだと思います。
うまく伝わってないのかな。
「自分達の誰かが作成したインターフェースで且つレビューなどのチェックをしてないもの」のどこに仕様が存在するんでしょうか？
そんなものを正しく使用しているか作った人以外確認できませんよ。
＞自分のところで機能を実装したら、当然その部分の評価が必要になります。
＞みんなが不幸になるやりかたでしょう。
ん？評価するのは当然でしょ。私の考えが古いだけかもしれないので、後学のためにも評価を行わない理由を教えてください。
今までの流れだと三浦マネージャのやり方を「全否定」はできないよねって言いたかっただけで、肯定は致しません。
flatline
こんにちは。
>「自分達の誰かが作成したインターフェースで且つレビューなどのチェックを
> してないもの」のどこに仕様が存在するんでしょうか？
ここでCMPさんが言っている「インターフェース」というのは、文字通りインターフェースなんでしょうか？それとも、具象クラスのことでしょうか？
CMP
flatlineさんへ
質問に対して質問で返して申し訳ないですが、文字通りと具象クラスでは何か違いがあるんでしょうか？
ちなみに私が想定していたインターフェースは、誰でも使えるようになっているものの中で、自分達で新規に作成したものを考えています。まぁ、要はいきおいでインターフェースって書いただけです（汗）。
間違っていたら訂正致しますのでご指導よろしくお願いします。
flatline
CMPさん、こんにちは。
> 質問に対して質問で返して申し訳ないですが、文字通りと具象クラスでは何か違いがあるんでしょうか？
インターフェースなら、定義や仕様だけ決まっていて、具象クラスはモックということもありえるので、レビューのしようがないですよね。仕様が妥当かどうかというチェックはあるかもしれませんが。
実際、インターフェースだけあって、実装を作っているのは別のチームや別の会社ということなんて、よくあることなので。
具象クラスなら、それ自体のレビューとかユニットテストとかは当然必要だと思いますが、それは作った人なりチームなり会社なりがするだけなので、使う方は気にしないと思います。
と思って、どっちの意図なのかなと聞いてみたわけです。
コラム本文では描写がないだけで、当然、提供されているインターフェースには、JavaDocなり仕様書なりが存在しているのではないでしょうか。誰かが適当に作ったものを、インターフェース名とメソッド名だけで使うとは思えないので。
CMP
flatlineさんへ
回答ありがとうございました。
私自身の経験として、会議を通さずにコモンに追加されたクラスや関数は、必ずバグの基になるってのがありまして、その注意喚起の意味でつらつらとコメントを書いてました。
なので、三浦氏の発言は正鵠を射た発言ではないけど、そんなに間違っている発言でもないよねってことを言いたかったんです。
うまく伝えられてなかったみたいですが・・・。
>私自身の経験として、会議を通さずにコモンに追加されたクラスや関数は、
>必ずバグの基になるってのがありまして、その注意喚起の意味でつらつらと
>コメントを書いてました。
「コモンに追加された･･･」というのはどういう意味でしょう？
Publicな領域にクラスや関数を勝手に追加すると言うような意味でしょうか？
それならばバグの元になるのはありがちです。そういう場合はインターフェイスの
レビューが必要でしょうし、評価も当然必要です。
しかし、通常は外部に公開しないクラス･メソッドであれば外部仕様さえ満たしていれば、
どう実装しようとかまわないでしょう。Cならば名前空間の制御が粗いので、規約で縛る
必要がある場合があり得ますが、Javaならば外部公開仕様以外の部分が、外から覗けるような
実装は拙すぎます。
>なので、三浦氏の発言は正鵠を射た発言ではないけど、そんなに間違っている発言でも
>ないよねってことを言いたかったんです。
モジュール分割のやりかたは、ソフトウェア設計の思想やポリシーなので
正解はない、とは言えます。しかし、間違った方針やまずいやり方だ、と言えるケースが
あり、三浦マネージャの方針はまずいです。
例えば以下のクラスを仮定します。
クラスA メソッド string getName(int id);
戻り値はユーザidの氏名を返す。
クラスBでgetNameを使用する場合、正しいIDを渡して、返してくれる
氏名を正しく扱えばいいわけです。
・不正なidを渡したときにどうなるか
・どのような範囲の氏名が返されるのか(英語のみとか日本語、空文字列があり得るとか)
などは気にしなければなりません。
クラスBはクラスAのgetNameの「中身を知る必要」は一切ありません。
DBから取得するかもしれないし、設定ファイルを読むのかもしれません。
そんなことはBには関係ないわけです。逆にDBから取得していたモノが、
設定ファイルから読み込むようになってもBを修正する必要はありません。
クラスA メソッド string getName(int id);のレビューや評価自体は
当然必要です。しかしそれはクラスAの責務であり、実装が正しいかどうかは
クラスAのレビューで行うべきモノです。
CMP
TDaさんへ
＞クラスA メソッド string getName(int id);のレビューや評価自体は
＞当然必要です。しかしそれはクラスAの責務であり、実装が正しいかどうかは
＞クラスAのレビューで行うべきモノです。
そのクラスＡも使用しているクラスＢも三浦氏のグループが作成しているものであり、クラスＡのレビューはやってないと私は受け取っているのです。
まぁその描写がないだけと言ってしまえばそれまでなのですが。
クラスAを誰が開発したのか、そのレビューが終わっているのかどうかは
クラスBのレビューには関係ありません。
ですから描写があるのかどうかも無関係です。
クラスBのレビュー時に、クラスAのレビューが終わっている必要がある、
と思ってますか？
プログラムはすべてボトムアップで作り上げなければならない、
と言っているのと同じですよ。
CMP
TDaさんへ
共通で使用されるクラスに関しては、レビューが終わってないといけないと思ってます。
それがなぜボトムアップで作り上げなければならないことになるのかが不思議でしょうがないのですが。
flatline
CMPさん
＞共通で使用されるクラスに関しては、レビューが終わってないといけないと思ってます。
またまた質問ですが、「レビューが終わっている」という状態は、どの程度を指すのでしょうか？
1. インターフェースの責務と、名称、メソッド名、引数などの妥当性のレビューが終わっている。
2. 具象クラスの実装が終わり、ユニットテスト、コードレビューも終わっている。
CMP
flatlineさんへ
私の考えでは、１＋αです。
で、プラスαの部分は、実装しているメソッドが存在する場合はその部分のユニットテストとコードレビューです。
私の言葉足らず＆解読力不足なのかも知れませんが、泥沼化しそうだな、これ。
ここは某氏の必殺技「学歴披露（上から目線）」をしてお茶を濁したいところだけど肝心の学歴が（汗）。
flatline
CMPさん
> で、プラスαの部分は、実装しているメソッドが存在する場合はその部分のユニットテストとコードレビューです。
細かくて申し訳ありませんが、「存在する場合は」ということは、もし実装がまだ存在していなければ、そのインターフェースは使用してはいけない、という意味でしょうか？
CMP
flatlineさんへ
ちょっと整理したいのですが、
私の考えは、「プロジェクト内で共通で使用するコモンクラスは常に最優先でレビューを受けるべきである」であり、「最優先でレビューするものは、当然の如く最優先で製造されるものである」です。
なのでTDaさんの例にあるクラスＡがコモンクラスであれば、「当然レビューは終わっているはず」になります。
で、flatlineさんの質問である「実装がまだ存在していなければ、そのインターフェースは使用してはいけない」ですが、回答は「抽象クラス内にある普通のメソッドのレビューが済んでいないのであれば、そのメソッドを使用しているクラスのレビューはしてはならない」です。
flatline
こんにちは。
> > 「抽象クラス内にある普通のメソッドのレビューが済んでいないのであれば、そのメ
ソッドを使用しているクラスのレビューはしてはならない」
その考えだとメリットよりデメリットの方が大きいのではないかなと思います。
これだと、先のTDaさんの例のクラスＡとクラスＢ、またはクラスＡを使っているその他のクラスとが、あまりにも密結合になってしまうので、後々メンテナンスしづらくなる気がします。
モジュール間の関係は、できるだけ疎結合にしておかないと、実装しているときも、後からメンテナンスするときも、あれこれ意識しなければいけないことが多すぎて大変です。
レビューが済んでいようといまいと、具象クラスがあろうがなかろうが、気にせず使用できるぐらい独立性が高い方が好ましいと思います。
あくまでも個人的な意見ですが。
よみこ
ここまで楽しんで読んでいます
三浦マネのやり方やソースは、汎用のCOBOLを組んできた私のVBソースに近いなあと思いました
といっても、私がCOBOLをやっていたのは15年も前だけど、その頃もオブジェクト指向みたいなこと言われてた気がします
その時は単純に小っちゃい部品作って組み合わせると工数減るからいいよねって感じで捉えてて、ステップ数の多いプログラム＝すごいプログラムではありませんでしたが。
その環境によって経験を積んで研鑽したものは無駄ではないと思います
そういう仕事の仕方が正しい環境もあると思うけど、これは違うって普通気が付くのに；；；
自分のやり方を通したい三浦マネはもしかして不安でしょうがないのかも。ゴリガンだからこんなやり方になっちゃうんですね
まだまだ、楽しみます＾＾
ある
>部品コードの先頭n文字で処理を分岐させる、というロジックが無数に発生することになった
>メンバーの中には、100ぐらいのif ～ else if を書く羽目になった気の毒な人もいる。
管理目的で会社コードとかの頭文字を決めることはありますね。
2始まりなら製造系、3始まりなら販売系など。しかし、これは…一度お目にかかりたい。
ソースのやりとりですが、やはり両者いまいちですよね。
>「いえ、適切な命名がされていれば、中を見る必要はないんですよ」
適切な命名という部分を具体的に説明する必要があると思います。
>「一般の消費者はエンジンの部品1つひとつの仕様を知らなくても車を運転できます」
ちょっと飛躍しすぎましたよね。
使う人は当然使うものを確認してから使うでしょう。クラスでも。
ユーザーを持ち出すとちょっと意味合いが変わります。
って改めてここまで読んで思いました。
そもそも、プロマネがコーディングの細部までっておかしいですよね。
方針等を決めるのはまだしも。。。
野球の監督が1球1球の配球まで決めているのですから。。。
そして、森にやさしくないな三浦さん。