いまさらながら、FizzBuzz問題

日記

ちょっと前に話題になってた、FizzBuzz問題を何も参考にせずに、自分で書いてみたら、こんな単純なコードになった。

 use strict;
 use warnings;
 
 for(my $i = 1; $i <= 100; $i++){
 
     my $j=0;
     my $k=0;
 
     if($i % 3 eq 0){
         $j = 1;
     }
     if($i % 5 eq 0){
         $k = 1;
     }
 
     if($j && $k){
         print "Fizz Buzz\n";
     }elsif($j){
         print "Fizz\n";
     }elsif($k){
         print "Buzz\n";
     }else{
         print "$i\n";
     }
 }

よく考えたら、$j,kのフラグいらないやん…
この辺は、普段見ているプログラムの癖なのかもしれん。


で、ネットでちょっと見てみると、やはり洗練されたプログラムを
書いている人はたくさんいて、プロは違うなぁとも思ったり。


ただ、社内SE的な立場で言うと、あまりにも洗練されすぎた
プログラムは維持運用を考えると、遠慮してほしい。


あるシステムの開発や維持運用の場面で、そのプログラムを書いた人がいるときは、問題ないんだけど、
その人がいなくなったあとに、そのシステムに何か問題があって調べるときに、あまりにも洗練された
プログラムだと、ぱっとみただけで何がどうなっているのかが分からない場合もあるんだよね。


社内SEとして自分が考える、Betterなプログラムは

  • 無駄がある程度ない、誰が見ても分かるもの

じゃないかな。

もちろん、あまりにもアホなプログラムはご遠慮いただきたい。
（といっても、ベンダーさんからくる開発者さんで、
　「あなたたちは、それでお金もらってるんでしょう！」
　たまにいるんだよなぁ。）


そりゃ、考えに考えぬいて、
「メモリを＊＊M節約しました！」
「I/Oを**%減らせました！」
のは結構なんだけど、その結果、可読性が著しく下がるのであれば、俺は読みやすいほうを選ぶ。
このご時世、ハードの進化はすごいんで、その辺は割り切ってハードにお願いするのもありだと思う。


洗練されたプログラムよりも、ドキュメントが残っているほうが100倍助かるしね。


ただ、この考え方は、「技術者」という立場に立った場合はダメなのかもしれん。
この辺が悩みどころなんだよな。