ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。

イノウーの憂鬱 (25) クラス、例外、ロガー、型定義

»

 「ごめんなさい!」マリは深々と頭を下げた。「ダメダメで情けなくて根性なしで口だけ番長で能なしでチビで貧乳で地味で暗くて向上心も協調性も存在感も個性も華もなくて......」
 「もうそれぐらいでいいから」ぼくは顔の下半分だけで笑った。「ぼくの方こそ、申しわけなかった。ちょっと詰め込みすぎた」
 「ちょっとですか?」マリは上目づかいにぼくを見た。「かなり、いや、相当だったような気がするんすけどね。まあ、それはともかく、しっかり心を入れ替えたので、改めてお願いします」
 「つまり......特訓を?」
 「もちろんです」
 ぼくがすぐに答えないでいると、マリはまたしおらしく顔を伏せた。
 「やっぱり、もうあたしはイノウーさんの信頼を失ってしまったんですね。そうですよね。一度、逃げ出した人間は、また逃げ出すかもしれませんもんね。いえ、イノウーさんは何も悪くないんですから、本当に全くもってとことん気にしなくて大丈夫です。全部あたしが、このどーしよーもないあたしが......」
 「わかったわかった」ぼくは閉口して手を振った。「ぼくももう一度、やり方を考えてみるから」
 そう言いながらも、ぼくは安堵していた。このままマリがドロップアウトしてしまうようなことになったら、と責任を感じていたからだ。どうやらマリのメンタルはチタニウム合金なみに強靱らしい。
 「ところで」マリはホワイトボードを見ながら訊いた。「コードレビューって何やるんですか?」
 ホワイトボードには、今日の日付、8 月25 日と「13:30 ~ 15:30 コードレビュー」と書いてある。
 木名瀬さんがマギ情報システム開発と調整して、この時間が決定したのは先週の金曜日の午後だった。ぼくはすぐに、火曜日からずっと有給休暇を取っているマリにTeams で参加を要請したが、返信はなかった。木名瀬さんに相談すると、私が何とかします、と請け合ってくれたので、ぼくはありがたくお任せすることにした。マリが休んでいる原因が、ぼくとの特訓にあるのであれば、他の人から働きかけてもらった方がいい。
 不安な思いを振り切れないまま週末を過ごしたぼくは、月曜日の朝、いつもより早めにリモートログインした。微かな期待を抱いてTeams でマリの状態を確認したが、オンラインになっていなかった。そのまま仕事をしたが、夜になってもマリとは音信不通のままだった。
 今日の朝、定例ミーティングにマリの姿がなかった時点で、ぼくはもうマリの参加は望めない、と諦めていた。ところが外でランチを済ませてシステム開発室に戻ってくると、驚いたことに、マリが直立不動でぼくのデスクの近くに立っているのを発見することになったのだった。マリはぼくの顔を見るなり、すさまじい勢いで謝罪の言葉を浴びせてきた。
 「フロントだとやらないかな」ぼくは答えた。「ソースを見て、コーディングルールとか、ロジックの組み方とかを批評するんだよ。コードの品質のためにね」
 「でも」マリは空席の課長席を見ながら囁いた。「今日はマギを外すためにやるって聞きましたが」
 ぼくは頷いた。もちろん、真の目的は、伊牟田課長には言っていない。
 「つまり、難癖付けるってことっすよね」
 「まあ、ぶっちゃければそうなるね」
 「よくわからないんですけど、そういうアラ探しって、うまくいくんすか? いえ、つまり、向こうがケチの付けようがないソースを出してきたら」
 「それは心配してないんだけどね」
 ケチの付けようがないソースなどというものはあり得ない。コーディングスタイルというものは、同じベンダーであってもプログラマ毎に異なる。変数名、コメント、行間のスペース、インデントなど、その気になれば何とでもなる。ぼくが心配しているのは別の事だった。
 木名瀬さんが入ってきた。
 「少し早いですが、マギさんが来ました」木名瀬さんが言った。「行きましょう」
 「課長は?」
 「斉木さんと一緒に、先に会議室に行ってます」木名瀬さんはマリを見て、まるで夏風邪で何日か休んでいただけのように声をかけた。「マリちゃん、体調は万全ですか?」
 「おかげさまで」マリは腕を曲げて力こぶを作るジェスチャーを見せた。「この通りです。あ、総務でお茶もらって来ますね」
 マリは勢いよく駆け出して行った。来客に対するお茶出しは、ペットボトル限定ではあるが、先週から解禁になっていた。その後ろ姿を見ながら、ぼくは木名瀬さんに訊いた。
 「どうやって説得したんですか」
 「女子同士にはいろいろルートがありますから。そんなことより」木名瀬さんは訊き返した。「今日、大丈夫ですか?」
 「何がですか」
 「コードレビューです」
 「コードレビューは何度も経験があります。大抵はレビューされる側でしたけど」
 「経験ではなく」木名瀬さんは、ぼくを促して会議室の方に歩き出しながら言った。「うまくソースのクオリティが低い、と主張できますか?」
 ぼくが懸念している点もそれだった。マリとの特訓でわかったことだが、どうもぼくは、誰かに対して強く出ることが性格的に向いていないらしい。明らかに手抜きをしているとか、悪意を持っている相手であれば、その限りではないのだが。これからやろうとしているのは、普通に自分の仕事をしているだけのベンダーに、でっち上げてでも言いがかりをつけることだ。土壇場になって躊躇しない、という自信は正直に言ってない。
 「何とかやってみます」

 ◇ ◇ ◇ ◇ ◇

 定刻通りに会議室に入ったぼくと木名瀬さんを迎えたのは、伊牟田課長とマギ情報システム開発の古橋さんの笑い声だった。どういう文脈だったのかは聞き損ねたが、伊牟田課長が「お金がねえ、おっかねえ」と言い、すかさず古橋さんが愛想笑いで応じたところだった。
 同行の三津橋さんは苛立ちを隠そうともせず、苦い顔で腕を組んでいた。マリがペットボトルのお茶をテーブルの上に置いても、小さく会釈しただけだ。彼の心境は想像がつく。このクソ忙しいときに、プログラミングのことなどわからないユーザ企業の社内SE による形式だけのコードレビューなど、何のメリットもなく、時間のムダでしかない。そんなところだろう。ぼくは元同業者として、三津橋さんに少しだけ同情した。少しだけだ。隣の内田さんは、すみません、と言いながら丁寧に頭を下げていた。
 同席しているのは他に3 名。マネジメント一課の下園さん、通信事業部の此木部長、営業三課の財津さん。この3 名は第三者の立場としてコードレビュー結果を評価する役目だ。コードレビューの規定によれば、担当部署以外からの評価者を最低3 名以上、同席させなければならない。今回は、斉木室長と木名瀬さんが各部の部長に打診した結果、この3 名が送り込まれている。彼らはレビュー基準マニュアルを見ながら、小声で相談し、手順を確認していた。
 お茶出しを終えたマリが着席すると、待ちかねたように伊牟田課長が言った。
 「じゃ、始めましょうかね。本日はお時間をいただいて申しわけないですな。みな忙しいので手短に済ませましょうかね。評価者の方々もお手数をおかけしますな」
 「いやいや」此木部長が顔の前で手を振った。「社内でコードレビューをやるのは久しぶりですからね。前回、いつやったか、憶えてないぐらいで」
 「まあ形式的なものだから気楽にお願いしますよ。じゃ、古橋さん、始めてもらいましょうか」
 「よろしくお願いします」古橋さんがペコペコと頭を下げ、同僚を見た。「三津橋くん、始めて」
 仏頂面の三津橋さんは、カバンから大きな封筒をいくつか取り出すと、中からプリントアウトの束を取り出し、内田さんに配付を命じた。内田さんが使い捨て手袋をはめた手で、ぼくたちにプリントアウトを配る。受け取ったぼくは、その厚みに驚いた。30 ページ以上はありそうだ。
 「えー、お配りしたのがですね、受発注システムの取引先マスタメンテナンス画面のソースです。電子データも持参しましたが、コードレビューということなので、まずは印刷物でご確認いただければと。言語はJava です。以前にお話しした通り、弊社のmagi-servlet-base については社外秘なので、仕様などはお話しすることができません。不明点があれば訊いてください」
 事前に対象のソースファイルを送ってもらえないかと打診したのだが、にべもなく拒否されていた。あらかじめ目を通しておけば、時間の節約になったのに、と思いながら、ぼくはA4 に見開き印刷されているソースに目を通していった。隣に座ったマリも熱心に読んでいる。その他の出席者もプリントアウトを眺めてはいるが、三津橋さん、内田さん以外はプログラマではないので、ロゼッタ・ストーンなしでヒエログリフの解読を強いられたような顔をしていた。
 読み始めて20 分ほど経過した後、ぼくは顔を上げた。
 「質問いいですか」
 「はあ」どうせ形式的に時間を費やすだけだ、と思っていたらしい三津橋さんは、驚いた顔で頷いた。「どうぞ」
 「変数名がtorihiki_saki とかjyusyo とかyubin_no とか、ローマ字表記になっているんですが、全部こんな感じですか?」
 「何か問題でしょうか」
 「問題というか、わかりづらいんですが」
 「そうですか?」三津橋さんは肩をすくめた。「捉え方は人それぞれだと思いますね。うちではこれで統一してますので」
 「統一って......」ぼくが呆れたのは決して難癖ではない。「消費税だけでもsyouhi_zei とshouhizei、それにsyohi_zei とバラバラになっているんですが」
 三津橋さんはノートPC を開いてソースを確認した。
 「ああ、確かになっていますが、それぞれ別のメソッドですから問題はないですね。メソッドというのは......」
 「メソッドは知っています」ぼくは遮った。「こういうのはできれば統一していただきたいんですが。というか、そもそも、ローマ字表記をやめて英語表記にしていただけないでしょうか」
 「そう言われましてもね」マスクの下で三津橋さんがため息をついたのが目に見えるようだ。「うちのメンバーは、これで慣れてしまっているんで。とりあえず要望として承っておきます。おい」
 三津橋さんに促され、内田さんは慌ててノートPC のキーを叩き出した。ぼくは読みづらいソースリーディングを再開した。先ほどまで感じていた三津橋さんに対する同情は、朝日を浴びた夜露のように消えかけている。
 「え?」5 分後、ぼくは思わず驚きの声を発した。
 「今度は何でしょうか」三津橋さんがうんざりしたような声で訊いた。
 「TorihikisakiMei というクラスがあって」ぼくは該当のページを掲げた。「中身はString 型のプロパティが1 つだけです。これは何のためにあるんですか」

25-1.png
 三津橋さんはバカにしたような含み笑いを漏らした。
 「何のって、そりゃ取引先名を格納するために決まってるじゃないですか」
 「いえ、ぼくが訊いているのは、わざわざそのためにクラスを作る理由......」ソースを追いながら話していたぼくは、あることに気付いて絶句した。「......まさか、全部の項目に対して、それぞれクラスを作っているんですか?」
 「そうですが何か問題でも?」
 ぼくは唖然としてプリントアウトを眺めた。取引先名、取引先名カナ、代表電話番号、担当部署、担当者名、登録日時、更新日時など、取引先マスタメンテナンス画面で使用する項目が、全てクラスでラップされている。しかもご丁寧にアクセサメソッド付きだ。数えたことはないが、ダリオスに登場する項目は100 や200 ではきかないはずだ。それら全てに対応するクラスが存在するということなのだろうか。
 「それって、どんないいことがあるんですか?」
 皮肉や嫌みではなく、本心からの疑問だったのだが、三津橋さんの受け取り方は違ったようで、ムッとしたように眉をしかめた。
 「あのですね、うちにはうちのやり方というものがあるんですよ。ずっとこの方法でやってきているので」
 「いえ、非難したわけではないんです。すみませんが、本当にメリットがわからないんです。差し支えなければ教えていただけますか」
 「少し難しい話になりますが、大丈夫ですか?」
 「お願いします」
 「オブジェクト指向という考え方があるんですよ。その重要な要素にカプセル化というものがあります。例えば、取引先名という情報をprivate にすることで、外からは直接操作できないようにします。操作はget、set のメソッドを通してしかできません。これで安全が担保されるわけです」
 そんな初歩的な話が聞きたいわけではない。ぼくは重ねて質問しようとしたが、ふと気付いて横を見た。マリはぼくと三津橋さんの会話をそのまま書き起こしてでもいるような早さで、ペンを裏紙に走らせている。
 「笠掛さん」ぼくはペンの動きが止まるのを待って、呼びかけた。「今の話、理解できた?」
 マリはビクッと顔を上げてぼくを見たが、すぐにブルブルと首を横に振った。
 「どこが理解できなかった?」
 「えーと......」マリは裏紙に目を走らせた。「安全が担保される、というところですかね。どうして安全になるのかが、ちょっとよくわからないです」
 「申しわけないんですが」ぼくは三津橋さんに向き直った。「どうして安全になるのかを教えていただけますか」
 三津橋さんは、やれやれ、と言わんばかりに肩をすくめた。
 「だから難しい話になると言ったじゃないですか。いいですか。例えば、取引先名を取得したい場合は、get メソッドを使います。ここまではいいですか? ちなみに、このメソッドをgetter と呼ぶんですがね」
 「ゲッターロボだ」
 不意に伊牟田課長が口を挟んだが、古橋さん以外は無視した。
 「で、もし、取引先名を出すときに、何らかの加工が必ず必要になったとしますね。そのときでもgetter を修正すれば、元の値をいじらなくてすむんです。また、取引先名を更新するときでもですね、直接書き換えるんではなくて、setter を経由すれば、間違っていた値の場合でも、元の値を汚染しなくてすみますよね。これがカプセル化というものです」
 マリは傾聴していたが、その目元を見れば、理解しきれていないことは明らかだった。
 「理解できた?」ぼくはマリに訊き、付け加えた。「正直に」
 「すいません。全然です」
 ぼくは頷いて、三津橋さんに訊いた。
 「一つ質問なんですが、今まで、そのようにアクセサメソッドを修正するだけで、ビジネスロジックを簡単に修正することができた、というようなケースに遭遇したことはあったんですか?」
 「え?」三津橋さんの口調から、尊大さが消えた。「あ、それは、まあ、いろいろと」
 「たとえば、どんなケースですか?」
 「......すぐには出てきませんが、あるはずです」
 「そうですか。では、後でいいので、その具体例を差し支えない範囲で送っていただけますか」
 三津橋さんは目に見えて動揺したが、全員の視線を浴びていることに気付くと頷いた。
 「わかりました。帰社したら探してみます」
 「本日中でお願いします」ぼくは笑いかけた。「できますよね」
 「......大丈夫です」
 「お待ちしています。それから、次の質問をよろしいでしょうか?」
 「どうぞ」
 「検索や更新のロジックですが」ぼくはプリントアウトをペンで叩いた。「必ずboolean で結果を返しているようです。これはなぜでしょうか?」
 「なぜ......」三津橋さんは慎重な口調で答えた。「何らかの方法で結果を返す必要があるからです」
 「それはもちろんですが、呼び出し側を見ると、false の場合は、そのまま例外を投げていますね。しかもエラーメッセージは、ロジック側でDB に書き込んで、呼び出し側でselect しています。だったらロジック側で例外を投げればいいと思うんですが」
 「......すいません。仰っている意味がよくわからないのですが」
 ぼくは閉じてあったノートPC を開くと、Eclipse で手早くコードを書いた。三津橋さんは驚いた顔でぼくを見ている。
 「こんな感じです」

25-2.png


 ぼくが向けた画面を、三津橋さんは身を乗り出して、食い入るように見つめていたが、やがて思い出したように元の姿勢に戻った。
 「ああ、確かにそういうやり方もあります」三津橋さんは何度も頷いた。「それは人それぞれですから」
 「こっちの方が余計なDB アクセスが不要になるので効率的ではないでしょうか」
 「......そうかもしれません」
 三津橋さんは、ようやくぼくがプログラマであることに気付いたようで、人を小馬鹿にしたような態度は消滅していた。古橋さんは会話の内容は理解できなくても、自社の技術者がやりこめられていることは理解できたようで、狼狽したように、ぼくと三津橋さん、それに伊牟田課長を交互に見ていた。
 「それからですね」ぼくは続けた。「クラスの命名なんですが」
 「はい......」
 「こっちはLogic、こっちではHelper、こちらはGetter、それにこちらはBean とバラバラですが、これは何か意味があるんでしょうか?」
 「......特にはありません」
 「ご存じかと思いますが、オブジェクト指向、というより、現代のコーディングでは、ネーミングは非常に重要な要素となります。統一していただけると、後でソースを読むとき助かるんですが」
 ぼくの指摘に、三津橋さんは肩を落とし、内田さんに記録を指示するのが精一杯の様子だった。古橋さんの懇願するような視線を受けて、伊牟田課長が何か助け船を出したそうだったが、3 名の評価者の手前、何もできない様子だ。ぼくは質問を続けた。
 「次にロギングですが、このmagiLogger というのは、御社で作られたロガーでしょうか?」
 「そうです」
 「Log4J2 やslf4j などのメジャーなロガーを使わないのはなぜでしょうか」
 「以前から使っているので......」
 「Java Logging Framework に準拠しているんですか?」
 「それは......していません」
 「ログレベル指定などの設定はどこにあるんですか?」
 「設定ファイルみたいなものはなくて......ソースにパラメータを書きます」
 「ハードコーディングするということですか。テスト時と本番環境では、当然、ログレベルなどが異なりますよね」
 「本番環境をリリースする直前に記述するので」
 「それを忘れたら? 書き直したら再起動になりますよね」
 「はい......」
 3 名の評価者は、ぼくと三津橋さんの会話のたびに、規定のレビュー用紙を埋めていた。レビューの内容を理解できているわけではないだろうが、三津橋さんが劣勢であることは素人目にも明らかだ。
 「別のロガーに変更できませんか?」
 「変更ですか」三津橋さんは少し考えてから、目を逸らして答えた。「magi-servlet-base 内でも使っていますので......」
 「ダリオスのロジックの中で使っている分は変更できますね」
 三津橋さんは力なく頷いた。
 ぼくはプリントアウトを数枚めくった。Java ソースのプリントアウトの後、「エンティティ定義」とタイトルの付いたドキュメントが続いている。
 「笠掛さん」ぼくは小声で呼びかけた。「データベース部分で、何か気付いたことは?」
 マリは慌ててプリントアウトをパラパラとめくり、エンティティ定義書を抜き出した。取引先マスタの他、いくつかの関連するテーブルの定義だ。
 「少しお待ちください」
 ぼくは出席者たちに断って、定義書に目を走らせるマリを見守った。4 月に互いのスキルを交換していたとき、RDB 関連は最初に教えた項目だ。しかもサンプルとして使ったのはPostgreSQL。記憶していてくれるといいのだが。
 5 分ほど定義書を見て、さらにスマートフォンで何かを調べた後、マリは躊躇いがちに口を開いた。
 「えーと、あの」自信があるとは言えない声だった。「取引先コードがchar(8)、取引先名がvarchar(1000) で定義しますけど、text でないのはなぜなんでしょうか」
 三津橋さんは首を傾げた。
 「取引先コードは8 桁ということなのでchar(8) で定義していますが」
 「間違っていたらすいません。文字型の場合、char 型を使うメリットはほとんどないし、varchar とtext って内部的には変わらないので、わざわざデータ長を制限する必要はないと習ったんですが」
 「そういう考えもありますがね」素人と判断したのか、三津橋さんの口調に傲岸さが少し戻っている。「8 桁のコードですからね。char 型にしておいて問題はないでしょう」
 「んー」マリは首を傾げながら言った。「私は現行のダリオスを使ったことがあるんですけど、取引先コードって、承認されるまでは仮番号なんですよね。確か先頭が"temp-"で8 桁の年月日と、たぶん乱数だと思うんですけど5 桁か6 桁ぐらいの数字になるはずなんです。このテーブルの定義で、それって対応できてます? 8 桁になるのは、上長と部門長の承認が完了した後なんですけど」
 三津橋さんは青ざめ、大慌てでノートPC のキーを叩いた。内田さんにも指示して、何かを検索しているようだ。二人の技術者以上に狼狽している古橋さんは、今にも椅子から立ち上がらんばかりに腰を浮かしている。
 「おいおい、笠掛ちゃんよ」伊牟田課長が助け船を出した。「そういう細かい仕様の問題は後でいいんじゃねーの? 今、コードレビューの場よ?」
 「いやいや、伊牟田さん、これ、結構、重要な問題だと思いますよ」営業三課の財津さんが言った。「要件がちゃんと伝わってないなら、レビュー以前の問題じゃないですか」
 「俺が言ってんのは、仕様の問題なら日を改めてすりあわせすべきじゃねーか、ってことよ」
 「先送りにすべき問題ではありません」木名瀬さんが冷静に指摘した。「むしろ、この段階で発覚したことを幸いと考えるべきです」
 伊牟田課長は沈黙した。その援護を期待していたらしい古橋さんも落胆したようだ。要件についてはエンドユーザにヒアリングを行う、と言っていたが、これほど短期間で満足な要件定義ができるかどうか、最初から疑わしかった。
 10 分ほど検索した後、三津橋さんは断念して顔を上げた。
 「すいません。ヒアリングでその要件は出ていなかったので」
 「ちょっと待ちなさいよ」此木部長が腹立たしそうに言った。「こっちの責任だとでも言いたいわけですか?」
 「責任というか」今や三津橋さんの額には、玉のような汗が浮かんでいた。「やはり言われていないことは......」
 「いえ、そんなことはございません」答えたのは、三津橋さんではなく、古橋さんだった。「こちらのミスでございます。誠に申しわけございませんでした」
 三津橋さんは気まずそうにうつむいた。さすがに少し気の毒になってきたぼくは、目的は達成できたと判断し、苦行から解放してあげることにした。
 「どうも、これ以上、コードレビューを続けても意味がないような気がしますね。とりあえず、これまでで出た問題点などは宿題として持ち帰ってもらって、改善方法を出してもらうということでどうですか」
 マギ情報システム開発の人々は、この場から立ち去れるものなら、自分の母親でも売り飛ばしかねない表情で頷いた。伊牟田課長は異論がありそうだったが、3 名の評価責任者たちは、短く相談した後、ぼくの提案に同意した。
 「それがよさそうですね」此木部長が代表して宣言した。「今日のところは、ここまでにしておきましょうか」
 木名瀬さんは、まだまだ甘いな、とでも言いたげにぼくを見ていたが、此木部長の言葉を聞くと、仕方なさそうに頷いた。
 「宿題の回答期限は木曜日の朝までということでどうでしょう」
 「そりゃちょっと急ぎすぎじゃ......」
 伊牟田課長がすかさず反論したが、木名瀬さんは譲らなかった。
 「新ダリオスの総合テスト開始は来月の14 日です。遅いぐらいだと思いますが。そうではありませんか?」
 最後の疑問符はマギ情報システム開発側に向けられたものだ。古橋さんは三津橋さんの意見も聞かずに、大きく頷いた。
 「はい、もちろん、それで結構です」
 その言葉を最後に、コードレビューは終了となった。伊牟田課長が取り繕うように新型コロナの感染者数の話をしたが、もはや古橋さんが愛想笑いで応じることはなかった。

 (続)

 この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術や製品の優位性などを主張するものではありません。

Comment(46)

コメント

匿名

>変数名、コメント、行間のスペース、インデントなど、その気になれば何とでもなる。
やめてよ・・・

匿名

いつも楽しく拝見させて頂いております。
此木部長と朽木部長は別の人物ですか?急に朽木部長が出現したように読めたので。
勘違い、読解力不足ならばすみません。


ちゃとらん

一応…

ExTestのomethingLogic ですが、isError1 というのは、『エラーか?』という意味なので、falseなら、エラーじゃない、!isError1==true なら、『エラーじゃない事ない』なので正常という事になりませんか?


よく使うのは、 初期値を、isOK=false; にしておいて、ロジックがきちんと通れば、isOK=true;をセットする、どこかで抜けたり正常処理できなかったら、初期値のままなので、
if( !isOK ) { ・・・} としたりします。


説明がややこしかったのですが、要するに、
isError1 = true;
if( isError1 ) {
  throw new RuntimeExceptuin("エラー!!!");
}
だと思います。

匿名

>変数名、コメント、行間のスペース、インデントなど、その気になれば何とでもなる。

コーディング規約渡してればね…。

リーベルG

匿名さん、ちゃとらんさん、ありがとうございます。
それぞれ、ご指摘の通りでした。

これ読んで、思いだした。
インスタンスの数だけクラスが1対1で存在してて、クラス図が孔雀みたいになってるヤツ。

夢乃

サンプルの
boolean isError1 = true;
boolean isError2 = true;
は、
// 何かの処理
の前に置くべきかな、と思いました。(if (isErrer1) が必ず true になっちゃうから)
 
>変数名、コメント、行間のスペース、インデントなど、その気になれば何とでもなる
こんな難癖は嫌だあぁぁぁぁ。

匿名

蝶々みたいなクラス図は見たことある。

ちゃとらん

> 豚さん
> クラス図が孔雀みたいになってるヤツ
あかん。。。笑ってしまった。


> 夢乃さん
> // 何かの処理
> の前に置くべきかな、と思いました。
おっしゃる通りだと思いますが、この例では、isError1 と、isError2 があるので、紙面(行数)を取るのであえて直前に書かれたんだと思います。
この辺り、ソースコードを出すって、行数と判りやすさとのトレードオフがあって難しいと思います。


所で、小説の本筋であるマリちゃんの復活、よかったです。


現実にはなかなかあり得ない展開ですが、そこに話が流れると、それだけで終わってしまうので、さらっと復活で結果オーライという事で。(イノウー君も綱渡りばかりでヒヤヒヤです)


マギ情報システムさん、さんざんですが、これくらいでへこたれる伊牟田課長じゃないでしょうから、まだまだ波乱がありそうで楽しみです。

匿名

マリちゃんは貧乳…

匿名

貧乳のマリちゃんすき

藤井秀明

痛快な話でしたが、マリの将来が不安になりますね・・・。
特訓といい、今回のコードレビューといい、相手に厳しく当たるようなやり方ばかり目にしてるので、それが正しいと思い込んでしまわないか心配になります。
どうしても、人は自分が教わったやり方や成功体験を是として考えてしまいがちですから。

匿名

メシマズは自覚してないのか…だからこそメシマズなんだろうけど。

SQL

いつも楽しく読ませていただいています

今回は、斉木室長と木名瀬さんの各部の部長に打診した結果、
=> 今回は、斉木室長と木名瀬さん *が* 各部の部長に打診した結果、
でしょうか

リーベルG

SQLさん、ありがとうございます。
「が」ですね。

デルフィアン

レビュー内容が柔らかジャブすぎで気持ち悪い(笑)
本格的な攻撃が早く見たいです

へなちょこ

イノウーがおっぱい星人でないことを祈ろう

匿名D

イノウー君は甘ちゃんだな。
厳しいのはマリに対してだけ? それはちがう。
あれも、形を変えた甘えに過ぎない。


そして、自分に対しても甘い。
何をやるにしても、中途半端が一番いけない。
やるなら徹底的に、この場でマギを落とすくらいの勢いでやるべきだった。
できなかったのは、マリには甘えることができたが、
マギには甘えることができなかったからでしょう。


マリは一所懸命なのは好感が持てますが、
マリの立場では、イノウーを全拒否するか全肯定するか、
どちらかしか選択肢がありませんしね。
全拒否してしまうとお話が終わっちゃうし。
当然、特訓「もどき」について改善すべき点は、
マリの中では無く、別のところにあります。


ほかの方も書いていますが、これはイノウー君の成長物語だし。

匿名D

私も、オブジェクト指向を勘違いしたプロジェクトに出くわしたことがあります。
setter/getterのような概念が普及する前、
フレームワークも無く、直接Servletを記述していた頃ですが。


データを変数に格納する段階で、全部、文字列にしちゃってるんです!


日付も数値も全部文字列。
画面表示については規定があって、それに合わせているんです。
だったらtoStrint()をオーバーライドしろよ、
データの保持はプリミティブ多状態で持てって話ですよ。
当然、演算やDBへの書込のたびに、いちいち形式を戻すんです。
やってられませんでしたよ。><

匿名

マリちゃんは貧というよりは普ですかね、イメージ的に。
自虐するセリフの流れと巨ではないというところから貧と言ったのかなぁと妄想してますw

まぁ貧でもステータスですから!

匿名

今後仕様変更や改修が必要になった場合も自社で開発する訳ではない
(マギもしくは他社に再委託する)ので、
命名規則やロガーについてはマーズにとっての失点にはならないと思います。

パフォーマンスについては微妙ですが、重大な失点ではないでしょう。
(マーズにとっては)
速けりゃ速いに越したことはありませんが、
「動くんだから別に良いよ」と許容されるかも。

その意味で、要求仕様未達が見つかったのは、ラッキーだと思います。
(おそらく)マーズからマギに要求仕様を伝えてなかったので、
マギの自責ではないように思いますが。

要求仕様未達以外の対応「必須」項目はないように思うので、
今回のコードレビューの目的に対する成果としては弱かったかも、と思います。

白栁隆司@エンジニアカウンセラー

※非公開コメントでお願いします

リーベルG さんへ

先程、リンクが含まれたコメントを投稿させて頂きました。
スパム判定されている可能性がありますので、確認をお願い致します。

ぽけもん

一応はマーズで保守する、という用件だったはず。
イムタ課長はそう考えてないのかもしれないけど。

>(おそらく)マーズからマギに要求仕様を伝えてなかったので、
>マギの自責ではないように思いますが。

こういうのってたいていはベンダー側(ヒアリングした側)の責任になるんじゃないですかね。
文中でも部長が言ってますが「聞いてない」というのはたぶん通用しない。「なんで聞かないの」と言われて終わり。
そもそも現行ソースを確認してれば、仮番号になることぐらいわかったはずなので、それを怠ったマギのミスですね。

ちゃとらん

> ベンダー側(ヒアリングした側)の責任・・・
> 「聞いてない」というのはたぶん通用しない。
いや~耳が痛いですが、それは結構厳しい注文です。
要件定義に『書かれていなければ』対応の必要はありませんし、現行ソースを提出されてもそれは参考資料であって、そこから仕様を読み解けって『契約』ならいざ知らず、それをベンダーの責任にするのは、きついと思います。
(現実には『書かれていないこと』が後出しじゃんけんで出てきます。)


システムリプレースで『現行システム踏襲ね』という要件定義と画面のハードコピーだけで作れって言われることがありますが(『そんなん、作れるわけねー』)と心の中で叫びます。


確かにスカタンかもしれませんが、マギさんの実力って案外平均レベルなんじゃないかと思ってしまいました。(ベンダーに甘すぎ?)

匿名D

仕様書もマニュアルも完全なものが存在しない、
それを前提に、ヒアリングで使用を把握する、
というのはマギからの申し出だったはず。


今回の仮番については、ソースからでは見つけられないと思います。
ロジック上必要なのは、番号を変更するロジックだけですから。
この場合、正番か仮番かの区別はありません。
ヒアリングで把握しなければならない要件です。
いずれにせよ、マギの立場では「何が足りないのか」は判断できません。


ただ、DBのスキーマは参照したはずなのに、
桁数を下げたのはマギの側、ということになりますけどね。

暁 紫電(akatukisiden)

今の現場自作ロガーなのよね……

匿名

今の現場何でも文字列なのよね……

ぽけもん

>今回の仮番については、ソースからでは見つけられないと思います。

そうですかね。
現行版に仮番号の機能があるなら、当然ソースにも該当ロジックがあるはずですから、ソースを見ていれば発見できたと思うんですが。

自分の経験則でしかありませんが今回みたいなリプレースの場合「現行と同じで」とはよく言われる言葉です。エンドユーザーはベンダーがプロだと思っているので説明しなくてもそんぐらいわかると思っていて、ろくな説明がないことなどざらにあります。ソースを調べて必要な機能を残さずさらうのも料金のうちと考えていますよ。

本文中に描写がないので、たぶんRFPも作ってない。納期も短い。
その状況でソースも読まずにできると思ったマギの見積が甘すぎですな。


匿名

TorihikisakiMeiは型から何者かが自明になるので悪くないのでは、と思いました
すべての場所で同じ変数名を使うのは努力が必要ですが、これなら楽ですし

匿名

イノウーは、良くも悪くもプログラマーだから、_プログラムの悪いところ_を指摘しようとしたんだけれど、この場では不要な視点と思う。
一方、マリは_難しい仕様をこなせているか_を質した(偶然かもしれないけれど)。_間違っている_というのではなく、_正しいですか?_ときいた。

この場では、コードの書き方よりも、仕様を満たしたコードかどうかが、最重要なはず。
悪いところを見つけられなくても、仕様を満たしていることを確認できたなら、良いレビューだし、どれほど整ったコードでも、仕様漏れを見つけられなければク〇だ。
今回、コードがク〇だったから助かったけれど、見た目きれいだったらイノウーは見逃していたのではないか?
ソースが来ないとか言っている間に、仕様確認するべきだったんでは。
その中で、重要な仕様からリストアップしておくべきだったのではないか。
成長物語だから、欠点があるのは良いけど、そこに気付けるだろうか。

匿名D

マリが指摘したことは、イノウー君は先刻から承知の上であって、
マリが指摘できなかったらイノウー君が指摘していたんでしょうよ。


なんの仕込みもなしにマリに話を振って、
何も出てこなかったら、それこそ大ちょんぼですよ。

匿名

そうなんですよね。ソースコードレビューって、
・こういう書き方をしたほうが、保守性が向上する
・こういう書き方をしたほうが、無駄な処理がなく高速化が見込める
というセオリー的な指摘は容易ですが、
そういう目先に囚われたイージーな指摘に陥ってしまい、
・このコードは要求仕様を満たしているのか?
という指摘をするという究極の(本来の)目的を見落としてしまうことが多いですよね。
…自戒の念を込めて。

匿名

要求仕様を満たしているか(動作するか)のみを観点としたレビューしか行われていないせいで、保守性だの可読性だのが一切考慮されていないコードが延々と受け継がれている現場もあるのでなんとも

匿名

仕様を満たしているか仕様書と突き合わせてレビューして、
それ以外の可読性とか保守性とかはコーディング規約と突き合わせてレビューするんじゃないの?

匿名D

なんか潔癖な方が多いんでしょうか?
そもそも、模範的なコードレビューを描写したり論じるのが目的じゃ無い。


これは小説です。
専務まで敵に回した抵抗活動の一環なんですよ。

匿名

> 項目名がクラス

NameクラスのフィールドがFirstNameクラスとLastNameクラス(それぞれStringフィールドを持つ)になってるようなやつの強化版でしょうか。

静的型付け言語では一定のメリットがあるのでしょうけども。

なんなんし

要件レビューとコードレビューを一緒にするのにもにょる

そういう意味では段階的でもよいから
要件レビューを依頼して合意を取り付ける
というプロセスが必要だった
なのでコードレビュー段階で要件漏れあるのは
致命的なベンダーの落ち度かなぁ
コード規約に関しても、契約段階で詰めてないベンダーの落ち度

要件定義に書かれてないからと言って
書いてあるだけのことしかできないから
ってのは先の民法改正で負け戦です(´・ω・`)

だからこそ、ベンダーはコストリスクを事前に提示しないといけないんだけど

契約をなぁなぁでやったしっぺ返しですね

z

マギに瑕疵がないと言う人は、18を見直してくるとよいかと

匿名

それよりz氏よ、聞いてくれ。(旧2ch風に言っただけです)
19を覗いてしまって混乱している。

そこには、ライブラリとしてLoggingが挙げられているんだ。
今話では、ログは独自実装とかいってなかったか?

匿名

上で、19とか書いてるけど、18の間違いでした。あぁぁ。

fksk

まって!マリちゃんは普だけど木名瀬さんが母性あふれる巨なため、相対的に貧と自己評価している可能性もありますよ!?
でもそうするとイノウーがおっぱい星人説が俄然と真実味が出てしまい良くないか・・・

匿名

Loggingがあるからといって、使ってるとは限らない。
commonsのなかには、Loggingが、必要なのもあるから。

匿名

>>今回の仮番については、ソースからでは見つけられないと思います。
>
>そうですかね。
>現行版に仮番号の機能があるなら、当然ソースにも該当ロジックがあるはずですから、ソースを見ていれば発見できたと思うんですが。
>
>自分の経験則でしかありませんが今回みたいなリプレースの場合「現行と同じで」とはよく言われる言葉です。エンドユーザーはベンダーがプロだと思っているので説明しなくてもそんぐらいわかると思っていて、ろくな説明がないことなどざらにあります。ソースを調べて必要な機能を残さずさらうのも料金のうちと考えていますよ。
>
>本文中に描写がないので、たぶんRFPも作ってない。納期も短い。
>その状況でソースも読まずにできると思ったマギの見積が甘すぎですな。

ぽけもんさんに同感。
さすがにこの仕様をソースから読み取れない人は経験不足すぎるでしょ。
元ソースが隠蔽されている部分があってその中でやってて、隠蔽部分はベンダー公開されてないとかなら別だけどね。

なんなんし

みなさん自分だったらとかヒートしてるけど
ストーリー的には
ソース読まずに作れるように
ってのが今回のリプレースに寄せた
ベンダー側の理論なので
技術云々の話では楽しく読めなくなっちゃいますよ(´・ω・`)

匿名

24あたりから、なんか変な自己中コメント多くなってきたな。
24でいろいろ吠えてたやつが、「これは小説です」とか書いてる時点で
爆笑もんなので楽しく読まさせてもらっておりますがw

匿名

> 地味で暗くて向上心も協調性も存在感も個性も華もなく
あまちゃんですね。懐かしい。

コメントを投稿する