社内SEの徒然なる日記

読みやすいソースってどんなんだろ?

よっ読めない!

ユーザーから、とある処理が異常終了するという連絡を受けて、原因を調べていたのですが、障害の原因となったソースが非常に読みにくくて、無駄に手間取ってしまいました。

悪いことに、他システムと連携するための処理で、1時間以内に何とかしないと大変な問題だってことで、ユーザーが後ろに立って急かしてくる状態だったので、私自身が焦ってた事もありますけどね。

大声上げて私を責めても、問題は解決しないよ...

ソースのサンプル

頭を抱えたのは、こんな書き方をされたからです。

private boolean smart(String a, String b) {

// 1.引数a、bの共に1であればTrue
boolean chkFlag = a.equals("1") && b.equals("1");

// 2.引数aが2ならばTrue
boolean aFlag = a.equals("2");

// 3.日付作成
String day = chkFlag || aFlag?"30":"31";

// 4.作成された日付が"30"ならTrue
return day.equals("30");
}


実際のソースは見せられないので、適当に書いてみたのが上記のソースです。
なんというか、非常に気に入らないです。

1.と2.で、判定用フラグへの設定値に、別の処理の結果を直接突っ込んでいる。

3.で三項演算子を使っている

4.で関数の戻値に、別の処理の結果を直接突っ込んでいる。

こういうソースを書く人って「スマートでしょ」とか思ってるのかなぁ。

もちろん、追えますよ

もちろん、追えますよ。実際に追い切って、対応策まで出してますしね。
しかし、多少冗長であったとしてもif文を使ってくれていれば、もっと手早く対応できたわけですよ。

許される場合とダメな場合

気に入らないと書いておいてなんですけど、別に私は上記のような書き方を、一概に否定してる訳ではありません。
システムの特性や、チームの技術レベルなどによっては、使ってもいいとは思っています。

例えば、「多少のバグがあっても許される」「寿命が数ヶ月から数年」「開発速度が最優先で今後の改修予定もない」なんて条件であれば、効率優先ってことで、書きやすい手法をとればよいと思います。

反対に、社会インフラを支えるような、止まる事が許されない類のシステムの場合、求められるのは安定性ですので、あえて冗長だが読みやすい書き方をするべきだと思います。
まぁ、常に優秀な技術者が確保できるっていうのなら、難しく書いても良いでしょうけどね。

他には、立場上、口に出来ないとかですかね?IT系でシステム開発が本業っていう会社の技術者が「三項演算子は分りずらいので使いません」とか言い出したら、「その程度で難しいと思う程度の技術力しかないのか?」とか思っちゃいますし。

後書き

ちなみに、障害の原因自体は、日付計算を行うメソッドのパラメータに、存在しない日付を渡したという、実に馬鹿らしいものでした。

パラメータとして渡す日付は、年月は画面から入力、日をマスタから持ってきて作成するのですが、作成された日付が「****/11/31」のように月末日を超えた場合は「****/11/30」のように補正する処理が実装されています。

はい、ここまでは良いんですよ。
問題はこのソースを書いた人が、マスタから取得した「日」が"30"以下の場合は、補正処理を実行しなくても良いなんてアホな考えを持っていた事です。

・・・はい、この障害は2月に発生しました。

もうね!三項演算子がどうとか、スマートな書き方が云々とか、それ以前の問題ですよね。
スポンサードリンク

PageTop

コメント


管理者にだけ表示を許可する