アカウント名:
パスワード:
>チームで仕事するなら、ルールぐらい守れよ
年齢から見て、おそらくこの人はルールを 捏造する 作る側の人じゃないの?老害が時代錯誤なヘボルールを作って、それに従うよう強要される憐れな若手の姿が目に浮かぶ。
まだペーペーの頃、ファイル変換処理のローダー部分を作らされたんだが、仕様に「ファイルを『固定長配列』に読み込む」って書いてあるのを、気を利かせたつもりでvectorへ読み込むように作ったら、上司に仕様と違うじゃないかと怒られたのを思い出した。(なお仕様との違い以外に問題は無く、結合しての動作確認まで済んでいた。)
ファイルサイズが配列長超えたらどうするのか等々、修正を渋っていたら、結局上司自らスパゲティ山盛りのクソでかい関数をこさえた。
まぁテストの段階でバグが殆ど出なかったのは妙に感心したが、1週間もかけてあんなの作る位だったら、素直に仕様変更したらどうなのかと思った。客に説明できないとか仰せであったが、ファイルサイズの制限について説き伏せるよりは、遥かに簡単だったろうに…
#勿論、きちんと手順踏んで作業しなかったのも悪いんですが。
相手先が固定長の(ファイル|フィールド)の場合、変に頑張って処理を続けるより、あっさり死んでくれた方が助かるケースもかなりありますよね?(そもそも想定外のファイルが送られてくる時点で、そのデータは信用できない場合とか)
PGレベルでの実装のきれいさと、仕様としてのきれいさが(矛盾とまではいかないまでも)反することなど日常茶飯事で、むしろそこの穴を埋めるのがPGとしての腕だと思いますが。プログラムでのコミュ力というか…
いちPGとしての矜持に反するというその憤りも分かりますが、だからといって上司を無視するようなその態度(およびそのことを武勇伝的に思っている)もいち社会人としてはどうかと思いますね…
#1759565ですが、ちょっと言い訳させて貰いたい。仕様通りに作らなかった事を正当化するつもりはありませんが、ここで指摘したいのは、その後の対応のまずさです。この場合、まず客に仕様の不備を説明した上で仕様を変更して良いか確認し、客の承諾を得られたら仕様を修正し、承諾を得られなかったらコードを修正というのが最善策ではないでしょうか。
実際、後で客に仕様の不備を説明してるんですから、欠陥仕様を押し通すより客の意向を確認しそれに従うべきです。
#1759687さんへ:(情報が後出しになりますが)そもそも客の意向を確認してもらえば、vectorから固定長配列へ変更する用意はできていたんです。仕様を修正する・しないで揉めた後、1週間放置プレーを食らい、気が付いたら上司謹製コードが出来上がっていました。
元コメントのACさんが正しいと思うんですけど。。。反論するコメントばかり付いてますが、自分にまわってきた仕様を実際に組む検討をするときに「いやこれじゃだめじゃん」って気づくことは多々あると思うのですが皆さんはそれを上司やSEに「これじゃだめです」って訴えないのですか?間違ってると思ってても、そのまま書くのですか?こっそり「後で変更可能な仕組み」を入れたりもしないのですか?それでは、「プログラマー」ではなくて唯の「コーダー」ですよね?それが「時間や金に縛られる『会社』というものだ」と言われれば私には反論できませんが、なんか悲しいです。元ACさんがおっしゃるようにvectorから固定長配列に変換するのなんて数行なんですから上司さんがvectorの便利さを知らなかったとしか思えないです
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
ひとりで趣味でやるなら (スコア:0)
他人が口を出す問題ではない。
チームで仕事するなら、ルールぐらい守れよ
Re: (スコア:2)
>チームで仕事するなら、ルールぐらい守れよ
年齢から見て、おそらくこの人はルールを
捏造する作る側の人じゃないの?老害が時代錯誤なヘボルールを作って、それに従うよう強要される憐れな若手の姿が目に浮かぶ。
Re: (スコア:1, 興味深い)
まだペーペーの頃、ファイル変換処理のローダー部分を作らされたんだが、
仕様に「ファイルを『固定長配列』に読み込む」って書いてあるのを、
気を利かせたつもりでvectorへ読み込むように作ったら、
上司に仕様と違うじゃないかと怒られたのを思い出した。
(なお仕様との違い以外に問題は無く、結合しての動作確認まで済んでいた。)
ファイルサイズが配列長超えたらどうするのか等々、修正を渋っていたら、
結局上司自らスパゲティ山盛りのクソでかい関数をこさえた。
まぁテストの段階でバグが殆ど出なかったのは妙に感心したが、
1週間もかけてあんなの作る位だったら、素直に仕様変更したら
どうなのかと思った。
客に説明できないとか仰せであったが、ファイルサイズの制限について
説き伏せるよりは、遥かに簡単だったろうに…
#勿論、きちんと手順踏んで作業しなかったのも悪いんですが。
Re:ひとりで趣味でやるなら (スコア:2, すばらしい洞察)
相手先が固定長の(ファイル|フィールド)の場合、変に頑張って処理を続けるより、
あっさり死んでくれた方が助かるケースもかなりありますよね?
(そもそも想定外のファイルが送られてくる時点で、そのデータは信用できない場合とか)
PGレベルでの実装のきれいさと、仕様としてのきれいさが(矛盾とまではいかないまでも)
反することなど日常茶飯事で、むしろそこの穴を埋めるのがPGとしての腕だと思いますが。
プログラムでのコミュ力というか…
いちPGとしての矜持に反するというその憤りも分かりますが、だからといって
上司を無視するようなその態度(およびそのことを武勇伝的に思っている)も
いち社会人としてはどうかと思いますね…
Re: (スコア:0, 興味深い)
#1759565ですが、ちょっと言い訳させて貰いたい。
仕様通りに作らなかった事を正当化するつもりはありませんが、
ここで指摘したいのは、その後の対応のまずさです。
この場合、まず客に仕様の不備を説明した上で仕様を変更して良いか確認し、
客の承諾を得られたら仕様を修正し、承諾を得られなかったらコードを修正
というのが最善策ではないでしょうか。
実際、後で客に仕様の不備を説明してるんですから、欠陥仕様を押し通すより
客の意向を確認しそれに従うべきです。
#1759687さんへ:
(情報が後出しになりますが)そもそも客の意向を確認してもらえば、
vectorから固定長配列へ変更する用意はできていたんです。
仕様を修正する・しないで揉めた後、1週間放置プレーを食らい、
気が付いたら上司謹製コードが出来上がっていました。
Re:ひとりで趣味でやるなら (スコア:2, 興味深い)
元コメントのACさんが正しいと思うんですけど。。。
反論するコメントばかり付いてますが、
自分にまわってきた仕様を実際に組む検討をするときに
「いやこれじゃだめじゃん」って気づくことは多々あると思うのですが
皆さんはそれを上司やSEに「これじゃだめです」って訴えないのですか?
間違ってると思ってても、そのまま書くのですか?
こっそり「後で変更可能な仕組み」を入れたりもしないのですか?
それでは、「プログラマー」ではなくて唯の「コーダー」ですよね?
それが「時間や金に縛られる『会社』というものだ」と言われれば
私には反論できませんが、なんか悲しいです。
元ACさんがおっしゃるように
vectorから固定長配列に変換するのなんて数行なんですから
上司さんがvectorの便利さを知らなかったとしか思えないです
Re: (スコア:0)
>皆さんはそれを上司やSEに「これじゃだめです」って訴えないのですか?
訴えすらせずに勝手に仕様と異なる実装をしたのが問題だ、という反論コメントでしょう。
本人さんが後付と断って情報追加してますが、少なくとも
元コメントだけでは反論されて仕方ないように見えます。