アカウント名:
パスワード:
継承図なんて要らんよ。フローチャートと同じで、まともなプログラマーにはそんなものは必要ない。
書いても良いけど品質が上がるわけではないので、結局は時間の無駄。
＞概要設計、基本設計、コーディングルール、etcetc・・・見事に全部不要なもんばかりだなあ。感心するわ。
＞いろんなものが「自称」優秀なプログラマには必要無いのでしょうね平凡なプログラマでも不要です。
あなたが平均以下のプログラマーなのは勝手だけど、平均以上の人間の足を引っ張るのだけはやめてくださいね。
おもおかついてるけど、ネタなのか真性なのか区別がつかん
真性だから「おもおか」がついてるんだろ
随分攻撃的だなぁｗ まあそれはいいけど
＞＞概要設計、基本設計、コーディングルール、etcetc・・・＞見事に全部不要なもんばかりだなあ。感心するわ。
アジャイルな開発手法もあるし前の二つは必須じゃないが、複数人で作業するならコーディング規約は必要でしょ？インデントから何からバラバラだとやってられへん。まあインデント程度なら整形プログラムで対処できるけど。
複数人で作業するならコーディング規約は必要でしょ？
コーディング規則が不要な人達を「平均以上」と定義、というオチでは？
腐ったコーディングルールほどコードの可読性を落とすものも無いと思う。
賛成できません。他にもコードの品質(可読性はその一部分)に影響するものはたくさんあります。例えば、プログラマが「まとも」かどうか、などです。
「まともなプログラマー」なら
#1759411 [srad.jp]では、
平凡なプログラマでも不要です。＜＜略＞＞あなたが平均以下のプログラマーなのは勝手だけど
と、「まとも」かどうかではなく「平凡」か、あるいは「平均」かが問題になっていますね。コーディング規則など不要、と呼べるほどの「まとも」なプログラマーは、「平凡」でも「平均」でもないでしょう。そうでないのなら、「腐ったコーディングルール」なんてものは、ほとんど存在しなくなっているでしょう。
> 複数人で作業するならコーディング規約は必要でしょ？あまり気にしなくても済んでますね。その場の雰囲気にあわせて常識的な判断で書いてもらうという感じで。そもそも、コーディング規約が異なるプロジェクトからモジュールを拝借したりするので。
>その場の雰囲気にあわせて常識的な判断で書いてもらうという感じメンバが空気が読める人だけならばそれでうまくいきますね。私が以前いたところでは、頑なに自分ルールで書く人がいたのでダメでした。例えば既存のメソッドに引数を増やす場合でさえ、methodXXX(int code, string name)↓methodXXX(int code, string name, string _strOption)みたいな感じにしてしまう。これにまた別の人が引数追加すると、methodXXX(int code, string name, string _strOption, int Value)みたいな。
合意されたコーディング規約がないと、こういうのを「ダメ」って指摘しづらいんです。
> メンバが空気が読める人だけならばそれでうまくいきますね。たとえば Javaコーディング規約 [sun.com]は空気じゃなくて明文化されてますね。日本は何でもかんでも「空気を読め」「目で盗め」で済ませようとしますが。ガラパゴスに閉じこもっていれば「常識」で済ませられるかもしれませんが、「常識」が人によって違うのが常識である世界標準ではむしろくどいくらいに明文化しておくのが当然ですね。ただ自然言語で明文化する必要は必ずしもありませんけどね。JavaやCのソースコードをExcel方眼紙で書き直して手
＞日本では既存のコーディング規約を無視して何もかも自分たちで一から作ろうとする
これが一番の無駄だろうな。
>そのほか日本では既存のコーディング規約を無視して何もかも自分たちで一から作ろうとするとかどうしようもありませんね。俺の住んでる日本と違う日本があるのだろうか？っていうかそんな酷い所あるのなら実名あげて欲しいぞ、怖いから
人数が多いプロジェクトの管理をしてみればわかるが平均以下の人もいるし俺俺ルールをみんなもっている。規約がいらないというのは少人数でやるときだけ。ましてやＣ＋＋なんて規約である程度縛ってあげないと自由が利きすぎる。
＞あなたが平均以下のプログラマーなのは勝手だけど、＞平均以上の人間の足を引っ張るのだけはやめてくださいね。
あなたの見てるベクトルと世間のベクトルが違うと言うことに気づくことも大事だと思います。
コードからUML図を作ってくれるツールを使えば、対外的なドキュメントは後から作れるしねｗ
継承図とかは接合部分にだけあればOKだと思う。最下層の部分とかには不要でしょう。だって、まともにOOやればクラスなんてどんどん増えていくし。全部は書ききれないと思う。
接合部にだけこんな感じっていう図を用意するのがいいと思う。どうしてもほしい人はDoxygenでも使って自動生成すればいい。
そんで、他人が作ったものはクラスというかモジュールは、ブラックボックスとして利用させてもらいたいっす。そのモジュールの中までは興味なし。暇があったら流し読みしたいけど。
図を一生懸命書く暇があったらテストの一つでも作ってほしいと思うんよ。
>納品図書として請求される場合があることを忘れていないか？そういうことはあるだろうけど、
＞＞ 継承図すら作らずにコーディング始めるとかには当たらんよね。その手の書類はコーディング後、又はコーディングと平行して作る物です。
というかdoxygen使えばすぐ出来ちゃうよね。
> その手の書類はコーディング後、又はコーディングと平行して作る物です。そうですよね。そんな書類よりもソースを見た方がわかりやすいし、確実。で、確実にソースに合わせるためには、ソースから起こすべき。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
問題外 (スコア:1)
世の中は案外そんなもんらしく・・・
＃で結局デスマーチ、と
Re:問題外 (スコア:4, おもしろおかしい)
継承図なんて要らんよ。フローチャートと同じで、まともなプログラマーにはそんなものは必要ない。
書いても良いけど品質が上がるわけではないので、結局は時間の無駄。
Re:問題外 (スコア:2, すばらしい洞察)
いろんなものが「自称」優秀なプログラマには必要無いのでしょうね
＃で結局デスマーチ、と
Re:問題外 (スコア:3, おもしろおかしい)
＞概要設計、基本設計、コーディングルール、etcetc・・・
見事に全部不要なもんばかりだなあ。感心するわ。
＞いろんなものが「自称」優秀なプログラマには必要無いのでしょうね
平凡なプログラマでも不要です。
あなたが平均以下のプログラマーなのは勝手だけど、
平均以上の人間の足を引っ張るのだけはやめてくださいね。
Re:問題外 (スコア:1, おもしろおかしい)
おもおかついてるけど、ネタなのか真性なのか区別がつかん
Re: (スコア:0)
真性だから「おもおか」がついてるんだろ
Re: (スコア:0)
随分攻撃的だなぁｗ まあそれはいいけど
＞＞概要設計、基本設計、コーディングルール、etcetc・・・
＞見事に全部不要なもんばかりだなあ。感心するわ。
アジャイルな開発手法もあるし前の二つは必須じゃないが、
複数人で作業するならコーディング規約は必要でしょ？
インデントから何からバラバラだとやってられへん。
まあインデント程度なら整形プログラムで対処できるけど。
Re:問題外 (スコア:1)
複数人で作業するならコーディング規約は必要でしょ？
コーディング規則が不要な人達を「平均以上」と定義、というオチでは？
Re: (スコア:0)
「まともなプログラマー」なら常識的なルールは守るから余計なルールは入れない方が安全、的な意味合いで受け取ってあげましょうよ。
Re:問題外 (スコア:1)
腐ったコーディングルールほどコードの可読性を落とすものも無いと思う。
賛成できません。他にもコードの品質(可読性はその一部分)に影響するものはたくさんあります。例えば、プログラマが「まとも」かどうか、などです。
「まともなプログラマー」なら
#1759411 [srad.jp]では、
平凡なプログラマでも不要です。
＜＜略＞＞
あなたが平均以下のプログラマーなのは勝手だけど
と、「まとも」かどうかではなく「平凡」か、あるいは「平均」かが問題になっていますね。
コーディング規則など不要、と呼べるほどの「まとも」なプログラマーは、「平凡」でも「平均」でもないでしょう。
そうでないのなら、「腐ったコーディングルール」なんてものは、ほとんど存在しなくなっているでしょう。
どんな開発であっても設計書は必要だよね？(Re:問題外 (スコア:1, 参考になる)
どんな開発であっても複数人数でやるものならば必須だよね？
アジャイルとかXPとか設計書はいらないなんて開発手法もいわれているけれど
あれってただの夢物語でJavaがポインタなんていらないぜーとか、メモリリークしないよとかとか
いっているのと同じレベルだよね？
設計書もなしでどうやって、機能テストの妥当性をレビューするつもりなんだろう
内部設計以降はいらないと思うけどさ。外部設計以前は必須でしょ。
ライブラリつくってはい、おわりーとかだったら別だけど。。。
Re: (スコア:0)
> 複数人で作業するならコーディング規約は必要でしょ？
あまり気にしなくても済んでますね。その場の雰囲気にあわせて常識的な判断で書いてもらうという感じで。
そもそも、コーディング規約が異なるプロジェクトからモジュールを拝借したりするので。
Re:問題外 (スコア:1, 参考になる)
>その場の雰囲気にあわせて常識的な判断で書いてもらうという感じ
メンバが空気が読める人だけならばそれでうまくいきますね。
私が以前いたところでは、頑なに自分ルールで書く人がいたのでダメでした。
例えば既存のメソッドに引数を増やす場合でさえ、
methodXXX(int code, string name)
↓
methodXXX(int code, string name, string _strOption)
みたいな感じにしてしまう。
これにまた別の人が引数追加すると、
methodXXX(int code, string name, string _strOption, int Value)
みたいな。
合意されたコーディング規約がないと、こういうのを「ダメ」って指摘しづらいんです。
Re: (スコア:0)
> メンバが空気が読める人だけならばそれでうまくいきますね。
たとえば Javaコーディング規約 [sun.com]は空気じゃなくて明文化されてますね。日本は何でもかんでも「空気を読め」「目で盗め」で済ませようとしますが。
ガラパゴスに閉じこもっていれば「常識」で済ませられるかもしれませんが、「常識」が人によって違うのが常識である世界標準ではむしろくどいくらいに明文化しておくのが当然ですね。
ただ自然言語で明文化する必要は必ずしもありませんけどね。JavaやCのソースコードをExcel方眼紙で書き直して手
Re: (スコア:0)
＞日本では既存のコーディング規約を無視して何もかも自分たちで一から作ろうとする
これが一番の無駄だろうな。
Re: (スコア:0)
>そのほか日本では既存のコーディング規約を無視して何もかも自分たちで一から作ろうとするとかどうしようもありませんね。
俺の住んでる日本と違う日本があるのだろうか？
っていうかそんな酷い所あるのなら実名あげて欲しいぞ、怖いから
Re: (スコア:0)
人数が多いプロジェクトの管理をしてみればわかるが
平均以下の人もいるし
俺俺ルールをみんなもっている。
規約がいらないというのは少人数でやるときだけ。
ましてやＣ＋＋なんて規約である程度縛ってあげないと
自由が利きすぎる。
Re: (スコア:0)
＞あなたが平均以下のプログラマーなのは勝手だけど、
＞平均以上の人間の足を引っ張るのだけはやめてくださいね。
あなたの見てるベクトルと世間のベクトルが違うと言うことに気づくことも大事だと思います。
Re: (スコア:0)
作っていくうちに間違いに気付けばすぐ修正できるし、
そこで重要な部分のインターフェイスが変わってしまうようなら設計能力が乏しいってのが分かります。
いわゆる優秀なプログラマーは一人で全て済ませてしまうので必要ないんでしょう。
2人以上で開発するときは、それがOSSであっても作った方がいいと思います。
ただそれに時間かけすぎても無駄なので、ある程度の規模内で一人で作れる所があれば、細かい設計資料は作らなくていいと思いますよ。
ツール利用 (スコア:1)
コードからUML図を作ってくれるツールを使えば、対外的なドキュメントは後から作れるしねｗ
Re:問題外 (スコア:1)
継承図とかは接合部分にだけあればOKだと思う。
最下層の部分とかには不要でしょう。
だって、まともにOOやればクラスなんてどんどん増えていくし。
全部は書ききれないと思う。
接合部にだけこんな感じっていう図を用意するのがいいと思う。
どうしてもほしい人はDoxygenでも使って自動生成すればいい。
そんで、他人が作ったものはクラスというかモジュールは、ブラックボックスとして利用させてもらいたいっす。
そのモジュールの中までは興味なし。暇があったら流し読みしたいけど。
図を一生懸命書く暇があったらテストの一つでも作ってほしいと思うんよ。
by rti.
Re: (スコア:0)
Re:問題外 (スコア:1)
>納品図書として請求される場合があることを忘れていないか？
そういうことはあるだろうけど、
＞＞ 継承図すら作らずにコーディング始めるとか
には当たらんよね。
その手の書類はコーディング後、又はコーディングと平行して作る物です。
Re:問題外 (スコア:1, すばらしい洞察)
というかdoxygen使えばすぐ出来ちゃうよね。
Re: (スコア:0)
> その手の書類はコーディング後、又はコーディングと平行して作る物です。
そうですよね。
そんな書類よりもソースを見た方がわかりやすいし、確実。
で、確実にソースに合わせるためには、ソースから起こすべき。
Re:問題外 (スコア:1)
無駄な時間をすごしますのう。
Re: (スコア:0)
# 後で作り直すことは同意
Re: (スコア:0)
それはその場合があれば書けばいいってだけの話
継承図 (スコア:0)
クラス図は、多分普通はコードと同期できるんだが（大規模プロジェクトの場合はそうでないのかもしれんがよく知らない）
シーケンス図書くのは第三者的（1月後の自分も含めて）な理解のために結構有用だと思うのです。