アカウント名:
パスワード:
単純作業じゃないのは・仕様の決定・テストパターン作成・単体テスト・結合テスト・・・・バグの低減・バグ発覚時の修正(特にS後の瑕疵担保期間に・・)・バグに対する顧客・上長説明
などなど上げればキリないけど、顧客対応・営業対応・工程管理じゃない?コーディング単体なんて半分単純作業だと思う・・・
仕様通りに、スパゲッティなコードでもいいならそうかもだけど、効率のいいとか、読みやすいとか、メンテナンス性がいいとか、そういうのを考えるとなると、そこまで簡単なお仕事ではないとは思うんだけどね。
スパゲッティなコードの元はスパゲッティな設計書にある訳でプログラム書く人間に判断させる設計してる時点でおかしいと思うけどな。
自分で設計して自分で書く場合も微に入り細に渡る仕様書を書いた方がコーディングを瞬殺できるし障害対応の反映も楽で結果としてコードと設計書の齟齬も生まれづらい。
メンテナンス性の高いプログラムはメンテナンス性の高い設計書から生まれる。
設計書なんて無しで、可読性の高いコードを設計者が自分でさらっと書いてしまうのが一番効率が良い。メンテナンス性の高いプログラムに必要なのは、可読性が高く効率の良いコードで、そこに設計書など必要はない。無駄な書面を残すことは、二重三重の管理コストが嵩むだけでしかない。
> 設計書なんて無しで、可読性の高いコードを設計者が自分でさらっと書いてしまうのが一番効率が良い。
問題はですね。そのレベルの開発者はほとんど居ないということです。たいていの人は、良くてトランザクションスクリプト、悪けりゃスパゲティコードしか書けません(実体験より)。
ただし、そのレベルの人は設計書書かせても同レベルの品質です(地獄
つまり多くのコード書く人は単純作業しかしてないし、ストーリー元の発言も妥当だということか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
ソースコードを書くのは簡単なお仕事です。 (スコア:0)
単純作業じゃないのは
・仕様の決定
・テストパターン作成
・単体テスト・結合テスト・・・
・バグの低減
・バグ発覚時の修正(特にS後の瑕疵担保期間に・・)
・バグに対する顧客・上長説明
などなど上げればキリないけど、顧客対応・営業対応・工程管理じゃない?
コーディング単体なんて半分単純作業だと思う・・・
Re: (スコア:0)
仕様通りに、スパゲッティなコードでもいいならそうかもだけど、
効率のいいとか、読みやすいとか、メンテナンス性がいいとか、
そういうのを考えるとなると、そこまで簡単なお仕事ではないとは思うんだけどね。
Re: (スコア:1)
スパゲッティなコードの元はスパゲッティな設計書にある訳で
プログラム書く人間に判断させる設計してる時点でおかしいと思うけどな。
自分で設計して自分で書く場合も微に入り細に渡る仕様書を書いた方が
コーディングを瞬殺できるし障害対応の反映も楽で
結果としてコードと設計書の齟齬も生まれづらい。
メンテナンス性の高いプログラムはメンテナンス性の高い設計書から生まれる。
Re: (スコア:0)
設計書なんて無しで、可読性の高いコードを設計者が自分でさらっと書いてしまうのが一番効率が良い。
メンテナンス性の高いプログラムに必要なのは、可読性が高く効率の良いコードで、そこに設計書など必要はない。
無駄な書面を残すことは、二重三重の管理コストが嵩むだけでしかない。
Re: (スコア:1)
> 設計書なんて無しで、可読性の高いコードを設計者が自分でさらっと書いてしまうのが一番効率が良い。
問題はですね。そのレベルの開発者はほとんど居ないということです。
たいていの人は、良くてトランザクションスクリプト、悪けりゃスパゲティコードしか書けません(実体験より)。
ただし、そのレベルの人は設計書書かせても同レベルの品質です(地獄
Re:ソースコードを書くのは簡単なお仕事です。 (スコア:0)
つまり多くのコード書く人は単純作業しかしてないし、ストーリー元の発言も妥当だということか。