去年12月から4月末までの5ヵ月間システムの常駐案件で働いていた。
一人でやる時と違うことが多々あり、今後も常駐案件をする可能性が100％くらいあるので今後に生かすためにも、過去の案件で学んだこと、気付いたことなどをつらつらと書いていく。
■ウォーターフロー開発
常駐案件の開発フローって高い確率でこのウォーターフロー開発手法だと思うのね。具体的に言うと、要件定義があって、基本設計があって、詳細設計があって、製造(コーディング)があって、単体テストがあって、内部テストがあって、結合テストがあって、運用テストがあって・・、その先は知らないし、知らなくてもいいかもね。
この一連の流れと、その内容を理解しておくべきだろうね。
■関心の分離
画面設計においては、設計者とお客さんとのやりとりとか、予算の都合で１画面に５画面くらいの機能が凝縮されてしまう場合があって、高い確率で炎上するのね。ていうかしたのね。
こういう画面のコーディングを任された時に、どう対応するかっていうのは大事かも。クラスを分けて、機能単位にファイルを分割するとか、バリデーション専用のクラスを作って別ファイルにするとか、共通関数を作るとか。
■自分の進捗を把握し、常に報告できるネタを用意しておくこと
特に進捗が悪い場合や、期日が迫っている場合には、しっかりと自分の担当している画面のコーディング状況を把握しておく必要がある。
これが結構難しい。というのは、進捗を把握するのにも時間がかかって、コーディングが遅くなってしまうから。けど、これはやらないとダメなんだろうね。
「急がば回れ」ってやつかな。
■進捗が悪い場合は、できればこまめに、自分から進捗報告を行うべし
口頭でもメールでもよいが、上長に進捗報告をするようにすべき。順調でない時ほど、自分から、こまめに、いわゆる「ホウ(報告)・レン(連絡)・ソウ(相談)」をすべきだった。これは正直どう訓練したらいいかが分からない。
■画面確認も含めて実装完了とせよ
コーディング完了が決められた期日に間に合わないとしても、画面を確認しないままコードだけを書いて、「コーディング完了しました～」って言うのは、かなり良くないことらしい。(当たり前？)。きちんと画面確認を行って、きちんと動くことを確認できて、はじめてコーディング完了、実装完了と進捗報告してよいわけである。
■Oracleをあまり知らなければ、Oracle案件は避けるべきかも
SQL文とかほぼほぼMySQLと同じなんだけど、意外と面倒なので、知らないならやめといたほうがいいかも。
■MySQLについての理解を深めるべし
オライリー本を買うとかドキュメントを読むなどしてMySQLの理解をさらに深めた方が良さそう。例えばCASE WHENとかの構文とか今いち理解できていないので、複雑なSQLとかを理解した方がよさそう。トランザクション、ロールバックとかね。
■POST値は必ず検証する
例えばPOST値に1～5の数字しか入ってこない場合は以下のようにチェックするべし。
if( !in_array($_POST['id']), [1,2,3,4] ){
// エラー画面へ遷移させるなど
}
■if ～ elseif ～ else
場合によるが、if elseifだけの場合はelseも必要かどうかを確認する。まぁ、よく分かっていないけど長いことC言語やってた人がここ指摘してた。
■==と===
例えば
$value = 0;
として、
if($value == false){
// 条件に入る
}
if($value === false){
// 条件に入らない
}
if($value == null){
// 条件に入る
}
if($value === null){
// 条件に入らない
}
==は緩めの一致で、===は厳格にデータ型まで一致していないとtrueにならない。場合によっては==でもいい場合もあるし、場合によっては===じゃないと危険な場合もある。基本的には===を使った方が安全な気がする。
■関数実行時は戻り値を変数で受けてfalseなどの場合はエラー処理
関数は多くの場合戻り値を返す。その戻り値を変数でうけるべし。
$str = getSomeString( $val );
if( $str === false ){
// エラー処理
}
// 以下は文字列が返って来る前提の処理なので、falseが返るとあまりよろしくない。
$string = '結果は' . $str . 'でした！';
■テストについての理解
例えば、テスト駆動開発の概要とか、PHPUnitの使い方とか、テストに関する理解をある程度持った方がいいのかなって思った。案件で実際にPHPUnitを使わないとしても、どういう風にテストを行うものなのかっていうのは分かっておいた方がよさそう。
