プログラマをクソコードで殴り続けると死ぬ - megamouthの葬列
ここにクソコードがある。 誰が作ったかはわからぬ。それが、どのような経緯でクソコードとなったのか、 あるいは、最初からクソコードであったのか、それらは全てクソコード自身が知るのみである。 ファーストコンタクト ある日、営業からシステム案件を打診されたので見積もりして欲しい。というメールが来る。 とある企業の既存システムに機能を追加する簡単な案件ですが、なななんとソースや仕様書をご支給いただけます！ と、それはサンタにプレゼントが貰えると信じて疑わぬ子供のような真っ直ぐなメールである。 ソースコードが入った圧縮ファイルを受け取ったプログラマは、早速、コードを読んでみる。 そのシステムが本当にいいコードで書かれているかを判断するには時間がかかるが、 クソコードであるかはおおよそ30分でわかる。 インデントがタブとスペースどちらかに統一されていないとか、フレームワークの誤用があるとか、またはフレ
クソコードにならない為に、これだけは守って欲しい７つのこと - Qiita
まえがき 今回書く内容は、ある程度経験あるエンジニアでも、陥りがちなものに絞って書いてみたつもりですので、[重複コードは書かない]などの超あたりまえの事は書いていません。 2017/03/16 最近よく見られてそうなので１つ追記[そもそも継承するな!!!] そもそも継承するな!!! 継承するのは、どうしようもない場合のみにしてください。 その前に、strategyパターンや、compositeパターンなどの他のやり方を考慮してもなお、継承するのが妥当である場合のみにしてください。 基本的に継承しないほうが、スケーラブルだし、テストコードも容易にかけます。 継承はis-a関係 「あー、継承ね。はいはい」で飛ばしてんじゃねーよ。 いやマジで!!! ほぼ全てのエンジニアは[is-a]が何か知っています。 というのも全てのオブジェクト思考の書籍には出てくる概念だからです。 しかし、私の経験上この概
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
古のJavaを使うということ / JJUC CCC 2016 Spring
