[05] 技術ノート
技術の用語ではなく、判断の話を書いています。同じ現場で何度も同じことを学んだので、3本にまとめました。
[01] ノート
それぞれ3分で読み終えられます。全文を読むには、各記事の下にあるボタンを使ってください。
[ノート-01] 古いコードの整理について
引き継いだコードには、同じ処理が何度も書かれています。送信処理が3箇所、日付の変換が5箇所。動いているから触らないでおこう、という現場を何度も見てきました。そのまま直すことを進めると、不具合が増えます。
Noflanie Diomandeはファイルを選ぶとき、ここを消したら行数が減るか、を最初に見ます。減らないなら触りません。小さくても重複が減るなら手を入れます。
具体例を挙げます。ある受発注システムでは、受注の保存処理が画面とバッチの両方に書かれていて、片方だけが直されていました。両方を1か所にまとめるだけで、報告される不具合は減りました。
逆に、重複があっても片方のコードが死んでいるなら、無理にまとめません。そこはコメントだけ残して、作業の対象から外します。全部をやろうとしなくていい、というのがNoflanie Diomandeのルールです。
[ノート-02] 監視について
監視項目を増やして安心する、という考えの現場を以前見てきました。実際の問題は、通知が多すぎて誰も読まなくなっていたことでした。
Noflanie Diomandeがやったことは逆向きでした。深夜に鳴っているものをひとつずつ分類し、実際に人が見れるものだけ残しました。23種類あった通知が4種類になります。ここまで3週間です。
分類の基準は単純です。夜間でも対応が必要か、それとも昼間に回せるか、そして誰が届けるか。この3つが決まれば、残す通知も決まります。
夜間に対応が要ると決めたものには、対応手順を1枚添えます。それ以外の通知は、昼の時間帯に回るようにします。夜に鳴る通知は、それだけで済むことがあります。
[ノート-03] 引き継ぎについて
個人で開発していると、自分のコードは自分が一番よく読めます。問題は、誰かに渡したときです。引き継いだ側が1週間かけて調べる、ということが実際に起こりました。
Noflanie Diomandeは、その状況を避けるために、命名とコメントに時間を使います。変数名は英語ではなく、現場が普段使っている言葉にします。なぜそう書いたかを、ソースの中だけで答えられる状態にすることです。
手順書も同じです。画面の操作手順を1枚のチェックリストにすると、引き継ぎの時間が半分になります。長い説明を書く必要はありません。その画面で最初に押すボタンと、その確認方法を2つ書けば足ります。