アカウント名:
パスワード:
> 仕事ソフトの開発現場に色々と(他人には)謎な制約がつくのは、他の人も散々言っているように、 「しがらみ」です。 > かなり多くの場合、それは誉められたものじゃないですね。ソフト工学(だよね)に反しているのだから
「ソフトウェア工学が未熟だから」という理解もできることも覚えておいた方がよいでしょう。
「しがらみ」があるのが現実であって、現実に使ってもらえるものを作るのが生産です。
ソフトウェア工学は学問ですから一定の切り口を持っています。 現実は混沌としています。この両者のバランスが大切なのであって、ソフトウェア工学の立場からの意見だけを言ったって、得るものは少ないですよ。
蛇足ですが、誉められるために仕事するんじゃないんです。よろこんでもらうために仕事をするんです。
ソフトウェア工学は一つの道具にしかすぎません。
大切な道具ではありますが。
実行速度が劇的に速くなると言っても、今動いているものは、要求された時間内に終了しているのですから、それ以上を求めるのは趣味の世界です。 （要求された時間内に終了しなくなっているものに対しては「いじるな」とは言わないでしょう） 「速ければ速い程良い」というのは、まさに現場を知らないど素人の考え方、趣味の世界の考え方ですね。
そんなアルゴリズムを考えられるほど余裕のあるプロジェクトは ここ１０年お目にかかっていないですね。
# 「美しい」という、出題者の主観のみによって変更されてる点もポイントだ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
学生(計算機科学専攻)の意見ですが (スコア:1, 興味深い)
「既にこの問題を解くアルゴリズムが出来てるんだから、新しいのは作るな」
と言われていると思えて仕方ありません。 ほんの少しデータ構造などを変更するだけで実行速度が劇的に速くなったりすることもあるので (ライブラリを使ってたとしても、それが今実行したいものに対して不向きだったりする場合もある) 完成品でも多少見直すくらいはしても良いと思います。
#現場を知らないど素人が！と言われそうなのでAC
Re:学生(計算機科学専攻)の意見ですが (スコア:2, すばらしい洞察)
自己満足でお金はもらえないんです。お客さんもよろこびません。
: 〜〜〜 パルナス、けだるい日曜日。 〜〜〜
Re:学生(計算機科学専攻)の意見ですが (スコア:1)
それ、べつに学生プロジェクトには無いものだ、とは限らないはずですが…？
＃共同作業をぶっちぎって一人勝手にCで書いたんでG7。よくまぁあんなもんで卒業させてくれたもんだ…(藁
＃＃でもFortranはマジ勘弁。Fortranそのものというよりも「ルーチンもデータも全然構造化できてねー世界」がウンザリ。数十年モノのプログラム(の書き方)とかが有る世界なんだぜ。参った参った…
仕事ソフトの開発現場に色々と(他人には)謎な制約がつくのは、他の人も散々言っているように、
「しがらみ」です。
かなり多くの場合、それは誉められたものじゃないですね。ソフト工学(だよね)に反しているのだから。
Re:学生(計算機科学専攻)の意見ですが (スコア:1)
> 「ちゃんと動いているコードをリファクタリングするな」というのは、
> 「既にこの問題を解くアルゴリズムが出来てるんだから、新しいのは作るな」
> と言われていると思えて仕方ありません。
の部分に対してコメントしたのであって、学生うんぬんの話はしておりません。
: 〜〜〜 パルナス、けだるい日曜日。 〜〜〜
Re:学生(計算機科学専攻)の意見ですが (スコア:1)
> 仕事ソフトの開発現場に色々と(他人には)謎な制約がつくのは、他の人も散々言っているように、 「しがらみ」です。
> かなり多くの場合、それは誉められたものじゃないですね。ソフト工学(だよね)に反しているのだから
「ソフトウェア工学が未熟だから」という理解もできることも覚えておいた方がよいでしょう。
「しがらみ」があるのが現実であって、現実に使ってもらえるものを作るのが生産です。
ソフトウェア工学は学問ですから一定の切り口を持っています。 現実は混沌としています。この両者のバランスが大切なのであって、ソフトウェア工学の立場からの意見だけを言ったって、得るものは少ないですよ。
蛇足ですが、誉められるために仕事するんじゃないんです。よろこんでもらうために仕事をするんです。
ソフトウェア工学は一つの道具にしかすぎません。
大切な道具ではありますが。
: 〜〜〜 パルナス、けだるい日曜日。 〜〜〜
Re:学生(計算機科学専攻)の意見ですが (スコア:1)
そうですか？
少なくとも「排除せんとしょーがないシガラミ」も結構有るように感じてますが…
少なくとも、自分の言動の馬鹿さ(ソフトつくりへの不向きさ、貢献のマイナスさ、という意味だと思ってください)
を「棚に上げて」シガラミの遵守を要求し続けるのってのは、それはそれで相当不毛だと思います。
でも、この不毛をやらかすんだよね、人間は。
シガラミに従っていれば(現実に使ってもらえるものが)作れる、というわけでもないです。
馬鹿のいう事に合わせてたら、出来るものも出来なくなってしまう、という現象は
これまた頻繁に観測されるわけでして。
>ソフトウェア工学は学問ですから一定の切り口を持っています。現実は混沌としています。この両者のバランスが大切なのであって、
そのバランスなんですが、「現状のバランス」が良いバランスだとは、限りませんよ？
バランスを直すか、現状程度の品質で満足(妥協)するか、どっちかですね。
ところで我々は、品質を「改善」したかったのではないのでしょうか？
＃少なくとも所謂シガラミの中に品質の改善のネタが有るようには、まるで見えないのでG7
>蛇足ですが、誉められるために仕事するんじゃないんです。よろこんでもらうために仕事をするんです。
そういうのは、必要最低限(?)の品質を満たして初めて、言えることですね。
まあ、今の品質に(おおむね)満足している、という(幸福な)プロジェクトならば
とやかく言う必要は無いのですけどね。シャカリキになって品質を上げる努力を
する必要が無いプロジェクトなわけですから。
でも、そんな幸福なプロジェクトって、果たしてどれだけ有るんでしょう？？
現状(シガラミだらけな状況)が実際にヤバイからこそ、
工学だのなんだのという新しい道具が考案され続けるわけです。
卑近な所を一丁。
「お客さまは神様です」という典型的なシガラミは、しばしばソフトを破綻させますよね。
破綻させられるものを、そのまま受け入れろとでもおっしゃる？
プロとアマ (スコア:1, 興味深い)
結局，最終的には，プロはアマに敵わないというのはそういう事情ですね。
プロの最低はアマの最低よりもはるかに高い。でも，プロの最高はアマの最高
に及ばないことがしばしばあります。
これは，プロの方が技術レベルが低いから，ではなくて，コストベネフィット
を考えるときの「ベネフィット」として「お金」しか考えないからでしょう。
（それがプロの定義。）
「自己満足」＝お金をもらうことによる満足以外の満足。つまり，得意先がお
金を払う前に，評価できるものだけが，自己満足じゃない満足。よくも悪くも。
Re:プロとアマ (スコア:1)
アマの最高がプロの最高をしばしば上回るって、
例えばどんなのがあるでしょうか？
自分の知る範囲では、なかなかないもので。
Re:プロとアマ (スコア:0)
いまここで行っている「プロ」か「アマ」かという区分であれば
アマであると言えると思うけど？
#いまは企業として参加している人もいるから微妙なところもあるけど
#少なくてもGNUの出発時点はそうですよね？
Re:プロとアマ (スコア:1)
今のオリンピックみたいな感じ。
「プロの出るアマの祭典」
Re:プロとアマ (スコア:0)
あります。
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
の部分は私も意味がわかりません！
Re:学生(計算機科学専攻)の意見ですが (スコア:2, すばらしい洞察)
現場を知らないど素人は「リファクタリングに必要なコスト」＝「プログラミングにかかる人件費」としか考えていない場合が多いですが、実際には検証にかかるコストやリファクタリングしたものを配布するコスト、配布が完了するまでに複数バージョンが並存する事によるサポートコストの方が何倍も（場合によっては何十倍、何百倍も）かかる事も珍しくありません。
また、人間が関与するものである以上、変更に伴う諸々のミスにより、動作しなくなるというリスクを0にする事はできません。
それだけのコストをかけてもなおメリットが得られる場合というのは、そうそうあるものではありません。
実行速度が劇的に速くなると言っても、今動いているものは、要求された時間内に終了しているのですから、それ以上を求めるのは趣味の世界です。
（要求された時間内に終了しなくなっているものに対しては「いじるな」とは言わないでしょう）
「速ければ速い程良い」というのは、まさに現場を知らないど素人の考え方、趣味の世界の考え方ですね。
Re:学生(計算機科学専攻)の意見ですが (スコア:1)
>それだけのコストをかけてもなおメリットが得られる場合
だからこそ、テストの自動化が成立してる場でないと、リファクタリングなんてものは、やれないのでしょうね。
検証のコストパフォーマンスをどこまで下げられるかが重要な問題になってきます。
テストは人間にやらせないと安心できないという原始人(原始会社)には、土台無理な話なのかも知れません。
＃未だにそういう人種が絶滅してないのでG7
＃なんで文字列を肉眼で見るほうがstrcmp()より信頼できるのか、小一時間問い詰めたい。
>実行速度が劇的に速くなると言っても、今動いているものは、要求された時間内に終了しているのですから、それ以上を求めるのは趣味の世界です
そりゃそうと最適化とリファクタリングは別らしいですね。
リファクタリングは自分ちの掃除。機能は変わらない(変わっちゃいけない)し、
性能だってまあ変わらない(下手したら少々下がるかも知れない)。
得られる(＆目指すべき)のはひたすらメンテ性。
処理速度は単純な時間で済む問題でしょうけど、メンテ性って単純じゃないんだよね。
印象としてだけど、ある閾値(どうやって定量化するかはさておき)を越えると途端にメンテは「困難」になるし、
その閾値が今自分が居る場所とどれほど近いか？は、実はよく判らないことが多い。
だから、ふと気付いたらメンテ困難な状況に水没してる、っていう事が結構ある。
だから、「まだ掃除しなくても大丈夫っしょ」とか思っていると、ある日突然足を掬われる。
だから、一見大丈夫っぽくても、ソースを綺麗にする努力を継続せりゃならんという話になるわけで。
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
リファクタリングがはじめ90%なのか残りの10%なのかで少し事情がかわってくるかもしれませんね。
Re:学生(計算機科学専攻)の意見ですが (スコア:1, 参考になる)
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
Re:学生(計算機科学専攻)の意見ですが (スコア:2, 興味深い)
>「既にこの問題を解くアルゴリズムが出来てるんだから、新しいのは作るな」
>と言われていると思えて仕方ありません。
アルゴリズムやデータ構造で劇的に改善できるならば
プロジェクトマネージャとまず相談ですね。
劇的に改善されるならば、それはまだ完成していない状態ともいえます。
パフォーマンス（処理時間）も含めたテストで
ＯＫが出ているのですから一般的には改善の余地は無いと思います。
そんなアルゴリズムを考えられるほど余裕のあるプロジェクトは
ここ１０年お目にかかっていないですね。
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
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度だけ頷いて（発言してくれた人に、格好だけでも敬意を払う意味で）それた話を本題に戻しましょう。
Re:学生(計算機科学専攻)の意見ですが (スコア:1)
個人的な研究や趣味の範囲はさておき、営利企業における開発なら、そういわれても仕方ないと思います。
ただし、その新しいアルゴリズムを顧客に説明し、理解してもらった上で、リファクタリングにかかる費用を捻出できるなら、新しいアルゴリズムでリファクタリングすることも認められると思いますよ。企画力・調整力・プレゼンテーション能力が必要です。
費用の捻出は、顧客から出してもらうことを含みますが、それ以外でも例えば、保守性が上がり社内の保守工数が減ることで相殺できると言ったことも含みます。
良くも悪くも、営利企業における開発とはそうしたものです。研究だって、チームでやる場合には、勝手にコードをいじることが許されない場合もあるんじゃないかな。私はそういう研究をやったことがないけど。
個人的な研究や開発であれば、どう行おうと自己責任で、でおしましです。
Re:学生(計算機科学専攻)の意見ですが (スコア:1)
>「既にこの問題を解くアルゴリズムが出来てるんだから、新しいのは作るな」
>と言われていると思えて仕方ありません。
学生向けに説明すると「採点が終わった答案を書き直すな」ってところかな。
書き直すなら、テスト時間内か次回のテスト時にしなさいってこと。
# ちょっと方向が違うか？
Re:学生(計算機科学専攻)の意見ですが (スコア:1)
「あ、ごめんここ間違ってた。文章の解釈変えたからもう一度テスト受けてくれ」
って言って、再テスト（しかも点数ももちろん再テストの結果による）させられるようなもんでは。
そんなことさせられたら学生はたまらんだろー。
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
「あ、ごめん。ここ試験問題として美しくないからもっと美しい問題に変えてみた。もう一度テスト受けてくれ」
と言うようなもんでしょう:-D
# 「美しい」という、出題者の主観のみによって変更されてる点もポイントだ
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
> 「既にこの問題を解くアルゴリズムが出来てるんだから、新しいのは作るな」
> と言われていると思えて仕方ありません。
ものすごい「日曜プログラマ的発想」ですね(^^;
実際のプロジェクトでこんなこと言ったら袋叩きに会いそうです。
ただ、学生さんはこう
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
それはコーダー。
コーダーには別の視野とかは理解できなくてもしかたないし、理解できなくても問題無いように管理することが大切。
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
日本はプログラマの地位が低くないですか？
大体が入って数年後に自動的にSEになりますね。
私は50歳になってもプログラミングしていたいのだが。
Re:とあるマーフィーの法則 (スコア:0)
管理職に出世することにより、プログラミングから卒業する。
無能なプログラマ:
自分の能力に見切りをつけて、プログラミングから卒業する。
普通のプログラマ:
自分の年齢を理由にしないと、プログラミングから卒業できない。
# 異業種しか知らないのでAC
Re:とあるマーフィーの法則 (スコア:0)
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
そうですね。でも、それでなにか問題ありますか?
まさかあなたが50歳になってもプログラミングを続けるために、
日本でのプログラマの地位を引き上げろ、とでも?
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
わたしやあなたが定年までプログラマができるように地位を引き上げて欲しいです。
＃少なくともいい歳してプログラマやってるのはなぁという雰囲気はなくなって欲しいねぇ。
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
お茶ﾄﾞｿﾞｰ(*･ω･)つ 旦