パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

ソースコードを書くのは単純作業?」記事へのコメント

  • 単純作業じゃないのは
    ・仕様の決定
    ・テストパターン作成
    ・単体テスト・結合テスト・・・
    ・バグの低減
    ・バグ発覚時の修正(特にS後の瑕疵担保期間に・・)
    ・バグに対する顧客・上長説明

    などなど上げればキリないけど、顧客対応・営業対応・工程管理じゃない?
    コーディング単体なんて半分単純作業だと思う・・・

    • by Anonymous Coward

      仕様通りに、スパゲッティなコードでもいいならそうかもだけど、
      効率のいいとか、読みやすいとか、メンテナンス性がいいとか、
      そういうのを考えるとなると、そこまで簡単なお仕事ではないとは思うんだけどね。

      • by Anonymous Coward

        スパゲッティなコードの元はスパゲッティな設計書にある訳で
        プログラム書く人間に判断させる設計してる時点でおかしいと思うけどな。

        自分で設計して自分で書く場合も微に入り細に渡る仕様書を書いた方が
        コーディングを瞬殺できるし障害対応の反映も楽で
        結果としてコードと設計書の齟齬も生まれづらい。

        メンテナンス性の高いプログラムはメンテナンス性の高い設計書から生まれる。

        • by Anonymous Coward

          一人情シスで内製プログラム組む立場なんでそう思うのかも知れんけど...

          プログラムのコメントから詳細設計仕様書を作成する為にできたのが、
          JavaDocだったり仕様書工房なんだと思うんだが、詳細設計をしっかりやる人
          からすると、あれは使っちゃいけない邪道なツールだったりするんかね。

          実際の所、本当の詳細設計(関数名からその関数内で作業する内容、変数までを含む)
          なんて書いてたら、やってる事ってプログラムのソースを書いてるのとあんまり変わらんでしょ。
          違うのは、実際のコードを書いているかプログラムの詳細な文書を書いてるかって話だよね。

          なんと言うか、詳細設計仕様書を書く事とコーディングを分けられてしまったから、
          詳細設計仕様書を書く事とコーディングに違いが出ただけで、本来やってることは同じ筈で、
          分けられてしまった結果が、コーディングをキーパンチャー的な仕事にしてしまった理由
          なんじゃないかなぁ...と思うんだよねぇ...

普通のやつらの下を行け -- バッドノウハウ専門家

処理中...