2014-03-28

下請け底辺泥臭Webアプリデバッグ手法

次々とやってくるさまざまな環境で色々がんばる人のためのノウハウを集めてみよう。

必ずしも綺麗な環境で開発できる人ばかりじゃない。スパゲッティを手渡されラーメンを作れといわれる。

所詮下請けなので、そもそもこうした方がいいよとか軌道修正すらできない環境で足掻くために何ができるのか。

今回はみんな大好きPHPを使った場合の話をしましょう。

1. なんだよこれどこの処理通ってんだよわけわかんねぇよ。

朝はCakePHP、昼はsymfony、右向きゃ独自FW、左向きゃ素php

こんなこと、よくありますよね!

いろんなFWを使ってるとFW固有の機能とかもう何がなんだかわけがからなくなります

FW機能を使ってデバッグなんてやってられません。一番信頼できるデバッグ方法とはなんでしょう。

・・・うprintデバッグです!!!printデバッグこそ神!PHPならprint_rを使おう。

ただし出力バッファ捕獲したりするFWもあったりするのでprintだけだとどこの処理通ってるかわけわからんときがあります

そんなときはこれ!

exit

exitだけは何者にも犯せない最強の関数言語構造)なので確実に処理がとまってくれます。なのでわけわからんことになったら真っ先にexitしましょう。

2. ローカル環境作りたい?むぐぐこの定数とか関数とかローカルじゃうごかねぇよ

世の中には開発者PC環境ローカル環境)を作るのが困難な場合があります。例えば設置できたはいいが、ローカルでこの関数が動かないor動いたらまずいだとか

この定数はローカルだと微妙、書き換えたいとか。

こんなこと、よくありますよね!

そんなとき僕達がよくやる対策としてはソースコードを直接書き換えることですね!呼ばれたくない関数は中身をコメントアウトしたり、定数はローカル用の値に書き換えたりするわけです。

しかしこのやり方は少し問題があるのです。

例えばSVN等を使っている場合、常にこれらのファイルが変更状態のままになってしまます。間違えてコミットしちゃった!なんてこともあります

そして更にそのファイルに何か変更があった場合とても面倒です。関数コメントアウトを外し、定数は本番環境用に戻してからコミットする、なんてことになります。まぁ確実にいつか人的ミスが入るでしょう。

そこで僕が推奨するのはファイルを直接書き換えずに書き換えろ。ということです。

まりrunkitを利用するのです。

通常PHP関数や定数などを動的に上書きすることはできませんが、runkitを使えばそれができてしまうのです。このようなローカル環境を無理やり構築したい場合にはとても使える機能です。

もちろん本番環境においてrunkitを使うのはご法度だと思います伝家の宝刀馬鹿と鋏は使いよう、です。

3. 今何が最新なの?ねぇねぇ?もう僕わかんない

こんな経験はありませんか?

「ここを改修して欲しい」

「わかりました、じゃあSVNをUPDATEしてから改修しますね。」

「いや、今はステージング環境にあるファイルが最新なのでそこからダウンロードしてから作業してほしい」

「あ、そうなんですか、じゃあステージングから持ってきて対応します」

「改修完了しました。コミットしてステージングにアップします」

「動作問題無いので次は本番環境にアップしますね」

「あれ、なんか本番の動作がおかしい!デグレードしてますデグレードしてます!」

「どうやら本番環境のみに誰かがファイル書き換えていた模様」

「誰だrsync使わずアップしたやつわッ」

コミットもされてねぇ!」

「競合!競合!」

「うわああああああ、今何が最新なの?ねぇねぇ?もう僕わかんない。」

増税前にdiffすれば良かった」

こんなこと、よくありますよね!

この後の担当者の作業はこうです。

ローカル環境ファイルSVNdiffステージング環境diff。本番環境diff

改修対象ファイルが複数ある場合diff作業の大変さと言ったらもう筆舌に尽くし難いものとなります

僕は思いました。ローカル環境ファイルと、SVNステージング環境と、本番環境diffワンコマンドでさっとできたらどれだけ楽か・・・

そして作りました。それができるdiffコマンドを。

もちろん探せばそういったツールを見つけることは可能だとはおもいますが、探すのが面倒だったので自作しました。

そのツールをここに晒す事もできなくはないですが、この余白はそれを書くには狭すぎるので今回はそういうアプローチがあるということだけを書いて終了します。

とりあえず僕が自作したのはローカル(windows)とhttp(SVN)とftpssh対応した相互diffツールです。全ての環境の組み合わせでdiffをして差分を表示したり、特定環境だけをdiffしたりできるので開発効率アップです。

何より気軽にdiffしようという気が起きます

4. 見なかったことにしよう

タイトルで言ってしまった感がありますが、下請けで改修作業をしていると既知バグ発見してしまうことがあります

これは非常に難しい問題です。もう完全にクライアント次第としかいいようがないんですが、クライアントに報告すべきかしないべきかは慎重に考える必要があります

バグを報告するとちょちょっと直してよ、とかいクライアントもいますし、何よりクリティカルバグ場合見積もりしてくれと言われたとしてもとてもじゃないけど責任を請け負いたくない場合もあります

なので見なかったことにする。

む、ちょっと眩暈が。最近寝てなかったし。とか言いながら缶コーヒーでも飲んで一服しましょう。

するとどうでしょう、さっきまでバグを見過ごさないのはプログラマ矜持だとかなんとか言ってたのにあら不思議、とりあえず今改修対象のところだけ直そう。となります

・・・こんなこと、よくあります、よね?とほほ。

5. うん。もうない。

20個くらい書くつもりで見切り発車してみたものの、もうない。泥臭い作業にノウハウなんてないのだ。

所詮泥は泥。ドロドロ。細かいコードの書き方まで言い出せばいくらでもあるけど「些末なコードレビュー」の話したところで泥で足掻いてる人にとってはなんら救済にならないし別に必要ないよね。

さてここからは他にも泥臭い作業をしている人たちでノウハウを構築しようではないか。6番目以降を書く同志達を僕は待ち望んでいるッ!

記事への反応(ブックマークコメント)

ログイン ユーザー登録
ようこそ ゲスト さん