アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
学生(計算機科学専攻)の意見ですが (スコア:1, 興味深い)
「既にこの問題を解くアルゴリズムが出来てるんだから、新しいのは作るな」
と言われていると思えて仕方ありません。 ほんの少しデータ構造などを変更するだけで実行速度が劇的に速くなったり
Re:学生(計算機科学専攻)の意見ですが (スコア:1, 興味深い)
現場の細かい事情とか知らない人の方が本質を突いたことを言う
なんてのはよくあるよ。
Re:学生(計算機科学専攻)の意見ですが (スコア:1)
minix/hurd vs linux
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
>なんてのはよくあるよ。
別ACだが、それは偶々鉄砲の玉が的に当たったと言うだけ。
当てずっぽうが当たったから、当てずっぽうで発言するのを考慮しろと？
#別の言い方をすれば、考えてから発言してくださいと言う事。
Re:学生(計算機科学専攻)の意見ですが (スコア:2, すばらしい洞察)
『コード改善すればプロダクトの品質があがるのに、どうしてやっちゃいけないの?』という疑問は別にありえない質問ではないと思います。それが出来ないのなら「なぜできないのか」をきちんと挙げ、「できるようにはならないのか」を考える事も必要ではないでしょうか。
# なぜできないのか、は他のコメントで多くの方が言及されていますね
例えばリファクタリングコストでも、「機能のカプセル化」や「テストユニット」が出来ていれば、変更のコストや全体への影響は小さくなるはずです。方法論としては、eXtreme Programming や OOP, Design Pattern などが発展してきていると思っています。
仕事的にも「開発メソッドの改善」「QA方法の確立」等の形でやっている人もいると思います
現実的に難しいのは理解してますけどね。上や客まで巻き込む必要が往々にしてありますから。私だって勝手に検証済みのコードをいじられたら非常に困りますし、上に挙げたようなことも実現できてませんから。
Re:学生(計算機科学専攻)の意見ですが (スコア:1)
あまり雑誌には載らない話題なので、学生だとあまり視野に入らないかもしれませんが、技術者にとって、世間一般の常識と、技術者の現場の常識や制約条件の角逐は、非常に深刻な問題です。
私は若いのであまり経験は豊富ではありませんが、営業担当者と技術者の言い分のずれのために、喧嘩状態になり、社内の人間関係が非常に険悪な状態になるのは、しょっちゅうです。
会社の技術者の大半が、あまりに無理解で無茶な要求をされるのに嫌気がさして、「金をもらっているから仕方なく働く」という無気力状態になってしまったこともありました。
そして、技術者のつらい内部事情を、十分に包括的に分かりやすく説明する書物が存在しないのも、問題だと思います。これだけ理解されず虐げられているのに、みんな愚痴ったり、理解されないようなことをやっているのを威張ったりしてるばかりです。なぜ、理解してもらえることを目指して活動する人が少ないのか、不思議だと思います。
Re:学生(計算機科学専攻)の意見ですが (スコア:1)
> >なんてのはよくあるよ。
> 別ACだが、それは偶々鉄砲の玉が的に当たったと言うだけ。
現場の人は色んな柵があって言えないことを、現場の細かい事情とか知らない人が口にしちゃう、ってこともありますね。
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
>
他人をうまく誘導して、言わせてしまうという高等テクニックもあります。
が、失敗すると自分の部署にのみ危険な言葉が出てきてしまう諸刃の刃。
素人にはお薦めできない。
＃まだまだ素人なのでAC
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
雑談サイトなのだからべつにいいじゃん。
正解ではありえないパターンが１つ証明されたという事で
あたたかく見守ってあげようよ。
# 会議の場だったら私だって怒りますよえぇ。
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
>当てずっぽうが当たったから、当てずっぽうで発言するのを
>考慮しろと？
あて推量も時には必要。
ブレインストーミングという意味では。
明らかに的外れなら、1度だけ頷いて（発言してくれた人に、格好だけでも敬意を払う意味で）それた話を本題に戻しましょう。