プログラミング言語の教科書と目の前で動いているシステムがどうも、結び付かないという方はいるでしょう。私自身も効率は悪くなってきましたけど、今でもソースコードをいじってます。ソースコードの厄介なところは、一人では作れないという事です。人が作ったソースコードを埋め込む、あるいは大勢で分担して作り、つなげるという作業です。最近は、自分で作るより外からもってくることで、随分、楽になりました。最近でているandroid アプリも昔だったら一人では作れませんが、android のライブラリ(人が作ったソースコード)を使えば、なんとか作る事ができます。これは、どういうことか。

1. どんなライブラリがあるか知らなくてはいけない
2. 外のソースコードは見ない

という事になります。ライブラリは時代とともに成長しますので、覚える事がなくなるということはありません。ですが、例えばandroidのライブラリは閉じた世界で、他では使えない。この業界にいると、どれだけ無駄なものを覚えなければいけないのだろうと思っていました。今では、覚える事が苦にならなくなりましたね。覚えるという事は如何に忘れるか、なんて学者さんがいいそうですが、その通りかもしれません。覚え方と思い出し方と忘れ方のプロがプログラマーではないかと思います。インフラに転向して、長くはありませんが、１０００個ぐらいのIPアドレスを覚えるのが苦ではない事に驚いています。ですので、数万行のソースコードを覚えるのは、有意義な事ではないと思う人にはすすめません。とは言っても障害が起きた時に、見ないでいいのか、という悩む時はくるでしょう。私自信も、「２．外のソースコード」は基本みません。自分達で作るものは必要十分なボリュームを目指すので、コンパクトですが、外のコードは汎用的であり、時代とともに、いくつものライブラリが加わって、みずらいのと、膨大な量になっています。それでも必要に駆られて見る事はあります。見るだけでは覚えられないので、書いたり、整理したりします。書くと言ってもせっかくPCを使っているのですから、コピーと貼り付けにコメントを付ける作業です。これをやらないと頭の中に入ってこないと思っています。あと、とにかく眠たいです。引継の時はまる１週間から１ヶ月は、ずーっとソースコードを見続けるので、ほんと眠くなります。寝ながらだろうが、なんだろうが、覚えればいいのです。そうしているうちに、危険なソースコードが見えるようになってきます。

1. ソースファイルの大きいものは、避けては通れない。
2. 古い更新日付のソースファイルには手を出すな。
3. ファイル名から機能がイメージできないものは、徹底的に調べるべし。

【１．ソースファイルの大きいものは、避けては通れない。】

ソースファイルが大きいとは、どういう事かというと、複数の人間で作る為という事もありますし、ソースファイルの名前で中身がわかるようにしたいので、開発当初は一定のサイズを目指して書き始めます。あまり大きくすると読むのも大変です。それが、大きくなった理由は、達成する機能が難しかったと言えます。難しい定義は様々ですが、以下のように考えてます。

• 要件が増えた。
• よく使われる機能で、変更を余儀なくされた。
• よくトラブルがおきて、何度も改修した。

当初の予定になかったのですから、大きくなるのは当たり前でしょう。ですから、最初にファイルサイズをみて大きいと感じたら、見たくなくなるのですが、上記の理由は全て重要な機能である事をさしています。重要であるからこそ、要件は増えるし、良く使われるから変更も多い、増えて多いのだからトラブルも多くなります。そういう経験から大きいファイルは気合を入れて読むようにしています。障害対応するのですから、危険なソースから見るのは当たり前です。顧客担当として、もし可能であれば、どのソースをリリースするのかを把握する事をお勧めします。あのソースに手を入れると、こういった不具合が発生しやすいと前もって認識できるからです。

【２．古い更新日付のソースファイルには手を出すな。】

１年前がぎりぎりでしょうか。システムの改造頻度もあるので一概には言えませんが、３年以上も前のソースはいじるべきではありません。システムは人間的と言い続けていますが、今まで誰もやってこなかった事をやるのは、『人類は継承し続けて現代がある』という視点からも、誤りでしょう。例えば、あるAというソースコードがあり、それを１００本の他のソースコードから呼ばれてしようされていたとします。Aを直せば、１００本に影響がでます。そこで、AをコピーしてAAを作成します。このAAは１００本のうち、今回、目的だった５本のソースコードのAを呼ぶところをAAに変更します。影響範囲が少なくてすみます。せっかく共通処理として作ったのにもったいない話ですが、このAAの存在を理解せずにAを直す事が良くあります。とくにAAはコピーではなく、いくつか機能を付けて、内容が被る部分はAを呼び出していた場合、AAの存在を理解していたとしても、Aの改修が非常に難しい状況に置かれます。簡単な例としてAは、ユーザの名前を返す処理だったとします。AAは、名前に「様」を付加する機能だったします。新たな要件にユーザが企業だった場合は「御中」を付けて欲しいと言われました。単純にAの処理に「御中」を付けてしまうと、AAでは「御中様」となってしまいます。そして「御中」を付けたいのは、呼出し元の１００本中２０本でした。簡単な例ですが、悩ましい問題です。開発の現場ではよく「方針がわからない」という声があがります。AとAAを直すのか、BBを作るのか、BBを作っただけではだめで、AAの５本中２本の呼出し元に影響があるので、ABを作るのか。どれを選択しても間違いではありません。問題があるとしたら、改造の度にAと１００本の呼出し元を直したり、BBと作ったりと理由もわからず、方針が変わる事でしょう。話がもどって、古い更新日付の例は、Aは直さず、BBやABを作ってきた場合です。私は何度もAを直して失敗してきましたので、過去の方針に沿ってBBやABを作ります。実際、呼出し元１００本の影響調査を一人でやる、または、複数のスキルが異なるメンバーでやるのは、リスクの高い作業です。最低でも２人がそれぞれ１００本見るべきでしょう。いいえ、やはりさけるべきです。

【３．ファイル名から機能がイメージできないものは、徹底的に調べるべし。】

これは作り手の問題というよりは読み手の問題です。自分に弱い部分という事がわかります。自分に弱い部分で一番やってはいけない事は、他の人に保障してもらう事です。まったく同じ立場または、相手の方が上の立場であれば個人的な責任はないかもしれませんが、障害になる事に変わりありません。話は変わってしまいますが、イエローハットの創業者は時間を作って毎日、会社の便所掃除をするそうです。会社が大きくなると駅から会社までの道路を掃除するようになったそうです。これは、汚いものに手を出さなければ、どんどん目を背け、取り返しがつかなくなる事を知っているからでしょう。私自身、このソース見たくないなあと直感的に感じたものは、ほんとによく障害にあいます。もし、今まで面倒を見てきた人も、そう感じたのなら、恐ろしい事になっている事でしょう。指でつまんでポイってすてるような対応してきたのですから。汚いソースは一度綺麗に編集し、時には部分的に理解して、コメントをいれ、まとめた資料を別途作成します。ソースコードは無暗にいじってはいけないので、リリースするソースコードは変わりませんが、頭の中はスッキリしています。なので、障害が起きても、前向きに対応でき短い時間で復旧できたり、改造したいという要件には、どのようなリスクがあるかを述べて、顧客の上長を説得してもらったり、他の方式を検討する事が可能になります。他の方式とは、当初予定していたより、使い勝手が良くならないとか、運用業務が一つ増えたとか、そういう条件をのんでもらうという事です。障害が発生して何日も止めて、且つ治らない（治しても治しても事態が良くならない）よりは、よっぽどましですが、説得する際の理由として、「よくわからない」とか、理由もなく「できません」では、説得のしようがありません。