アカウント名:
パスワード:
単純作業じゃないのは・仕様の決定・テストパターン作成・単体テスト・結合テスト・・・・バグの低減・バグ発覚時の修正（特にS後の瑕疵担保期間に・・）・バグに対する顧客・上長説明
などなど上げればキリないけど、顧客対応・営業対応・工程管理じゃない？コーディング単体なんて半分単純作業だと思う・・・
仕様通りに、スパゲッティなコードでもいいならそうかもだけど、効率のいいとか、読みやすいとか、メンテナンス性がいいとか、そういうのを考えるとなると、そこまで簡単なお仕事ではないとは思うんだけどね。
スパゲッティなコードの元はスパゲッティな設計書にある訳でプログラム書く人間に判断させる設計してる時点でおかしいと思うけどな。
自分で設計して自分で書く場合も微に入り細に渡る仕様書を書いた方がコーディングを瞬殺できるし障害対応の反映も楽で結果としてコードと設計書の齟齬も生まれづらい。
メンテナンス性の高いプログラムはメンテナンス性の高い設計書から生まれる。
一人情シスで内製プログラム組む立場なんでそう思うのかも知れんけど...
プログラムのコメントから詳細設計仕様書を作成する為にできたのが、JavaDocだったり仕様書工房なんだと思うんだが、詳細設計をしっかりやる人からすると、あれは使っちゃいけない邪道なツールだったりするんかね。
実際の所、本当の詳細設計(関数名からその関数内で作業する内容、変数までを含む)なんて書いてたら、やってる事ってプログラムのソースを書いてるのとあんまり変わらんでしょ。違うのは、実際のコードを書いているかプログラムの詳細な文書を書いてるかって話だよね。
なんと言うか、詳細設計仕様書を書く事とコーディングを分けられてしまったから、詳細設計仕様書を書く事とコーディングに違いが出ただけで、本来やってることは同じ筈で、分けられてしまった結果が、コーディングをキーパンチャー的な仕事にしてしまった理由なんじゃないかなぁ...と思うんだよねぇ...
その手のコメントとインターフェースから設計書を書き起こすツールは設計書を作る派にとっては設計用ツール扱い。まずスケルトンを作りコメントを書き設計書を自動出力し各種チェックしてから実装開始。
1人情シスではないけれど少人数でプロジェクト回してて互いに属人性の高い仕事してるとそれくらい厳密に設計書書かないと他人に仕事任せられないし、そこで手抜きすると成果物レビューで死ぬのが目に見えてる。
不具合修正とか機能追加がメインのエンジニアではありますがエンジニアを理解しよう -- その４ [vector.co.jp]のとおり、基本的には「それをどこに書くか知っていること(理解できること)」が重要だと感じるんですよねだから、＄1ぶんの仕事は可能なら外注したいなぁ、と思っちゃいます...
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
ソースコードを書くのは簡単なお仕事です。 (スコア:0)
単純作業じゃないのは
・仕様の決定
・テストパターン作成
・単体テスト・結合テスト・・・
・バグの低減
・バグ発覚時の修正（特にS後の瑕疵担保期間に・・）
・バグに対する顧客・上長説明
などなど上げればキリないけど、顧客対応・営業対応・工程管理じゃない？
コーディング単体なんて半分単純作業だと思う・・・
Re: (スコア:0)
仕様通りに、スパゲッティなコードでもいいならそうかもだけど、
効率のいいとか、読みやすいとか、メンテナンス性がいいとか、
そういうのを考えるとなると、そこまで簡単なお仕事ではないとは思うんだけどね。
Re: (スコア:1)
スパゲッティなコードの元はスパゲッティな設計書にある訳で
プログラム書く人間に判断させる設計してる時点でおかしいと思うけどな。
自分で設計して自分で書く場合も微に入り細に渡る仕様書を書いた方が
コーディングを瞬殺できるし障害対応の反映も楽で
結果としてコードと設計書の齟齬も生まれづらい。
メンテナンス性の高いプログラムはメンテナンス性の高い設計書から生まれる。
Re:ソースコードを書くのは簡単なお仕事です。 (スコア:1)
一人情シスで内製プログラム組む立場なんでそう思うのかも知れんけど...
プログラムのコメントから詳細設計仕様書を作成する為にできたのが、
JavaDocだったり仕様書工房なんだと思うんだが、詳細設計をしっかりやる人
からすると、あれは使っちゃいけない邪道なツールだったりするんかね。
実際の所、本当の詳細設計(関数名からその関数内で作業する内容、変数までを含む)
なんて書いてたら、やってる事ってプログラムのソースを書いてるのとあんまり変わらんでしょ。
違うのは、実際のコードを書いているかプログラムの詳細な文書を書いてるかって話だよね。
なんと言うか、詳細設計仕様書を書く事とコーディングを分けられてしまったから、
詳細設計仕様書を書く事とコーディングに違いが出ただけで、本来やってることは同じ筈で、
分けられてしまった結果が、コーディングをキーパンチャー的な仕事にしてしまった理由
なんじゃないかなぁ...と思うんだよねぇ...
Re:ソースコードを書くのは簡単なお仕事です。 (スコア:1)
Re: (スコア:0)
その手のコメントとインターフェースから設計書を書き起こすツールは設計書を作る派にとっては設計用ツール扱い。
まずスケルトンを作りコメントを書き設計書を自動出力し各種チェックしてから実装開始。
Re: (スコア:0)
1人情シスではないけれど少人数でプロジェクト回してて
互いに属人性の高い仕事してるとそれくらい厳密に設計書書かないと
他人に仕事任せられないし、そこで手抜きすると成果物レビューで死ぬのが目に見えてる。
Re: (スコア:0)
不具合修正とか機能追加がメインのエンジニアではありますが
エンジニアを理解しよう -- その４ [vector.co.jp]
のとおり、基本的には「それをどこに書くか知っていること(理解できること)」が重要だと感じるんですよね
だから、＄1ぶんの仕事は可能なら外注したいなぁ、と思っちゃいます...