チームはひとつにする

・チームはひとつにする
・アプリケーションのニーズをもとにワークフレームを構築する
・リファクタリングによってアプリケーションとフレームワークを継続的に改善する

[Joshua Kerievsky – Refactoring to Patterns]

フレームワークが価値あるものとなるための方法だそうだ。実現難しいアイデアだと思う。アプリケーションの規模や種類によってはアプリケーション部分がひとつのチームで構成できない場合があるだろう。そうすると必然的にフレームワークを主体に扱うチームが形成されるだろうから。


Distributed revision control with Mercurial

英語だけど、Mercurialのことが深く書いてある文書Distributed revision control with Mercurial
MQに関することも載っている。

MQはローカルでパッチ管理するのに役に立つツールだ。まだ、ベーシックな使い方しかできないけれど、CVSからソースをチェックアウトした後に、MQで改変履歴を管理するという使い方ができる。CVSリポジトリのアップストリームブランチに追従するのも簡単だ。

あとは慣れだな。(笑

作りこみすぎ

コードを必要以上に柔軟にしたり精錬させることは、作り込みすぎ(over-engineerring)である。プログラマがこれを行ってしまう理由の1つは、システムが将来どういう要求を受けるかわかっていると思い込んでいるためである。…これはもっともに思える。ただし、それは予知能力者にとってだけだ。

[Joshua Kerievsky – Refactoring to Patterns]

肝に命じよう。


技術継承ということ

技術継承ってなんだろうと思う。

たとえば、プログラミングの師匠に付き添ってうまいテクニックを学ぶことだろうか。でも、それって単に能力の強化であるにすぎないと思う。個人でも強化できる部分だし、はたして師匠の様に使いこなせるだろうか?そこはやはり個人の能力だ。

そもそも、継承というからには物として転嫁できなければダメだろう。技術というのは言わば製品や商品にちかいものであるべきだ。それ単体で価値があるべきだ。たとえば、特許。誰しもが参照でき、それを使うことができる。ただし、価値があればライセンス契約が必要だろう。これは技術を具現化した最たる物だろう。

コンデンサの世界シェアNo1である、村田製作所。WBSだったか、インタービューに応じている社長の言っていたことが印象に残っている。村田製作所の特許戦略は出願しないことだそうだ。この戦略は特許庁の平成17年度 産業財産権制度活用優良企業等表彰を受賞している。ここには知を会社に蓄積しつづける、技術の継承ともいえるプロセスがある

それではプログラマの技術継承ってなんだろうか。まだまだ未熟でしる由もないのだが。。今は、担当してるプログラムの仕様を説明資料におとすことから始めている。

これにも価値があるとよいのだけれど。。。

仕事納め

早いもので2007年も残り僅か

今年も年末年始のお休みに突入しました。だけれど、まぁ、いつもの如く休みも有って無いようなものです。持ち分が捗っていないので、長期の休みは邪魔の入らない絶好の環境でもあります。

さてさて、年末の反省は大事です。

今年も外乱が多かったです。大きな仕事を控えていながら、リリース製品の不具合に泣かされる事が多かったです。なかなか着手できないことでいろんな方に迷惑をかけました。

そんな中でも得るものは有りました。

今日もそれを実感することになりました。当たり前の事かもしれませんが、試験でつまずき無しということです。何回経験しても嬉しい。

今回は設計前のシナリオに時間をかけました。制御する動作のパターンを洗いだし、図形を使って紙面に落としました。実際にプリントアウトしたシナリオを眺め、マーカーを片手に共通化が可能な部分に色を付けました。ほとんど文字が無くて、色の付いた図形が散らばっている様は、傍目には色塗り?お絵描き?に見えたかもしれません。

でも、今までなんでやらなかったのだろう。シナリオによって仕様が網羅されている安心感。そして、色つけによって、頭の中には共通化されたプログラムがなんとなく浮かび上がります。そこからプログラムに落とすには実際もう一段具体的な資料が必要なのですけれど、結果、試験にかける時間がぐっと少なくて済みました。

今年の教訓

良い設計は良い製品を生むのではでなく、良い製品には良い設計がある。良い設計は良く考えられたシナリオが生み出す。ジェネリック設計を主眼に置かず、まずは具体的なパターンから。急がば回れ。

Mercurial覚え書き

パッチ管理の開始: hg qinit

新しいパッチ開始宣言: hg qnew patch_name

変更をパッチに取り込み: hg qrefresh

さらなる変更をパッチに取り込み : hg qrefresh

次のパッチ開始宣言 : hg qnew next_patch_name

変更をパッチに取り込み ; hg qrefresh

で、、終わりはどうすのだろう。。

Mercurial

mercurialはcvsやsubversionと同じソースコード管理システム。

cvsやsubversionと違うのはリポジトリが分散されること。cvsと違うのはcommit単位がファイルではなく、チェンジセット(更新ファイルの集合)であること。mqというパッチ管理システムが付属していること。

cvsに慣れきった体ですが、これだけ見ても便利そうなので、今、試しに使ってます。