目次
久々に忙しかったのです
仕事で、超忙しい数週間でした。
ブログを書く暇もないくらいってのは、ほんと、超ーー久々です。
作った本人がいなくなった既存のソースを解析して仕様変更とバグ修正をする。
そんな仕事だったので、嫌な予感はあったのですけどね。
いざ引き受けてみたら、関数ひとつで数千行なんてのがあったり、複雑な条件分岐（IF文やSwitch case）が迷路のようにネストしてたり・・なかなかの難物でした。
まあ。
頑張って、なんとか修正を終わらせて本番稼働にこぎつけることはできたんですけど、まさに、七転八倒の綱渡りみたいな日々を過ごさせてもらいました（笑）。
毎日、脳みそが疲れて、板みたいになって、もう考えられない・・から仕事を終える。
そんな感じ。
そんなときは、ついつい、目の前のソースをばっさり消して、美しいコードにいちから書き直して、みんなの賞賛をあびながらどや顔している「天才的プログラマ」になった自分みたいな妄想をして、現実逃避したりは・・やっぱり・・しますね。
天才的プログラマっているのですね
世の中には天才的なプログラムは、たくさんいます。
天才とまでいかなくて、自分の２倍・３倍くらい優秀なんて程度のレベルなら、たぶん、はいて捨てるほどいるんじゃないですかね。
その中でも、自分が一番インパクトをうけたのは「登 大遊さん」という人です。
最近では、65万円で作成したテレワークのシステムで名前がでてました。
ですけど、
自分がすごい衝撃を受けたのは、ずっと以前。
およそ15年くらい前（2007年）に登さんが書いたこのブログ記事です。
この記事は、いきなり、こんな感じで始まります。
僕は、1 日に少なくとも 3,000 行程度、多く書くときで 10,000 行以上のプログラムを書くことができる。その結果、多い月で 10 万行 / 月くらいである。なお、言語は書くソフトウェアの性質上、大半が C 言語である。また、プログラミングにはバグが付き物だが、ここ 2、3 年の間は、発生するバグの数を極めて少なく保つことに成功している。
この時点で、無茶苦茶です。
1ケ月間でも、この人の1日分に満たない人は山ほどいます。
自分も含めて・・ですけど。
しかも、プログラミングのやり方について書いているのを見ると
だいたいイメージができたところで、心の中に、ソフトウェアの設計図やデータ構造といったものを思い起こす。
・・・・ 中略 ・・・
コンピュータの前に座って、キーボードの上に両手を置けば、後はあまり考える必要はない。自動的に手がキーボードを打ち、プログラムを入力して完成させてくれる。
などと書かれています。
そのくせ
また、プログラミングにはバグが付き物だが、ここ 2、3 年の間は、発生するバグの数を極めて少なく保つことに成功している。
とのこと。
ただただ、すごいな・・と感心はします。
でも、真似できそうなところは1ミリもありません。
アニメや漫画・小説の登場人物ならともかく、こんな人間が実在しているんだな・・という事実そのものが衝撃でした。
自分は凡人だと正しく認識できたのは有難かった
マネできる部分は１ミリもない・・とはいえ。
上記の記事は、逆の意味ですごく参考になりました。
それは
の２つです。
それまでは、いろんな優れたプログラマの記事を読んでも、なんとなく、がんばったら自分もなれるんじゃないか・・みたいな気になって、真似をしてみたりしてたんですけど、そんな淡い期待を粉々にしてくれて、逆に清々しい限りです。
例えば、上記の記事には、こう書かれています。
まず最も重要な前提知識として、以下の 3 つのことを遵守することが必須である。
① 努力しないこと
② 論理的に考えないこと
③ 頭を使わないこと
それ以前なら、その意味を考えて、参考にできる部分はないか考えたでしょうけど、自分は「凡人」なのだと確信できてからは、上記は「天才」のすることで、「凡人」である自分はこうすべきだと言い切れるようになりました。
① 努力すること
② 論理的に考えること
③ 頭を使うこと
これは大きいです。
凡人プラグラマには凡人なりのやり方がある
有難いことに、自分は長いこと業界で仕事させてもらっています。
なので、自分なりのやり方はもってます。
長年、いろいろ試して失敗から学んでたどり着いた自分にあったやり方ではあるのですが、正直、なんら目新しいことのない「ザ・凡人」のやり方でもあります。
ざっくり、紹介してみます。
自分の仕事のジャンルは「業務アプリケーション開発」なので。
最初にすることは、自分が利用者になったつもりで、作ろうとしているシステムがかかわる業務の流れを頭の中でシュミレートすることです。
あくまで目的は、そのシステムを使うことで、利用者の業務が効率的になることです。
だから、その観点を忘れずに色々な角度から考えながら、画面・処理・データ構造などをデザインして、そこにあてはめていくことになります。
凡人プログラマは、ここで「論理的に考えぬく」しかありません。
正直。
一発でうまくいくことは少ないです。
凡人の悲しさで、具体的なレベルに落とし込んでから、大きな見落としに気づいて「やりなおしだあ！！」となることも多々あります。
３回か４回もやりなおすなんてこともあって、心が折れかけますが、ここを面倒がってはしょってコードを書いていっても、どっかで手戻りが発生して、よりダメージが大きくなるだけなので、我慢して続けるしかないんです。
なんせ「凡人」なんで。
まとまったら、コードを書いていくわけですが、自分はコードを書く前に、コメントでアウトラインを書くことが多いです。
そうしないで、頭の中のイメージだけでコードを書こうとすると、何回も資料を見直したり、次の日になったら一部忘れてたりして効率が悪いから・・という、これも、実に凡人チックな理由ですけど。
例として・・素数を求める関数をPythonで書くのをやってみます。
まず、最初はこんな感じになります。
''' 引数で与えらえた数より小さい素数のリストを作成して返す 引数：number ''' def make_prime_number_list(number): # 素数・素数以外を識別するための定数(PRIME、NOT_PRIME)を定義する # numberまでの全数字のリストを生成し、全部PRIME（素数）に仮置きする。 # 数字リストの0と1は素数ではないので、NOT_PRIMEにする。 # 2からnumberまでの数(i）をループで処理する # 数（i）を２乗した数がnumberを超えたら終了する # 数（i）にあたる数字リストが既にNOT_PRIMEにならスキップする # 数（i）に2から順に数を掛けて合成数を計算する # 合成数 con_numがnumberより大きくなったらブレイクする # 合成数 con_numは素数でないので、数字リストをNOT_PRIMEにする。 # ここで数字リストがPRIMEで残っている数は素数なので、結果リストに格納する prime_number_list = [] # 作成した結果リストを返す return prime_number_list
まあ、アルゴリズムの説明文をそのままコメントに移したような感じです。
実際は、ここまで細かく書かずに、アウトラインを書いて、あとで必要に応じて細かくしていく感じですけど、まあ、サンプルなので細かくしてみました。
あとは、ここにコードを埋めていくわけです。
できあがったら、こんな感じになります。
''' 引数で与えらえた数より小さい素数のリストを作成して返す 引数：number ''' def make_prime_number_list(number): # 素数・素数以外を識別する定数 PRIME = 1 NOT_PRIME = 0 # いったん、全部P（素数）に仮置き。 number_list = [PRIME for i in range(0, number + 1)] # 0と1は素数ではない number_list[0] = NOT_PRIME number_list[1] = NOT_PRIME # for i in range(2, number): # ２乗した数がnumberを超えたら終了 if (i * i) > number: break # 既に素数でない場合はスキップ if number_list[i] == NOT_PRIME: continue # 2から順に数を掛けて合成数を計算 for c in range(2, number): con_num = i * c # 合成数がnumberより大きくなったらブレイク if con_num > number: break # 合成数は素数ではない if number_list[con_num] == PRIME: number_list[con_num] = NOT_PRIME # 数字リストに素数のままの数を結果リストに格納 prime_number_list = [] for p in range(0, number): if number_list[p] == PRIME: prime_number_list.append(p) # 結果リストを返す return prime_number_list
見ていただいたらわかりますが、コードを埋めながら、コメントも調整してます。
コードを埋めた後は、コードを見たらわかることは極力消すようにしてます。
多すぎるコメントは、コメント自体の保守が難しくなるからです。
コードを修正する手間より、コメントを修正するほうが大変だなんて本末転倒なことになったら、バカですからね。
そこは気をつけてます。
なお、このへんは既存のコードを修正するときも同じです。
ソースを調べ、わかったところから、コードを補完する日本語コメントで埋めます。
ソースリーディングの効率があがって見落としがない・・なんて理由を表向きは言ってますが、実際のところ、こうしておかないと読んでいったん理解しても、次の日になったら半分くらい忘れてたりするので、その防止策（笑）です。
こんな感じで、自分が仕事でかかわったソースは、一気にコメントが増えます。
自分にあったやり方ではありますが、正直、ソースコードが美しくない・・と言われればグウの音もでません。
それに、コツコツ、地道な作業ですし、締め切りがある仕事の時とか、はしょって進めたい気持ちとの闘いにもなります。
そして、実のところ、楽しくもありません。
自分も仕事以外のプログラミングではこんなやり方はしません（笑）。
あくまで、仕事で役目を果たすために試行錯誤した「凡人プログラマなりの仕事のやり方」なのです。
でもね。
このやり方が確立できてから、自分が修正したプログラムで本番稼働後にトラブルになるようなバグの発生確率は確実に減りました。
だから、間違ってはないんだろうな・・とは思ってます。
世の中には「凡人」のほうが圧倒的に多いのです
自分のやり方に批判的な人はもちろんいます。
コメントをゴテゴテ書くな！！・・とか言われることもあります、
でも。
コメントのおかげでソースを追いやすくなったと、喜んでくれる人もいます。
まあ。
いろいろな意見があっていいと思います。
だけど、自分は思うわけです。
仕事で作るプログラムは、作った本人がメンテナンスし続けることのほうが少なくて、いろんな人の手によって保守されていくのが普通です。
その中には、天才的な頭脳をもった人もいれば、凡人もいます。
そして人数的にいえば、世の中には「凡人」のほうが圧倒的に数が多いはずです。
なので、複数の人によって手がはいるようなプログラムこそ、低いほうのレベル＝凡人にあわせたやり方がされている方がいいに決まってる・・と。
なので、凡人プログラマは凡人プログラマなりのやり方をすべきであって、ちまたに紹介されている「天才プログラマのやり方」を真似しちゃいけない。
そうも、思うわけです。
ではでは。
