「プログラマが体験するべき50の危険なこと」と「きのこ本」

「プログラマが体験するべき50の危険なこと」 - Togetterまとめ*1
- プログラマが体験するべきではない50の危険なこと - Life like a clown
- はてなブックマーク - Togetter - 「「プログラマが体験するべき50の危険なこと」」

あるあるネタです。よくある危険な体験談なので、共感を得られるのも当然だと思います。ですが、単に並べるだけでは苦笑やネガディブなネタになってしまい、何も改善されません。
笑って済ませるのは悪です。そんなの皆わかってるでしょうけど、改めて「そんなもの」にしてしまわないように意識して欲しいと思うのです。どこが危険であり、どう改善するべきか。また、なぜそのような事が行われるか。そして実際体験する事になった場合の対処等に展開できたらいいなと思っています。最終目標はこれらの多くを無くす事です。こんな事、体験させるべきじゃないんです。

発端

子どもが体験するべき50の危険なこと (Make: Japan Books) がTLに流れてきたので、とりあえず反応したのが発端です。

「プログラマが体験すべき50の危険なこと」

2011-05-12 12:14:51 via Echofon

当初思っていた以上の反応で、完全に他人のふんどしで相撲をとってる*2状態ですが、こういう情報の収集や増幅も需要や価値があるのかなーと、改めて考えさせられました。

以下ではいくつかをピックアップし、それの何が危険か、引き起こされる背景、遭遇時の対処、加えて関連するきのこを独断と偏見たっぷりの箇条書きでお送りします。きのこ本を片手に読めば一層楽しめるかもしれません*3。

プログラマが知るべき97のこと

作者: 和田卓人,Kevlin Henney,夏目大
出版社/メーカー: オライリージャパン
発売日: 2010/12/18
メディア: 単行本（ソフトカバー）
購入: 58人クリック: 2,107回
この商品を含むブログ (339件) を見る

「○○が正常に動作すること。って言う試験項目」

危険
- 試験項目として成立していないため、まともな試験にならない。
- 不具合を黙認する余地が生まれてしまう。
背景
- 試験項目を作る人が挙動を把握してない。
- 試験内容に対する確認箇所が多岐にわたり、試験項目数が指標値*4に収まらない場合の悪足掻き。
- 試験項目作成に十分な時間が無い。
- ただの手抜き。
対処
- 権限がない
  - せめて自分は作らない*5。
  - 可能ならば自分の担当分の試験項目は書き直す。
- 権限がある
  - レビューではじくべきです。
- 自動テストを書く*6。
関連きのこ
- 77 偶然の仕様ではなく本物の仕様のためにテストを書く
- 96 テストは正確に、具体的に

「仕様書なしのレガシー再構築」「システムの中身が不明な状態での改善、保守」

危険
- デスマがほぼ確定。
背景
- 仕様書を書くまでも無かった小規模システム（Excelマクロ等）が肥大化した。
- 仕様書は存在したが、度重なる改修により形骸化し破棄された。
- ただの手抜き。
対処
- 巻き込まれないように努力する。
- 解る範囲で仕様書を起こす。
- 可能ならば仕様化テスト*7を書く*8。
- 既存システムの文句を言いながら精神の安定を保つ*9。
関連（しそうでしない）きのこ*10
- 12 コードは設計である
- 60 真実を語るはコードのみ
- 67 コードを読む

「リリースアーカイブを毎回ある開発者のIDE上のGUIで手動で作っているプロジェクト」

危険
- 環境依存により、特定端末でしかビルドできない可能性がある。
- IDEのコンパイラを使用している可能性がある。
- 担当者が休んだらリリース出来ない。
背景
- リリースに対する認識の甘さ。
- 「動けば良い」と言う悪習。
- ただの手抜き。
対処
- 最低限ビルド専用マシンを用意する。
- ビルドスクリプトを書く。
- Jenkins等を導入する。
関連きのこ
- 42 コマンドラインツールを使う
- 51 プロジェクト自身にしゃべらせる
- 61 ビルドをおろそかにしない
- 75 面倒でも自動化できることは自動化する

「環境上の問題で、データ送信箇所をコメントアウトした状態で修正。」

危険
- 未テストでリリースされるため、本番トラブルを起こす可能性がある。
背景
- 何らかの理由により環境依存部分の切り離せていない。
- コメントを外せば動くと思っている。
対処
- 環境依存部分は切り離す。
  - 外部リソースとし、リリース時に自動的に取り込まれるようにビルドする。
関連きのこ
- 59 バイナリは常に1つ

「本番環境のJSPを稼働中に修正」「本番のソース直でいじってバグ修正」「直前までコード弄って現地でテスト」

危険
- コードが構成管理から外れるため、改修・保守が困難になる*11。
- ぶっつけ本番では何が起こるか判らない。
背景
- 即時対応を強要された。
- 運用フローが明確となっていない。もしくはザル。
- 単純に時間が不足している。
- ただの手抜き。
対処
- 本番コードを直接編集するような状況は避ける。
- テスト済み*12でなければ本番にリリース出来ない運用とする。
  - 日常よりテストおよびビルドにかかる時間を最小限に抑える必要がある。
- 理不尽に急かされた場合は「○○機能に影響を与える可能性が…」とか適当な事を言って危機感を煽る。
関連きのこ
- 20 すばやくデプロイ、こまめにデプロイ
- 30 そのコードに触れてはならない！
- 79 テストのないソフトウェア開発はあり得ない

「テストコードのないリファクタリング」

危険
- リファクタリングの正当性が保証できないため、バグを埋め込む可能性がある。
背景
- 「リファクタリング」を「コードの手直し」と誤認している。
対処
- 「それはリファクタリングでは無い」と常に主張する。
- 素直にテストを書く。
関連きのこ
- 06 リファクタリングの際に注意すべきこと

「コンフリクトしたソースコードを強制コミット」「SVNでのコミット合戦」

危険
- 「修正箇所の潰しあいは楽しいぜヤッホウ！」
- デグレの主因となる。
背景
- メンバーがバージョン管理システムを理解していない。
- コードがSRPに違反しまくっている。
対処
- バージョン管理システムの教育を行う。
- テストコードを書き、上書きによるデグレをいち早く検知する。
- 不吉な匂い*13を感じ取ったなら、早々にリファクタリングを行う。
関連きのこ
- 65 バージョン管理システムを有効に使う
- 73 単一責任原則

「コード汚いから1から書き直そう！！」

危険
- 高い確率で独り善がりです。
- 書き直した後が綺麗である保証がありません。
- システム全体の一貫性が取れなくなります。
  - スパゲティだったのがスパゲィとざるそばを混ぜた物になってしまいます。
- 自動テストがない場合は特にテスト工数が洒落になりません。
背景
- 汚いコードが悪いです。なので気持ちはわかります…。
対処
- 独断ではやらない。
- チームとして明確な指針を持って行う。
- やると決めたなら徹底的にやる。
- 現行機能が存在するわけなので、テストによるサポートが必須*14。

「本番機とテスト機を間違えて、ふざけたデータを登録してしまうこと。」

関連きのこ
- 25 見られて恥ずかしいデータは使わないこと

「デスマ」

危険
- 死にます。冗談抜きで…。
背景
- 原因はいくらでもあるのですが、挙げられている他の項目がそれだったりもします。
対処
- …。
関連きのこ
- 36 ハードワークは報われない

ほか

（気が向いたら追加します）

まとめ

認識の甘い管理者や他の技術者に「そこまでしなくても…」とか「そんなのいいよ」とか言われる事もあると思いますが、これらに安易に屈してはいけないと思います。それは顧客のためであり、自身のためでもあり、「しなくて良い」と言ってきた彼らのためにもなるはずです。ビジネスなので様々な事と天秤にかけられることはありますが、ツールによるサポートや技術の裏付けを正しく運用*15できれば、彼らの言い分を凌駕出来る筈です*16。