構成管理をちまちま始めるヒント集 - 「パターンによるソフトウェア構成管理」バーチャック、アップルトン

構成管理というは、開発プロセス全域に影響があるので、変化を起こすときに大変な思いをすることがあるんじゃなかな、と思います。プロジェクトの途中で、しかも、自分が下っ端だったり、いろんな事情で発言力が弱いときだってあると思います。どっかのこわい話とか、バージョン管理システムについて  の話題とか。

そんなときに、この本のプラクティスをちょっとずつ実践することで、ちょっとずつプロセスに変化ができて、その変化に慣性がついてくれば、大きな変化になるのかも知れません。幸か不幸か、私の職場は mercurial + trac 、最近は　redmine ですし、多少ラディカルな変化も受け入れやすい体質なので、よく分かりませんが。

すべての変更（とその依存関係）が、集約化された統合ビルドプロセス によってビルドされるかどうかを確認して下さい。 p.114

Python のウェブアプリの場合は、本番環境へのデプロイも含まないといけませんね。実行時まで分からないことが多いというのは、こういうとき割と不便です。

新しいメジャーリリース用にコードラインを分岐する時が来たら、前回のリリースラインから新しいリリースラインを分岐する代わりに、まず前回のリ リースラインを本流にマージして下さい。そこから新しいリリースラインを分岐してドさい。 p.62

まず、現行最新版の変更を、メインの開発作業に取り込め、ということですね。

バージョン管理システムを使って、ベンダから受け取ったソフトウェアのバージョンと、顧客に配布したソフトウェアの両方を管理して下さい。 p.123

どっかから拾ってきたライブラリを使用するときには、(1) 本家から引っ張ってきたコードを保持するブランチ/リポジトリ、と (2) そのコードを自分で変更したコードを保持するブランチ/リポジトリで管理せよ、ということです。本家でバージョンアップがあったら(1) に取り込み、つづいて、(1) を (2) に取り込む、ということです。

フレームワークが大きくバージョンアップするような場合には、そうはいきませんが、それはまあアプリケーションからみたら、プラットフォームが変更されるということなので、ここでの議論の対象外です。

それぞれのビルドをすべてスモークテストの対象とし、アプリケーショ ンがあまりにも明らかな形で動かなくなることがないように検証しましょう。 p.145

スモークテストというのは、機械の箱を開けて修理したあとに、電源を入れたときに煙が出ないか確認する、というのが語源です。つまり、よっぽどひどいコード変更をしていないのか、というののテスト。

API を提供するサーバ開発と、JavaScript や Flash で書かれたクライアント開発が、別組織になっているときのデバッグ中に使いました。各 API 個別のテストはもちろん書いてあるのですが、それとは別に、ちょっとした変更を依頼されたときに、スモークテストを走らせていました。

回帰テストのテストケースは、以下の項日から構成するとよいでしょう。

- リリース前の品質保証プロセスで見つかった問題。

- 顧客およびユーザから報告された問題。

- 要求什様に雌づくシステムレベルテスト。 

p.158

（テストがないという意味での）レガシーコードを触るときに、これやりますね。まず fail するテスト書いて、修正して、pass させる。それを回帰テスト（ユニットテストに含めるにしろ、より上位レベルのテストになるにせよ）として残す、と。レガシーコードをいじるときには、いきなり全部のテストを書くわけにもいかないので、変更/修正する箇所から段階的に追加していくことになるかと。

リリース済みバージョンと次回リリースの開発を同じコードラインで対応しようとするのではなく、保守用と継続開発用でコードラインを分割しましょう。 p.171

よい子のみんなは、きっとやっているよね ♡

メタ認知のヒント: Andy Hunt 「リファクタリング・ウェットウェア - 達人プログラマーの思考法と学習法」

転職するときに、以前の職場の上司からもらった本です。当時はピンとこなかったけれど、今読み直すと理解できるようになりました。同時に、この1年何をしてたんだという後悔も。まあ、後悔は毎日のようにしているので、慣れっこです。なんで、もう一度念入りにおしりを拭かなかったのだろう、とか。

格言とは、その状況に応じて臨機応変に解釈が可能な基本的な 原理・原則です。 (p.11)

レシピと格言とは異なるのもなのですが、混同されていることがあると思います。この本でも、疑わしければユニットテストしろ、というのをレシピと取るか、格言と取るかで、具体的な行動や判断基準が変わってくるとあります。

プロジェクトの終わる瞬間が知力のビークであり、開始時点ではもっとも低いということです。これでも、早い段階で決断を下すのが賢明な判断だと思えますか? (p.113)

アジャイルなソフトウェア開発は不確実な状態での作業を許容する方法論です。 最初のうちはプロジェクトの最終日が本当はいつになるのかわかりません。次の反復でどの機能が採用されているかは100%確実にはわかりません。反復が何回あるのかわかりません。でもそれでまったく問題ないのです。その不確実性に浸る心地よさを味わえるようになればよいのです。進んでゆく過程で徐々に答えが見つかり、最後にはすべての答えが出ています。 (p.114)

時間がたつほうが判断が正しくなり、時間が早いほうが残り時間が多くなります。そのトレードオフであると考えるといいのかも知れません。ういうモデルでプロジェクトを考えてみると、「アジャイルと規律」なんかで言われていることと一致するのかも。

最低限の時間を定期的に投資すると決めてしまうのです。[...] その時問すべてが等しく生産的になるとは限りませんが、定間的に予定に組み込むことで、長い目で見るとうまくいくでしょう。 (p.151)

長い目でみるとうまくいく、っていうのは、安心と自信を与えてくれる。おそれずにやっていこう。

しかし「最初からうまくいく」ことが大切なのでは なく、「最終的にうまくいった」ということが重要なのです。 (p.184)

これは斬新。いままで失敗は悪だと思い込んでいた。最終的にうまくいく過程で、失敗できるようリスクを最小化すればよいのだ。一発成功を狙うほうがはるかにリスクが高い。

と、まあ、Andy Hunt が書いているということもあって、最終的にはアジャイルな話になってきました。それでも、長期的な学習や、そのメタ認知の視点のヒントがありました。実践してうまくいったらものがあれば、また、どこかで書きます。

村上龍 / ラッフルズホテル

本棚を整理していたら、村上龍の「ラッフルズホテル」なる小説が出てきました。あーこれ読んでなかったわーと思って、読んでみたら、読んだことある本だった。後半まで気づきませんでした。