sakazuki.info

たまに近況が更新されたりします

メモ:「同じことを2度しないようにする」というプログラマの習性が、逆に生産性を大きく下げている

calendar

reload

>余分な工数をかけて再利用可能だのプラガブルだのに設計したところで、あとから起こる状況の変化が、はじめに予見したプラガブルアーキテクチャの範囲内で起こるとは限らないのだ。

>入念な検討にコストと時間をかけ、あらゆる場合を想定した柔軟なアーキテクチャに設計すると、ますます、開発コストは増大し、工期は長くなり、ビジネスの機動性は低下し、サービス展開が遅くなる。

>むしろ、予見なんてざっくりでいいから、プラガブルアーキテクチャなど放棄して、さっさと作ってしまったほうが、トータルコストは安く、機動的で、柔軟性も大きいケースなんて、たくさんある。なにか大きな変化が起きたら、そのときまた、書き直してしまえばいい。

引用元: 「同じことを2度しないようにする」というプログラマの習性が、逆に生産性を大きく下げている – 分裂勘違い君劇場.

物凄く同意した話。
プログラマの話になってるけど、他の仕事についても割と同じことが言えるはず。

開発するものの内容によるけれど、
「同じことを2度しないようにする」ように設計すべきかどうかは
状況によって変わってくる。

さじ加減が難しいところだが、特にベンチャー企業においては
「サービス展開が遅くなる」ことの方が往々にしてデメリットとしてデカイと思っている。

まず優先すべきはスピード。
使うかどうかわからないのに、「後で使うことを考える」というのはむしろ非効率。

「同じことを2・3回する」ぐらいの事は許容してしまって、
3回目あたりで「4回目以降は同じことをしない」ための対策を考えても
遅くはないのではないかという気がする。

どういう作業は繰り返しが発生して、
どういう作業は繰り返しが発生しないかとか、
作業のどういう部分を定型化すれば効率的かとか、
その辺りのさじ加減がわかってきたら
わかってきたその時に定型化すれば良い。

そのさじ加減を理解できるようになるまでは、
繰り返しの作業を自分の手でやってみた方が良いように思う。