アカウント名:
パスワード:
単純作業じゃないのは・仕様の決定・テストパターン作成・単体テスト・結合テスト・・・・バグの低減・バグ発覚時の修正（特にS後の瑕疵担保期間に・・）・バグに対する顧客・上長説明
などなど上げればキリないけど、顧客対応・営業対応・工程管理じゃない？コーディング単体なんて半分単純作業だと思う・・・
仕様通りに、スパゲッティなコードでもいいならそうかもだけど、効率のいいとか、読みやすいとか、メンテナンス性がいいとか、そういうのを考えるとなると、そこまで簡単なお仕事ではないとは思うんだけどね。
スパゲッティなコードの元はスパゲッティな設計書にある訳でプログラム書く人間に判断させる設計してる時点でおかしいと思うけどな。
自分で設計して自分で書く場合も微に入り細に渡る仕様書を書いた方がコーディングを瞬殺できるし障害対応の反映も楽で結果としてコードと設計書の齟齬も生まれづらい。
メンテナンス性の高いプログラムはメンテナンス性の高い設計書から生まれる。
一人情シスで内製プログラム組む立場なんでそう思うのかも知れんけど...
プログラムのコメントから詳細設計仕様書を作成する為にできたのが、JavaDocだったり仕様書工房なんだと思うんだが、詳細設計をしっかりやる人からすると、あれは使っちゃいけない邪道なツールだったりするんかね。
実際の所、本当の詳細設計(関数名からその関数内で作業する内容、変数までを含む)なんて書いてたら、やってる事ってプログラムのソースを書いてるのとあんまり変わらんでしょ。違うのは、実際のコードを書いているかプログラムの詳細な文書を書いてるかって話だよね。
なんと言うか、詳細設計仕様書を書く事とコーディングを分けられてしまったから、詳細設計仕様書を書く事とコーディングに違いが出ただけで、本来やってることは同じ筈で、分けられてしまった結果が、コーディングをキーパンチャー的な仕事にしてしまった理由なんじゃないかなぁ...と思うんだよねぇ...
その手のコメントとインターフェースから設計書を書き起こすツールは設計書を作る派にとっては設計用ツール扱い。まずスケルトンを作りコメントを書き設計書を自動出力し各種チェックしてから実装開始。
1人情シスではないけれど少人数でプロジェクト回してて互いに属人性の高い仕事してるとそれくらい厳密に設計書書かないと他人に仕事任せられないし、そこで手抜きすると成果物レビューで死ぬのが目に見えてる。
不具合修正とか機能追加がメインのエンジニアではありますがエンジニアを理解しよう -- その４ [vector.co.jp]のとおり、基本的には「それをどこに書くか知っていること(理解できること)」が重要だと感じるんですよねだから、＄1ぶんの仕事は可能なら外注したいなぁ、と思っちゃいます...
設計書なんて無しで、可読性の高いコードを設計者が自分でさらっと書いてしまうのが一番効率が良い。メンテナンス性の高いプログラムに必要なのは、可読性が高く効率の良いコードで、そこに設計書など必要はない。無駄な書面を残すことは、二重三重の管理コストが嵩むだけでしかない。
＞ 設計書なんて無しで、可読性の高いコードを設計者が自分でさらっと書いてしまうのが一番効率が良い。
問題はですね。そのレベルの開発者はほとんど居ないということです。たいていの人は、良くてトランザクションスクリプト、悪けりゃスパゲティコードしか書けません（実体験より）。
ただし、そのレベルの人は設計書書かせても同レベルの品質です（地獄
つまり多くのコード書く人は単純作業しかしてないし、ストーリー元の発言も妥当だということか。
同感です。一人情シスですが、発注先のSIerのソースコードを見て実感しました。
SQLで数行で出来る処理をトランザクションスクリプトでぐだぐだとやっておりましたよ。
そこまでは前の職場で見慣れていたのですが、ループ処理で取得最大行数が未知なのに配列サイズを固定して１行ずつ読み取った値を配列変数に溜め込んでいました。
SIer２社とも似たようなコーディングでしたよ。
ドッチかというと>SIer２社ともこれが原因でしょうな。集合操作の概念など理解したくもないようなのが幅効かせてるトコなので。
コードってドキュメントとしては超詳細仕様だから、概観を語る資料ってやっぱ要るよ。あとソースという単一要素しかないと設計意図が不明なことがある。どうしてこの実装なのかを保証する材料に不足していることがある。リーディングのコスト掛ければ最悪どうにかできるけど、そのコストを計算から除外するわけにはいかない。
何の為にコメントというシステムがあると思ってるのか。
// 1を足すi += 1;
なんてコメント書いてる馬鹿が少なくないんだよな・・・何故ここで１を足すのか理由を書けっての。自分が何してるか疑問に思わないのかね。
概観もコードで語るんだよ。詳細を追わなくても概観のみもコードで追えるようにするんだよ。可読性が高いとは、そういうこと。
可読性が高いかどうか判断するのはあなたではないよ
チームでプログラミングをしたことがない人には、おそらく想像できないと思う
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
ソースコードを書くのは簡単なお仕事です。 (スコア:0)
単純作業じゃないのは
・仕様の決定
・テストパターン作成
・単体テスト・結合テスト・・・
・バグの低減
・バグ発覚時の修正（特にS後の瑕疵担保期間に・・）
・バグに対する顧客・上長説明
などなど上げればキリないけど、顧客対応・営業対応・工程管理じゃない？
コーディング単体なんて半分単純作業だと思う・・・
Re:ソースコードを書くのは簡単なお仕事です。 (スコア:0)
仕様通りに、スパゲッティなコードでもいいならそうかもだけど、
効率のいいとか、読みやすいとか、メンテナンス性がいいとか、
そういうのを考えるとなると、そこまで簡単なお仕事ではないとは思うんだけどね。
Re:ソースコードを書くのは簡単なお仕事です。 (スコア:1)
スパゲッティなコードの元はスパゲッティな設計書にある訳で
プログラム書く人間に判断させる設計してる時点でおかしいと思うけどな。
自分で設計して自分で書く場合も微に入り細に渡る仕様書を書いた方が
コーディングを瞬殺できるし障害対応の反映も楽で
結果としてコードと設計書の齟齬も生まれづらい。
メンテナンス性の高いプログラムはメンテナンス性の高い設計書から生まれる。
Re:ソースコードを書くのは簡単なお仕事です。 (スコア:1)
一人情シスで内製プログラム組む立場なんでそう思うのかも知れんけど...
プログラムのコメントから詳細設計仕様書を作成する為にできたのが、
JavaDocだったり仕様書工房なんだと思うんだが、詳細設計をしっかりやる人
からすると、あれは使っちゃいけない邪道なツールだったりするんかね。
実際の所、本当の詳細設計(関数名からその関数内で作業する内容、変数までを含む)
なんて書いてたら、やってる事ってプログラムのソースを書いてるのとあんまり変わらんでしょ。
違うのは、実際のコードを書いているかプログラムの詳細な文書を書いてるかって話だよね。
なんと言うか、詳細設計仕様書を書く事とコーディングを分けられてしまったから、
詳細設計仕様書を書く事とコーディングに違いが出ただけで、本来やってることは同じ筈で、
分けられてしまった結果が、コーディングをキーパンチャー的な仕事にしてしまった理由
なんじゃないかなぁ...と思うんだよねぇ...
Re:ソースコードを書くのは簡単なお仕事です。 (スコア:1)
Re: (スコア:0)
その手のコメントとインターフェースから設計書を書き起こすツールは設計書を作る派にとっては設計用ツール扱い。
まずスケルトンを作りコメントを書き設計書を自動出力し各種チェックしてから実装開始。
Re: (スコア:0)
1人情シスではないけれど少人数でプロジェクト回してて
互いに属人性の高い仕事してるとそれくらい厳密に設計書書かないと
他人に仕事任せられないし、そこで手抜きすると成果物レビューで死ぬのが目に見えてる。
Re: (スコア:0)
不具合修正とか機能追加がメインのエンジニアではありますが
エンジニアを理解しよう -- その４ [vector.co.jp]
のとおり、基本的には「それをどこに書くか知っていること(理解できること)」が重要だと感じるんですよね
だから、＄1ぶんの仕事は可能なら外注したいなぁ、と思っちゃいます...
Re: (スコア:0)
設計書なんて無しで、可読性の高いコードを設計者が自分でさらっと書いてしまうのが一番効率が良い。
メンテナンス性の高いプログラムに必要なのは、可読性が高く効率の良いコードで、そこに設計書など必要はない。
無駄な書面を残すことは、二重三重の管理コストが嵩むだけでしかない。
Re:ソースコードを書くのは簡単なお仕事です。 (スコア:1)
＞ 設計書なんて無しで、可読性の高いコードを設計者が自分でさらっと書いてしまうのが一番効率が良い。
問題はですね。そのレベルの開発者はほとんど居ないということです。
たいていの人は、良くてトランザクションスクリプト、悪けりゃスパゲティコードしか書けません（実体験より）。
ただし、そのレベルの人は設計書書かせても同レベルの品質です（地獄
Re: (スコア:0)
つまり多くのコード書く人は単純作業しかしてないし、ストーリー元の発言も妥当だということか。
Re: (スコア:0)
同感です。
一人情シスですが、発注先のSIerのソースコードを見て実感しました。
SQLで数行で出来る処理をトランザクションスクリプトでぐだぐだとやっておりましたよ。
そこまでは前の職場で見慣れていたのですが、
ループ処理で取得最大行数が未知なのに配列サイズを固定して１行ずつ読み取った値を配列変数に溜め込んでいました。
SIer２社とも似たようなコーディングでしたよ。
Re: (スコア:0)
ドッチかというと
>SIer２社とも
これが原因でしょうな。
集合操作の概念など理解したくもないようなのが幅効かせてるトコなので。
Re: (スコア:0)
コードってドキュメントとしては超詳細仕様だから、概観を語る資料ってやっぱ要るよ。
あとソースという単一要素しかないと設計意図が不明なことがある。どうしてこの実装なのかを保証する材料に不足していることがある。
リーディングのコスト掛ければ最悪どうにかできるけど、そのコストを計算から除外するわけにはいかない。
Re: (スコア:0)
何の為にコメントというシステムがあると思ってるのか。
Re: (スコア:0)
// 1を足す
i += 1;
なんてコメント書いてる馬鹿が少なくないんだよな・・・
何故ここで１を足すのか理由を書けっての。自分が何してるか疑問に思わないのかね。
Re: (スコア:0)
概観もコードで語るんだよ。
詳細を追わなくても概観のみもコードで追えるようにするんだよ。
可読性が高いとは、そういうこと。
Re: (スコア:0)
可読性が高いかどうか判断するのはあなたではないよ
Re: (スコア:0)
チームでプログラミングをしたことがない人には、おそらく想像できないと思う