"血をもって書け。そうすればあなたは、血が精神だということを経験するだろう。"

コピー指向ブログ

geek

http://d.hatena.ne.jp/fromdusktildawn/20081026
「中途半端に〜」論のいろんな反響を見ていて結構参考にさせていただいたので、だいぶ遅いですがこれまでの自分や周りと照らし合わせながら考えを整理。ほぼ全てが誰かの言ったことのコピー、SIerでもなんでもない一学生の戯言。早く上級者の視座に立ちたい。

  • 「ケースバイケース」「例外なき規則なし」「原理主義者乙」「空気嫁」
    • 確かにそりゃそうだけど。
    • でも基礎として習うことを妄信といってしまうと、初級者は誰の話を聞けばいいんだという話になる。「守破離」とコメントしてた人がいました
    • パソコンの前に座るだけならまだいいけど、機械加工なんかだと中級者の適当なアドバイスが大惨事につながりかねない。「命綱なんて邪魔だから外せ」という例を挙げてた人がいました
  • 抽象化、保守、引継ぎのコスト
    • 最初の抽象化は確かに結構な初期投資だが、それだけでは抽象化を知らないプログラマに「可読性が」と言い訳を与えることにしかならない
    • いつまでも低きに流れるプログラマやそのレベルの教育コストを惜しむプロジェクトって…
    • 短納期単発が多くて設計している暇がないのは仕方がないが、長期的な視野を失わないように注意したい
    • とはいえ、誰もOOのコードを書かないようなところで目前の仕事を押しのけてまでモジュールがどうこうという話をするのは悪夢に近い
  • DRY
    • これも場合によるか。
    • 構造化はできるだけ意識する。誰かがおもむろに目の前で
    print 1;
    print 2:
    print 3:
    ...

と延々とpaste&fixを始めたらさすがに止める。

    • デザインパターンなんかは微妙。リソース的にシビアなエンベデッドおもちゃを作るときに「StateパターンやStrategyパターンで分岐を撲滅するぜー」ってなるかというと、別にそんな気はしない。多分スイッチの入力で分岐しまくるif文が分散しまくるプログラムができて終わり。組み込みでJava な人はどうなんだろ。
  • 「将来的に変更されるコピペはそもそも違うロジックだからDRYには反さない」「完成形においてrepeatしている部分だけを共通化すべき」
  • 「コピペはコンパイラチェックを通る/言語仕様として可能だからおk」
  • 「IDEのスニペットや補完もコピペ」「そもそもコピペは悪なのか」
    • とっくにライブラリ化されていそうな教科書のコードをそのまま書くのもコピペ。自分のライティング能力を上げるという狙いがあるのならもちろん推奨すべきだけど
    • コピペが悪なら全てのプログラマの仕事はAPIを作るか、APIを呼ぶかのどちらかになりそう
  • DSLのくだり
    • おっ面白そうと思ったがあまりピンとこなかったので、具体的な展開を見たかった

全体的には

  • 実はまだこの手の話は誰も決着を着けてない
  • 実は議論している人の一部あるいは全員がどこか視野狭窄に陥っている
  • 人間もプログラミングも進化する。今正しいことも明日には正しくないかもしれない

のどこかという気がする。これって一種の宗教戦争ですよね。一番大事なのは

  • 経験を積み、表面的な知識に惑わされずに環境に応じて融通を利かせる

ことかな。