アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
ITでも (スコア:2, 興味深い)
新しい開発形態には新しいレビュー形態(視点)が必要
ってことだな。
例えばOOPコーディングを従来の手続きオンリーの視点で(だけ)レビューすると、的外れなレビュー結果が出かねない。
(だからOOPをやめる、ってのは適切とは限らないぞ)
Re:ITでも (スコア:1)
トピ名が「材料」に寄ってるから、ここはプロジェクトで採用するフレームワークやライブラリの話の方が広がるかも？
行数だけでプログラムの規模や品質測られるよーな笑い話も、減って来てる
と信じたい昨今ですしRe:ITでも (スコア:0)
何かある？
# ファンクションで測ろうったって「重み付け」で勘が入るし
# 機能の複雑さは普通行数に比例するべ？と言われちゃうし
Re:ITでも (スコア:0)
しかも、zipなりlhaなりで圧縮後のサイズで。
コピペで同じコードの比率が高いと、その分、圧縮率も上がって、サイズは小さくなる。
あ、でも、オブジェクトだとコメントがサイズに影響しないから、
コメント皆無のソースで出来上がってきそうだな…。
コメントの無いソースはメンテしたくないなぁ…。
Re:ITでも (スコア:0)
多数のよく似た、しかし相互に少しずつ異なる処理を行う場合、
意図的にコピペを多用する場合があります。
下手にコードを共通化して複雑にするよりも、
似たやり方で個別に書いた方が分かりやすくなる場合もあるのです。
また一部のパターンにおいてより単純化できるとわかっている場合があっても、
あえて他と設計方針を揃えるために冗長な構造を採る場合もあります。
ボトルネックとなる箇所ならともかく、パフォーマンスに大差が無ければ、
より書きやすくメンテナンスのしやすいコードの方がむしろ高品質といえる場合も少なく無いのです。
Re:ITでも (スコア:0)
コピペ＝低製造コスト
ってことで考えてました。
出来上がったものの品質を計るには、どうしたら良いですかねぇ？
品質を考えると、納品後のバグ率とかですかね？
品質の視点からすると、バグが少ない、変更が容易(短時間で済む)のが、良いコードかなと思うのです。
そうすると、コピペ三昧でも、関数大増殖でも、あまり構わない。
要は、バグが少なくて、変更しやすい(程度によるでしょうけど)のであれば、
コーディングがどんな華麗か！どんなに醜悪か？なんてどっちでも良いんですから。
あっ、納品後のメンテも、製造側にやってもいましょう。
でも、お支払いする対価は、決まった額だけ。
バグが少なくて、変更が容易なコードだったら、低いコストで対応できることになるので、メンテ費は黒字。
逆に、とりあえず納品しました…てレベルのコードなら、メンテのコストが高くつく。
頂いているメンテ費から足が出て赤字かも？
ん～、すでに、どこかで、実践されてたりして？
Re:ITでも (スコア:0)
というか、いざバグが出たときの修正費用を
どっちが持つか
(製造元か、それとも追加料金を頂くか)
っていう論点で
営業のかたがたは日夜奮闘なさってるようです。
よく判らないんだけど、
「それが」営業の仕事なんだろうか？とは日夜不思議に思います。
あと、「バグが少なくて」といっても、
バグの定義が問題になるんですよね。
つまり要求が何を言っていたか？の解釈を洗いなおす羽目になる。
それ次第でドッチが悪いかがコロコロ変わってしまう。
ついでにいえば、ちゃぶ台返