日々常々

ふつうのプログラマがあたりまえにしたいこと。

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

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

発端

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

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

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

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

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

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

  • 危険
    • 試験項目として成立していないため、まともな試験にならない。
    • 不具合を黙認する余地が生まれてしまう。
  • 背景
    • 試験項目を作る人が挙動を把握してない。
    • 試験内容に対する確認箇所が多岐にわたり、試験項目数が指標値*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 テストのないソフトウェア開発はあり得ない

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

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

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

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

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

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

「デスマ」

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

ほか

(気が向いたら追加します)

まとめ

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

  • 関連きのこ
    • 01 分別のある行動
    • 24 変更を恐れない
    • 52 「その場しのぎ」が長生きしてしまう
    • 64 プロのプログラマとは?
    • 91 良いプログラマになるには

*1:時系列ではなく、「(ネタ + 反応) * n + 感想」の順に並べてます。そのほうが読みやすいと思ったので。あと、体験は赤文字、感想は緑文字でデコりました。

*2:私自身のネタは一つも無かったりします。

*3:予想以上に対応するものが多くて驚きました。

*4:規模(ステップ数)によって決められたりする悪習の一つです。

*5:既存の試験項目としてこれらが横行している現状、一担当者が容易に全体を引っくり返せるとは思えません。

*6:そもそも自動テストであればこんな試験項目にはなりませ……assert無しのテストが実在するだけになんとも言えませんか。

*7:レガシーコード改善ガイド (Object Oriented SELECTION)

*8:テストのためのコードの変更は許されずに適切なテストを書けない可能性も高い。

*9:幸い駄目な事は誰もが理解出来る――ユーザすら理解している場合もある――ので、愚痴も聞き入れられやすいはず。

*10:関連しそうなの見当たらなかった…

*11:一時的だから問題なしと思われるかもしれませんが、この運用を続けていると必ずどこかで漏れます。

*12:最低でも動作検証(疎通)は済んでいるもの。

*13:リファクタリング―プログラムの体質改善テクニック (Object Technology Series)の「巨大なクラス」、「長すぎるメソッド」など。

*14:無ければ仕様化テストから行う。

*15:なんて言ってる私も勉強中であり、常に押し切れる訳ではありません。

*16:感情論で押し切られる事もありますが、それは完全に力関係なのでプログラマとか関係ありません…。