404 motivation not found | t_ishidaのブログ

1月/70

1

100万行のソースコードの作り方

前置き

100万行のソースコードの作り方

http://japan.cnet.com/blog/umeda/2004/04/26/entry_1001/

http://japan.cnet.com/blog/umeda/2004/04/27/entry_1002/

http://japan.cnet.com/blog/umeda/2004/05/14/entry_100/

と言うのを読めと、とあるPHPフレームワーク*1の開発者の方から

メール頂きまして読みました。

感想

率直に言って、「何を当たり前な・・・」と言うところです。が、「誰も当たり前なことなんか出来てねーだろ!!!」と、マジで叫びそうになりました。

そう、例えばこれこれ。

よく、米国のドラマで、パーティーで上司に会う場面で、やけにびくびくしている部下という図がありますが、あれは下手なことをするといつ解雇になるかわからないという背景を冗談をまじえて強調しているのだと思います。それが原因かどうかは分かりませんが、命令体系は、完全トップダウンです。上の命令は絶対です。

そう、これがまず出来ていない。

誰かが責任持って決めて、

決めたことを覚えておいて、

最終的な絵を描き続けて、

そこから外れたら突っ込みを入れて、

喧嘩して、

どうにもならなきゃプロジェクト外す。

これがやれなきゃ、進まないだろ。

最後の二つはさすがに僕もやりすぎだと思うけど、

大体のプロジェクト、上から1つ目でこけてるだろ。

そんなんじゃ出来るわけ無いじゃん。

エンジニアはひたすら開発を行ないます。そして、開発したコードはエンジニア相互のレビューに廻されます。

(中略)
毎日タグと呼ばれる印をつけて(これはいつでも過去の状態に戻せるようにするため)、デイリービルドを作成し、テストに廻します。このサイクルはほぼ毎日行なわれます。

(中略)

設計書を出せと言っても出てこないことがあるかと思いますが、その場合には設計書自体が存在しない可能性が大です。

レビューですね。

やってるところはやってるんでしょうが、やらないところはやらないでしょう。

  • 教育
  • 品質保持*2
  • 信頼確保*3
  • コミュニケーション

レビューなんか時間勿体無いよ。とか言う奴が居たら、お前末代まで呪われろ。レビューすることで、いい加減なコードを書かせない。レビューが有るからいい加減なコードを書けない。それがもたらす結果は、レビューに割いた時間なんか、お釣が倍になって万馬券位の配当になって返ってくるわ。忙しいなら、ウオークスルーじゃなくても良いから、ソース読んで、ソース読ませろ。ブログにソース載せるとか回りくどい道楽より余程勉強になるわ。

それと設計書。

要らんよね。思考整理の為のメモ程度で良いよね。どうせ、改修加わっても、設計書直さんし。ならはじめからアテにしたくないから要らん。書いてる時間、それこそ勿体無いわ。でも、SI的には必要だよね。比べるところが間違ってるから、強くは言及しない。

テスト人員は開発の段階と共に、また製品の規模に応じて、様々に変遷します。ソフトウェア開発初期のテストエンジニアの配分は、開発エンジニア3に対し、テストエンジニアの1とされていいます。つまり開発をするエンジニアが30人いれば、テストエンジニアを10人割り当てなさいということです。
(中略)

噂によると、シスコやマイクロソフトでの割合は、開発エンジニア1に対し、テストエンジニア1だそうです。製品の規模が大きくなるにしたがって、テストをするのも、テストケースを作るのも難しくなってきます。場合によっては、開発エンジニアと同等かそれ以上のスキルがテストエンジニアに要求されることも珍しくありません。

テスターの割合が、規模によって変わってくる。「ふーん、当たり前じゃね?」と思いつつ、「その当たり前出来てないよね?」と、叫びたくなった。複雑度ベースの見積もりを知っているだろうか?複雑さと、その量で工数を見積もる見積もり法なんだが、アレは複雑度と量の定量ベースで工数が積みあがっていく。だが、現実のプログラムは、「例え、複雑さが少ないものだったとしても、100個積みあがれば、複雑さが高いものが10個積みあがったものよりも、圧倒的に複雑である」物凄く大げさだけど、なんとなく言っている事がわかると思う。それと、テストエンジニアのスキルが高くないとイケナイのは当たり前。新人にテスターやらせているプロジェクトは呪われろ。

結論を兼ねたTODO

  • いい加減、BTSを試して運用フローを作る。用意してくれた人に悪い。
  • いい加減、CVSを入れるか、ソース管理の仕組みを考える。ちゃんと運用するならtarボールでも構わん。
  • 誰がパイを握っているのか?それをハッキリさせる仕組みを作る。
  • ソースレビューをしっかりする為の運用フローを考える。ソースレビューに向けて、コメントを付け直す。コメントにダジャレ入れたり、エイプリールフール的、嘘コメントをふざけて入れたのを消す。何も返さないし、何の副作用も無い関数をウケ狙いで書いたりしない。

*1:Magic3

*2:少なくとも、その時点では読めるコードである事を保障する

*3:いい加減なコードを書かせない抑止力になる

Share and Enjoy:
  • Digg
  • del.icio.us
  • Google Bookmarks
  • Tumblr
  • email
  • Facebook
  • FriendFeed

RSS Feed

コメントはまだありません。

Leave a comment!

<< 色々自動化したいと考え中

Find it!

Theme Design by devolux.org

Tag Cloud