blog.fuktommy.com/ 長文記事

何かプログラムを作る必要が出てきたらライブラリを調べて、それで知識がついて、今後の役に立ったりする。でも必要がなければライブラリを調べるということはない。他にも仕事関係でそういうのってあるよね。ある程度広く浅く知識を持っておきたい分野について、でも直近で必要ないから調べてないというのはけっこうある。調べたくなるようなイベントを毎日発生させることができれば違ってくるのかな。ではどうすればイベントを発生させることができるのか。

> 最初は機能が少なくてもパフォーマンスが速いこととバグがないことだけは守るべきだ

その通り。

> ユーザーが欲しているとイメージしたものは必ずと言っていいほど間違っているわけです。
> (中略)間違っていることに気づいて、それをすぐに改善できる開発のスピードが大事

うんうん。まったくその通り。でもそれがなんで

> コードがどれくらいきれいかを気にする人は出来の悪いプログラマー

になるんだろうね。これは矛盾していると思うんだが。
というのも、汚いコードはたいがい設計が腐ってる。
したがってバグがあるのは当たり前だし、パフォーマンスも悪い。
それでもいいから開発速度を優先するというのもありえなくはないが、
アイデア一発勝負みたいな、ごく限定された状況だけだと思いますよ。

そして汚いプログラムを直したり新機能を入れたりするのにはやたら時間がかかる。
それでいいというのは、最初のサービスインは急ぐけど、
それ以降の改善はゆっくりでいいという、これまた不思議な状況で、普通には考えられません。

http://wired.jp/2012/02/03/interview-ginzamarkets/5/

んで

> ポイントは、「コードの見た目は後でいい。」の部分で、
> おいらは、コードの見た目はいつまでも汚いままでいいとは言ってなくて、
> 直す必要があれば、後から直せばいいと書いてるわけです。

後から直す時間なんかありませんよ。
ユーザーの動向をみて、どんどん新機能を追加するなり、使われてない機能を削るなり、
新規の開発をやらねばならんのです。

開発において用語の定義は重要だというのを同僚の人が言ってたけど、チームで濃い開発をしたことによって、その重要性を初めて認識した。予め適切な用語のある分野であればいいとして、「AのときとBのときで動きが微妙に違う」とかだと、A,Bそれぞれを何と呼ぶのが適切だろうか、とかね。

用語を適切に定義することでチーム内での認識ずれが減るというのは、たぶん予想できるはず。

また、これは予想なのだけど、適切に定義された用語は、そのままプログラムの実装に落としていくことができるし、適切なカプセル化、モジュール化に繋るんじゃなかろうか。

これはよいことだと思う。前提条件として、職員がFacebook上でプライベートな書き込みをしていて、それを市民からどうのこうの言われたとしても、市が職員を守ること。そういう雰囲気が一般化していくと、同じ人物にもプライベートと仕事があるんだなあという、当たり前のことがWWWでも広く認識されるのではないか。