アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
新人 (スコア:1, すばらしい洞察)
Re:新人 (スコア:4, 興味深い)
Re:新人 (スコア:2, 参考になる)
経験上の話として聞いていただきたいのですが、(責任範囲の内部の?)インタフェース設計まではやりすぎにしても、データフローとかフローチャートのような形での構造設計と、各人の間のインタフェースなどでの意志統一の作業はどんなに納期が迫っていてもきちんとやらないとデスマーチの素になりますよ。
数日の遅れで済む所を「いきなしコーディング」ではまって数週間以上の遅れになったりとか痛い経験をしてるので(ハードでもソフトでも同じ)…
# 「急がば回れ」って昔から言う訳で:-)
Re:新人 (スコア:0)
プログラムそのものを作るならともかく、
あるデータを解析したい。とか、解析するために変換が必要。とかだと、
10行のperlを書いて、データをぶち込み、数分後にはそのperlスクリプトは不要になっているケースとか多いわけで。
IT以外の分野ですが、perlで数行のスクリプトが組めるか組めないかでかなり差がでています。
#別の技術者と話をしていて、○○(数メガのテキストファイル)の
Re:新人 (スコア:0)
#こういうのを仕様会議で見ると不安になるのでAC
Re:新人 (スコア:1, すばらしい洞察)
そうかもしれませんが「とにかくX月Y日締切の○○(研究会、
会議、論文投稿など)までに結果をだせ」という圧力がかかる
通常の工学系の研究室では、手早く欲しい結果を出すための
プログラムばかり作ります。おかげでセキュリティホールや
メモリリークやGIGOなどはあたりまえ、自分が卒業してしまえば
完全に手が離れるのでもコード品質がぼろぼろなのが普通です。
> 「設計をちゃんと終わらせてからコーディング・・・」なんて
上のようなことを言う人はおそらく個人的にこだわっている
だけか、プログラム理論好きな指導教官にしごかれたのではないかと。
Re:新人 (スコア:0)
>上のようなことを言う人はおそらく個人的にこだわっている
>だけか、プログラム理論好きな指導教官にしごかれたのではないかと。
Re:新人 (スコア:1, 参考になる)
>インターフェースをちゃんと決めてからコーディングに着手
>しましょう、とか、建前を習うわけです。
業界で15年ほど働いてますが、先ず仕様を決めないで走った
プロジェクトでまともに動いているのをみたことがないですね。
こけてデスマになったプロジェクトの原因をたどっていると
仕様を決める段階で問題がおきているのがほとんどです。
なかには動くのは動くけど、訳のわからんエラーをたまに出す
とか頭が痛くなるものもあります。設計は大切です。
Re:新人 (スコア:1)
「使えない新人」扱いはされないと思いますよ。
原則論を言うだけなら猿でもできます。
--- (´-`)。oO(平和な日常は私を鈍くする) ---
Re:新人 (スコア:0)
Re:新人 (スコア:0)
フツウにPMBOKとかP2Mとかを勉強すればいいじゃん!