こんにちは
システムチーム プログラマー / マネージャー のAです。
数年前と比べると
プログラマーの数が増え、行うタスクは多くなりました。
デキテルに関しては成熟が進み、
搭載する機能のレベルは、上がりつつあります。
コード量も数年前と比べると、だいぶ増えました。
そして、発生する「不具合」の数も増えています。
少し強い言い方で書きますが
自分はとにかく「不具合」が嫌いです。
言葉の中で一番嫌いかもしれないです。
自分はその前提で、日常のタスクを進めているので、
いくつか、有用なノウハウを持っています。
今回は、
それらノウハウのうち、「カンタンな」モノを残します。
プログラマーは、しっかり読んでください。
動作確認のゴールを決める
部下を見ていると
「その動作確認、何をもってOKとしているの？」
と思うことがよくあります。
根拠のない時間を確保して、
適当にページを回る
という動作確認をしていませんか？
だとしたら、すぐにやめましょう。
まずは
「〇〇と××と△△を見れば、OK」という感じで、
最初に動作確認のゴールを定義してください。
もし難しいのであれば、
正しいゴールを設定できなくてもいいので、
必ず、何かしらのゴールを設定して、動作を確認してください。
少しずつ上手になるので。
なるべく、コードを「変更」せずに「追加」する。
ムズカシイ用語でいうと
「解放閉鎖の原則」と言ったりします。
既存のコードを「変更」するから
既存の機能に「不具合」が出る。
既存のコードを、「変更」しなければ
既存の機能に「不具合」は発生し得ない。
という、論理です。
変更していない個所には、絶対に、不具合は発生しません。
この原則に限った話ではないですが、
「どうやって、”不具合が絶対に発生し得ない状況” を作るか」を
考えることが、不具合防止に効果的です。
究極的な話ですが、
コードを一切変更しなければ、絶対に不具合は発生しませんよね？
ネスト・関数・クラス・ファイルの１個１個を短くする
これもムズカシイ用語でいうと
「単一責任原則」といったりします。
１個１個のモノをカンタンにすることで、
パッと見たときにすぐ分かるようにしましょう、という話です。
個人的には
数百行を超えたメソッドを
「正しく」記憶することは不可能だと思っています。
いいとこ１００行くらいが、自分は限界です。
それともう１つ。
１個のモノに、色々詰め込むと、
「正体を想定しやすい名前」が付けられなくなります。
「十徳ナイフ」がいい例です。
名前から、中身を正しく想定できますか？
この数年間
「想定外でした…」とよく聞いてきましたが、
「想定外」が出るのは、
「名前」から「想定」できなかったから、が理由の１つです。
「check」と書いていたけど、「確認」以外も色々してた。
「add」と書いていたけど、追加「しない」場合もあった。
「sendMail」と書いていたけど、「DBに追加」してた。
こういう、名前と正体の不整合から、不具合は良く起きます。
今回はできるだけ
カンタンで、キャッチ―に書いたつもりだったんですが
結局、難しくなってしまった気がします。
こういう話であれば
いくらでも話せることはあると思うので、
なにか気になる点があれば、聞いてもらえればと思います。
