思考整理
■書いてはいけないソースコード
負債になるソースコードというものが存在します。
ソースコードを書いたらバグが出ます。
極端ソースコードを書かなければバグは増えません。
バグを修正するソースコードによってもバグが発生します。
テストはするのですが、実行できることは無限ではないので、
どうしてもテストから漏れる部分はあります。
また、テストしても結果を見間違えることもあります。人間なので。
熟練のプログラマーのほうが新人よりもバグを発生させる確率は低いですが、それでも必ずバグを作ります。
とはいっても、ソースコードを書かないことにはプログラムは動きませんし、新しい機能は出来ません。
そのため、開発者はバグ覚悟でソースコードを書きます。
もちろんバグだけではないです。
ソースコード自体を書く時間もかかります。
そしてたぶんこれ結構観点から漏れがちなのですが、一度書いたプログラムは保守する必要があります。
なので開発者は何かプログラムを書くときに、
・本当にその実装しようとしているものにメリットがあるか
・ソースコードはなるべく少ない量で書かれているか
ということを意識する必要があります。
助長なソースコードは基本的に悪です。
コードのコピペはもってのほかです(オブジェクト指向言語を浮かべながら書いています)。
また読みづらいからといって、安易なリファクタリングは悪です。
手を加えた瞬間バグるリスクがあります。
1行でも手を加えたらテストが必要です。
今まで動いていたものを動かなくする＋テスト工数がかかるリスクがあっても修正したほうがいいですか？と常に問いかけましょう。
一度書いてしまったコードは消すことすら難しくなってしまいます。
もしそのコードをほかのところで使っていたらどうでしょう。消した瞬間たちまち動かなくなってしまいます。
Javaの話ですが、では呼び出し箇所をEclipseで特定すればいいじゃないとなるかもしれませんが、リフレクションを利用されていた場合呼び出し元では出てきません。
また、コード内をgrep検索をかけたとしてもたとえばクラスパスをDBや外部のプロパティファイル等に保持していた場合、クラスを検索しただけでは分かりません。
そのため、消すに消せなくなってしまいます。
もしそれが本当は不要なソースコードであっても保守し続けなければなりません。
そのため、自分ではソースコードはなるべく書かないほうがいいです
まず検討すべきは先人の知恵です。
世の中のライブラリーを使いましょう。
たとえばStringの文字チェックとか自前で書くのではなく、StringUtils.isEmpty()とかisBlank()とか使えば無駄な判定ロジックを自分で書く必要は無いです。
もしくはもともとあるテスト済みのロジックを流用してしまえばそのロジックについてはテストする必要がありません。
どうしても書かなければならなくなったときは影響範囲は最小限にどうやれば抑えられるかを必死に考えましょう。
新しくついた機能や、修正した箇所近辺のみでバグがでるのはまぁ許される場合が多いです。
「はじめての機能だしまぁ、、、」みたいな
でもいままでちゃんと動いていたものがまき沿いで新しくついた機能によってバグるのは許されない場合が多いです。
ここについてはちゃんと影響範囲を精査した上で、自爆テロにならないようにしましょう。
■ググって満足するのは悪
コレも結構思うことです。
たとえば
「Stringの文字列を結合するときに、Stringの+の文字列結合とStringBuilderやStringBufferでの文字列結合はどれが早いの？」
とか
「executeUpdateとaddBatchしてからの実行、いくつも同時に行う場合どっちが早いの？」
とか
こういった事はググればいろいろと出てきますが、やっぱり自分でソースコードを書いて検証するのがいいと思います。
DB絡んでくるとデータ件数とかテーブルの条件とかオプティマイザ的なものも関連してくるでしょうし、メソッドの実行速度もJavaのバージョンで変わってくるかも(？)知れません。
で、もし確認した結果が間違っていたとしても、自分で実際にやってみるとほかにいろいろな周辺知識も実体験をもって確認できるので副次的な情報も得られます。
確認・検証もはじめは時間かかってしまいますが、慣れればさらっと出来ますしね。
こういったコードはどんどん書くといいと思います。
コメント