プログラムをいじるだけがチューニングではない

ソースコードをこねくり回すのが本職なもので、ついついそちらに目が向いてしまいます。
ここのループを最適化して…とか、メモリにキャッシュしてとか。
それはそれで良い方法なのですが、他にも見所はあります。
例えば、飛び交うデータの流量を減らすとか。
(例:何でも SELECT * なダメダメDAOを見直す)
例えば特定の処理を別プロセスにしてみるとか。
(だけどデバックとか大変そう…)
例えばデータ量の多いテーブルの一部をジャーナルテーブルに逃がすとか。
(テーブルの絶対件数が減るので、I/O負荷が減る。)
例えば物理メモリが足りないのでスワップアウトしているとか。
(とは言っても、最近は調べる工数より購入コストの方が安い。)
かようにイロイロな手が考えられます。
それらを込みで、「チューニング」です。

気づくこと、観察すること

先日何気なくテレビを見ていたらやっていた番組で、「NHK高校講座 理科総合A・B」というのをやっていました。
えーっ、理科は 物理、生物、化学、地学 じゃないの?という突っ込みはともかく、非常に為になることを言っていました。
「科学の目で見てみよう」という回だったのですが、その中で、「気づくこと、観察すること」というのが重要だという内容でした。
これはデバックにも通じる言葉で、
「気づく」:この動作がおかしいということに気づく、再現条件に気づく、おかしなコードに気づく
「観察する」:動作を観察する、再現方法を観察する、ソースコードを観察する(特にステップ実行で)
と、いう部分がデバックの多くを占めます。
その上で、解決として、ソースコードを直したり…というコトに至る訳です。
その過程を飛ばすと、得てして惨事が起きます-多くの場合、新たなバグが誘発されます-で、「終わらないデバック」となります。
そうならないための視点…そういった意味で、大変勉強になった番組でした。
参考:番組のサイトはコチラ

パフォーマンスチューニング-測定に始まり、測定に終わる

マクラはパフォーマンスチューニングの話です。
パフォーマンスが悪いので、何とかしなければいけないというコトになりました。さて、何処から手を付けますか?
機能ベースで「ここ」はわかっても、多くの場合、その機能は多くの部品(クラスだったりDBだったりあれやこれや)の集合体ですので、その「どこ」までは、わかっていないのが普通です。
そういう時、最初にやるべきことは、「そのうちのどこか?」を確かめること、そして、「本当にそこか?」を確かめることです。
デバック実行でもトレースでも、区間タイムを記録して、その範囲を次第に狭めていけば、原因箇所はおのずと明らかになるはずです。
で、結果として手を入れたときも、同じように区間タイムを測定すれば、「確かにこれだけ早くなりました/効率的になりました」と、数値を上げて説明できるようにできます。
数値を上げての説明は、「だいたいこれくらい早くなった」と言う場合と比べて、説得力は圧倒的に違います。
そういうわけで、パフォーマンスチューニングは、「測定に始まり、測定に終わる」のです。

見なかったことにするのが一番悪い

ネタ元
【Yahoo!ニュース】<エレベーター事故>ブレーキ不良放置 保守業者
どうしたらいいかわからないからって、そのままにして良い訳はないでしょう。ちゃんと上司なりなんなりに、報告・連絡・相談して、しかるべき手を打つものでしょう。
こっちの業界でも同じで、「なんか動きが怪しい」とか「ビミョー」とか、イロイロあると思います。(目先の)仕事が増えるのでナイナイしたくなる気はわかりますが(私もやったことはあります-懺悔)、ちゃんとやるべきことはやっておいたほうが、後々のためにも宜しいかと思います。

改修時に必要な視点

バグ取りでも機能追加でも何でも良いですが、改修する際に「大体ここ!」というアタリはつくものです。
でもって、そこだけを見て、「えいっ!」って直して…
あのぉ…他への影響度は見なくて良いですか?
思わぬところに影響を及ぼして、聞くも涙、語るも涙の虫取り行脚というのはよくある話です。
まぁ、そうならないように初手から旨くカプセル化でもスコープでもなんでも、局所化しておくのが最善手なのですが、世の中ままならないものですから。
…と、言うことをサッカーを見ながら考えていたわけです。「そこしか見ない」改修って、ボールに10人*2が群がるみたいなもんだな…という感じで。

直すための情報は必要

エラーが出ました。直さなければいけません。
でも、何がどうなってエラーになったのかはわかりません。
こんな手探り状態では、直せるものも直せません。
仮に直しても「ハズレ」かも知れません。
悲惨な二次災害が発生するかもしれません。
これを繰り返していると、「もういい加減にしてくれ」感が双方に募り、感情的にも非常に宜しくない状態となります。
医者に行くときも、「ここが痛い」とか言いますよね。問診にも答えますよね。それと同じことです。

動かす、そして、正しくする

・動かす
仕様を満たすこと。
・正しくする
仕様を満たした状態を維持しつつ、より良い状態に変化させること。
納期に追われていると、「動かす」の段階で「できた」ことにしてしまうことがあります。それどころか、『もうそれでいいよ』と、強制終了させられることがあります。
ただ単に「動かす」状態のものは、-特に納期に追われている場合-良いものではないと言うのがほとんどの場合です。後から見ると、非常に汚いソースになっていることが往々にしてあります…どう考えても冗長な処理とか…。
小学校の作文の時間に言われましたよね。「推敲しなさい」って。
テストも提出前に見直せって言われましたよね。
ソースも同じです。
ただ単に書き散らしただけで「できた」とは言いたくありません。

再現させることから始まる

テストなりなんなりでバグが出ました。
でもって、バグ票を書いて、開発側にまわされるわけです。
そこで必要なのは再現できる情報です。
データもそうですし、手順もそうです。
どのデータかがわからなければ、発掘しなければいけません。消してしまうなどは言語道断です。
手順もなしに「バグです」なんていうのも、それはガキの言い草です。何をどうしてどうやったかの推理が必要になります。
そういう情報があれば、何がどうなったのかの追求が容易になり、言いたいことも伝わり、いい事尽くめです。
さらに言えば、そのようなバグ票は受け取る側から有難がられます。
バグ票を書く技術というのも、実は立派なスキルだと思うわけです。

緊急時こそ「マニュアル通り」

まずはコチラ。日経コンピュータの記事「東証ダウン、運用体制の不備が根本原因
ギョーカイの話題をさらった、東証事件の顛末です。
念の為に申し上げておきますが、別に「お役所仕事」と推奨しようというわけではありません。
ここで言いたいのは、「緊急時にはミスが起こりがちである。だからこそ、マニュアルに従え」ということです。
一度は経験したことがあると思います。焦って作業した結果、台無しにしてしまったとか、より悪化させてしまったとか。
そうなってしまっては元も子もありません。
急ぎのときこそ落ち着いて、マニュアルを参照しながらコトに当たる-それくらいのゆとりがないと、二次災害が発生します。
とくにこの仕事、一文字間違えただけでオオゴトですから。
-プレッシャーをかけられても思考は早くならない。
デッドライン―ソフト開発を成功に導く101の法則

バグ票には期待する結果を含めること

テスト段階でバグが見つかり、開発側に戻すことはよくある話です。
そのときによく「バグ票」と呼ばれる文書を発行することがあります。
このバグ票ですが、往々にして情報が不足することがあります。
少なくとも…
・再現手順
・期待する結果
が含まれていなければいけません。
ただ単に「おかしい」というのでは、直す側にはただ単に苛立つだけの価値の無い情報です。
さらに、テスト担当者に「じゃぁどうすればいいんだよ!」と聞きに行く手間暇がかかります。
そのほか、二度手間三度手間…
きちんとした情報の含まれていないバグ票はロクなことになりません。
優れたバグ票は、少なくともデバック担当者がテスト担当者に聞きに行く必要が無く、かつ、記録文書としての用を成すものである必要があると思います。