こんにちは
システムチーム・マネージャー / プログラマーのAです。
今回は、プログラマーに向けた記事になります。
不具合を防止するための、考え方を共有します。
厳密に書くとドキュメント３０ページ分くらいになるような、
技術寄りの、ハイレベルな内容になると思います。
質問がある場合は、ぜひ、直接聞いてください。
１）出来るだけコードを書かない。
極端な表現になりますが、
コードを一切書かなければ、不具合は、絶対に発生しません。
部下のコードレビューをしていると
「とにかく書いて何とかする」意図が強く伝わってきます。
理解・共感はしますが、基本的に間違いです。
「出来るだけコードを書かない」が正解です。
具体的にどうするか は
実際のコードレビュー時に説明するので、ココでは割愛しますが、、
重要な事は
「何とかして書く量を減らせないか？」を常に考えること。
書いたコード量でプログラマーは評価はされません。
コードを書くことが目的にならないよう、自制してください。
２）コードは「変更」ではなく「追加」する。
また、極端な表現になりますが
既存のコードを「変更」しなければ、
既存の機能での不具合は、出ません。
機能追加があったとしても、
既存のコードを「変更」せず、
新規コードを「追加」する方法を探すべきです。
簡単な例を用意しました。
プログラマーは必ず一読してください。
https://syde.jp/w/wp-content/uploads/__tmp/20230609.abe.1.pdf
上記例であれば、
「変更」する場合の、不具合リスクは「３つ」。
「追加」する場合は、不具合リスクは「１つ」。
追加するほうが、当然、安全です。
まとめます。
重要な事は
「既存のコードを変えない方法は無いか？」を考えること。
既存のコードを触ることに、
強い抵抗を持ってほしいと思っています。
３）テストは、何をテストするか決めてからやる。
テストをしている部下を見ていると、
そのテスト、何をゴールにしてるの？と思うときがあります。
何となくブラウザを操作して、
バグっ「ぽい」ものを探している感じ？
最悪、同じ意味の動作確認をぐるぐる繰り返してる・・・
だから、
ある端末や、画面サイズでの動作確認 が漏れたり、
ある条件下での動作確認 が漏れたりします。
ぼんやりと、テストしても時間の無駄です。
重要なことは、
「何と何と何を見ればいいのか？」を言語化したうえで、テストすること。
見るべき項目がリストアップ出来ないなら、相談してください。
今回は３点ほど紹介しました。
書いていて、やっぱり難しいなと思いました。
ただ
この難しさはウチに限った特殊な話ではなく
一般的な、プログラミング開発の難しさになります。
「開放閉鎖の原則」「テストケース」などで検索すると、似た話が沢山出ます。
直近の状況を見るに、
開発者（チーム）のレベルを
取り扱うタスクのレベルに近づける必要性を感じています。
極端に厳しくするつもりはないので
変に不安がらないでは欲しいですが、自分の素直な今の心境です。
