アカウント名:
パスワード:
なんかめんどくさいな。バージョン管理システムを導入していなかったり古いjdk使ってるだけでその会社の技術レベルが低いとかなに言ってますのんって感じ。マシンスペックに異様にこだわる無能プログラマに見えてしょうがない。
動いているものが正であり、何かを変えるとその分の費用、時間、労力がかかるって事を良くわかっていない気はちょっとしますね。クライアントの了承を取ったり、すべてテストし直しになったりするのだって嫌ですし。
＞クライアントの了承を取ったり、これは馬鹿なクライアントが自分のクビを絞めているだけだから放置するとして、
＞動いているものが正であり、何かを変えるとその分の費用、時間、労力がかかるって事をだからといって事態が悪化するのを手をこまねいてみているのは、愚かなマネージャーだけがすることですよ。そんな風にレガシー化するに任せて、みずほ銀行みたいなトラブルを起こしたいですか？
あなたが何も変えなくても、周りでは技術は進歩するし開発効率もあがるのです。あなたの生産性が昔と同じということは、ライバル企業に開発効率や品質で差を付けられるということですよ。さらにあまりに古すぎる場合は、製品販売も中止されるしサポートも打ち切られるし、解説書も手に入らなくなるしその技術を使う人間もいなくなります。
「それでもあなたはCOBOLを使い続けますか？」な感じですね。そんなにCOBOLと心中したければあなた一人で死んで下さい。私だったらあなたのような人に足を引っ張られて、巻き添えを食うのは御免被ります。
> そんな風にレガシー化するに任せて、みずほ銀行みたいなトラブルを起こしたいですか？
ぶっちゃけ、みずほ銀行のトラブルの原因はJavaを持ち込んだせいなんですわ。素直に既存システムへ統合すれば良いのを、Java＆COBOLなんて訳の分からないステップ踏んだのが原因。はっきり言って動くシステムには手を加えるなってのを証明した良い例なんだよねw
この案件に参加要請をされたが、仕様を見てお引き取り願った。だってデスマ確定フラグが立っていたから。。何人か友人が参加したが、皆さん死相が出ていらっしゃいましたw一から作ればまた違った結果が出たとは思うけどね。
＞ 「
開発者＆仕様を書く奴の絶対能力に依存する体制に問題があるとは思わない？それって精神論をふりかざしてるだけに見えるなあ。それと、何もしなかった立場で、俺ならこうすると吠えてるだけに見えるなあ。
動くシステムには手を加えるなと言っても、なんだかんだで手を加える必要が出てくるわけで。でないと私らおまんまの食い上げですがな。
どうせ手を加えなきゃならないなら、できるだけ安全にしたいよね。
いや本当に痛い開発者はすぐに開発現場から退場してもらいたいですわ。
すいませんが、みずほ銀行のどのトラブルがどれくらいレガシーな体制の責任だったか解説してはもらえんでしょうか。そして例えばストーリーにある「継続的インテグレーション、単体テスト、オートメーション化された回帰テスト、業界標準の（オープンソースではない）バージョンコントロール」を採用すると、どれくらいソレが解消されるであろうか教えてもらえないでしょうか。
そう、大声で自分の無能を叫ばなくてもわかりますよ。ストーリー内の文言はちょっと曖昧なので、要点は以下。
オートメーション化されたテストバージョンコントロール以上によって実現される継続的インテグレーション
結果から言うと、以上のものがない状態から比べれば、開発に関するコストが思いっきり違います。桁が違うと言いたいけど、1/5ぐらいにはなるかな。理由は、バージョンコントロールを手作業でやると累積的に作業（工数）が膨れ上がる事テストが自動化されていればテストを実行するコストが非常に小さく、またテストを実行する回数が桁違いとなり、問題の発覚、対策のスピードが加速度的にアップする事。で、開発に関するコストが大幅に小さくなると、スケジュール、要員的に余裕ができ、品質向上などにまわす事ができ、よりよいサイクルで開発が回ると。
ああ、そんな現場見たことないというのはそうでしょうね。こういうサイクルで物をつくれる人たちは旧世代の人売り業界とは縁が切れるので、従来の現場から姿が消えたように見えると思います。
>こういうサイクルで物をつくれる人たちは旧世代の人売り業界とは縁が切れるので、
人売りの最底辺ではこのあたりの自動化は楽とかなんとかじゃなくて健康に関わりますね。今の最底辺は、異常に納期短いんで。
元コメは恵まれた労働環境にいると思われ。
これらを採用することに価値はないと主張したいわけじゃありません。もちろん使った経験がないわけじゃないです。むしろ積極的に私が主導するプロジェクトに採用をしている状況ですね。
しかし、元コメが具体例として出したみずほの件、どう関わっているのでしょうか。どうもピンとこないのですが、そこに答えることは可能でしょうか？
開発に関するコストが思いっきり違います
…コーディングだけが開発の全てじゃありませんが…。
腹痛の患者に風邪薬を渡す医者のような技術者でありたくないですよね？そうであれば、素っ頓狂で攻撃的なコメントを書くべきじゃないのでは。
>みずほ銀行みたいなトラブルえーっと、具体的に答えるには過去のトラブルのうちのどれなのかよくわからないです。ｗｗ
コメントした時はなんとなく、旧世代の開発プロセスで起こったドタバタをイメージしてた程度です。
それと、コーディングのコストが小さくなると他のプロセスも影響が大きいです。製造工程以後の方向修正のコストが小さいならば、設計段階で無謬性の保証にかけていたコストが減るし（コストを０にしろというわけではない）
いや、でかいプロジェクトじゃない、かつレガシーなものだと思えますよね。それに費用や労力を積み上げるのは状況によりけりです。
変えるとしても新規に近いプロジェクトからです。そこでもろもろの学習してから水平展開させていけばいいんです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
こういう開発者って (スコア:1)
なんかめんどくさいな。
バージョン管理システムを導入していなかったり古いjdk使ってるだけで
その会社の技術レベルが低いとかなに言ってますのんって感じ。
マシンスペックに異様にこだわる無能プログラマに見えてしょうがない。
Re: (スコア:0)
動いているものが正であり、何かを変えるとその分の費用、時間、労力がかかるって事を良くわかっていない気はちょっとしますね。
クライアントの了承を取ったり、すべてテストし直しになったりするのだって嫌ですし。
Re:こういう開発者って (スコア:2)
＞クライアントの了承を取ったり、
これは馬鹿なクライアントが自分のクビを絞めているだけだから放置するとして、
＞動いているものが正であり、何かを変えるとその分の費用、時間、労力がかかるって事を
だからといって事態が悪化するのを手をこまねいてみているのは、愚かなマネージャーだけが
することですよ。そんな風にレガシー化するに任せて、みずほ銀行みたいなトラブルを起こしたいですか？
あなたが何も変えなくても、周りでは技術は進歩するし開発効率もあがるのです。
あなたの生産性が昔と同じということは、ライバル企業に開発効率や品質で差を付け
られるということですよ。さらにあまりに古すぎる場合は、製品販売も中止されるしサポートも
打ち切られるし、解説書も手に入らなくなるしその技術を使う人間もいなくなります。
「それでもあなたはCOBOLを使い続けますか？」な感じですね。そんなにCOBOLと心中
したければあなた一人で死んで下さい。私だったらあなたのような人に足を引っ張られて、
巻き添えを食うのは御免被ります。
Re: (スコア:0)
> そんな風にレガシー化するに任せて、みずほ銀行みたいなトラブルを起こしたいですか？
ぶっちゃけ、みずほ銀行のトラブルの原因はJavaを持ち込んだせいなんですわ。
素直に既存システムへ統合すれば良いのを、Java＆COBOLなんて訳の分からないステップ踏んだのが原因。
はっきり言って動くシステムには手を加えるなってのを証明した良い例なんだよねw
この案件に参加要請をされたが、仕様を見てお引き取り願った。
だってデスマ確定フラグが立っていたから。。
何人か友人が参加したが、皆さん死相が出ていらっしゃいましたw
一から作ればまた違った結果が出たとは思うけどね。
＞ 「
Re: (スコア:0)
開発者＆仕様を書く奴の絶対能力に依存する体制に問題があるとは思わない？
それって精神論をふりかざしてるだけに見えるなあ。
それと、何もしなかった立場で、俺ならこうすると吠えてるだけに見えるなあ。
動くシステムには手を加えるなと言っても、なんだかんだで手を加える必要が出てくるわけで。
でないと私らおまんまの食い上げですがな。
どうせ手を加えなきゃならないなら、できるだけ安全にしたいよね。
いや本当に痛い開発者はすぐに開発現場から退場してもらいたいですわ。
Re: (スコア:0)
すいませんが、みずほ銀行のどのトラブルがどれくらいレガシーな体制の責任だったか解説してはもらえんでしょうか。
そして例えばストーリーにある「継続的インテグレーション、単体テスト、オートメーション化された回帰テスト、業界標準の（オープンソースではない）バージョンコントロール」を採用すると、どれくらいソレが解消されるであろうか教えてもらえないでしょうか。
Re:こういう開発者って (スコア:1)
そう、大声で自分の無能を叫ばなくてもわかりますよ。
ストーリー内の文言はちょっと曖昧なので、要点は以下。
オートメーション化されたテスト
バージョンコントロール
以上によって実現される継続的インテグレーション
結果から言うと、以上のものがない状態から比べれば、開発に関するコストが思いっきり違います。
桁が違うと言いたいけど、1/5ぐらいにはなるかな。
理由は、バージョンコントロールを手作業でやると累積的に作業（工数）が膨れ上がる事
テストが自動化されていればテストを実行するコストが非常に小さく、またテストを実行する回数が桁違いとなり、
問題の発覚、対策のスピードが加速度的にアップする事。
で、開発に関するコストが大幅に小さくなると、スケジュール、要員的に余裕ができ、品質向上などにまわす事ができ、
よりよいサイクルで開発が回ると。
ああ、そんな現場見たことないというのはそうでしょうね。
こういうサイクルで物をつくれる人たちは旧世代の人売り業界とは縁が切れるので、
従来の現場から姿が消えたように見えると思います。
Re: (スコア:0)
>こういうサイクルで物をつくれる人たちは旧世代の人売り業界とは縁が切れるので、
人売りの最底辺ではこのあたりの自動化は楽とかなんとかじゃなくて健康に関わりますね。
今の最底辺は、異常に納期短いんで。
元コメは恵まれた労働環境にいると思われ。
Re: (スコア:0)
これらを採用することに価値はないと主張したいわけじゃありません。
もちろん使った経験がないわけじゃないです。
むしろ積極的に私が主導するプロジェクトに採用をしている状況ですね。
しかし、元コメが具体例として出したみずほの件、どう関わっているのでしょうか。
どうもピンとこないのですが、そこに答えることは可能でしょうか？
…コーディングだけが開発の全てじゃありませんが…。
腹痛の患者に風邪薬を渡す医者のような技術者でありたくないですよね？
そうであれば、素っ頓狂で攻撃的なコメントを書くべきじゃないのでは。
Re: (スコア:0)
>みずほ銀行みたいなトラブル
えーっと、具体的に答えるには過去のトラブルのうちのどれなのかよくわからないです。ｗｗ
コメントした時はなんとなく、旧世代の開発プロセスで起こったドタバタをイメージしてた程度です。
それと、コーディングのコストが小さくなると他のプロセスも影響が大きいです。
製造工程以後の方向修正のコストが小さいならば、
設計段階で無謬性の保証にかけていたコストが減るし（コストを０にしろというわけではない）
Re: (スコア:0)
いや、でかいプロジェクトじゃない、かつレガシーなものだと思えますよね。
それに費用や労力を積み上げるのは状況によりけりです。
変えるとしても新規に近いプロジェクトからです。そこでもろもろの学習してから水平展開させていけばいいんです。