プログラミングの長いコードを書く技術について考える

プログラマーという仕事をしていると、プログラマーではない人から、プログラミングの能力を魔法のように感じると言われることがあります。 人は自分でできない事を目の前で実行されると、魔法のように感じるのだそうです。 確かに海外旅行に言ってツアコンの方に通訳してもらう時に、自分でできない為にその人がいないとその国では生きていけないという気分になり、魔法というよりは「頼もしい」と感じる事はあります。 プログラマーは、仕事で行うプログラミングを「頼もしい」と思われる存在と考えてもいいのかもしれません。 そんなプログラミングという技術は、IT社会となってきた世の中では必要不可欠と言ってもおかしくはない職業になってきました。 そして同時に小学校からはじまるプログラミング教育を考えると、プログラミングは重要な社会の知識のお作法にもなって来ているようです。 そんなプログラミングのコードを書く技術を考えてみたいと思います。 ちなみに、今回の思考は、プログラミングを仕事で行っている人が読んで貰うことを目的としています。

ボリュームのある長いコードを書く技術

僕がプログラムスクールなどで講師をしていた時に、プログラミング初心者に言っていたのが、「３万行のコードを書いてようやく初心者から脱出できます」と話していました。 車の運転免許を取得する時に、免許センターの教官の方が言っていた、「３万キロ運転して初めて初心者マークがとれる」というのをそのまま流用していましたが、あながち間違っていない感覚です。 プログラミングを勉強する時に、はサンプルコードとして短いプログラムコードで学習することがほとんどですが、実際に何かツールを作ろうとプログラミングすると、非常に長いコードを書かなければいけません。 実際に仕事で初心者プログラマーを採用した時に、学校や参考書でのコード写経はしたことがあるけど、自分でコーディングしたことがない人や、他人の書いたソースコードを読んだことがない人などは、いざ仕事でボリュームのあるコードを書く際に、思考がついていかなくなる事が多いようです。 僕の知り合いのリーダークラスのプログラマーが以前に言っていた言葉で、「１０００行以上のプログラムコードをコントロール出来る人はプロ」というのを覚えていましたが、確かに短文でのプログラムは一目見るだけで分かるかわからないかという判断ができますが、長文プログラムは、しっかりと読み込んでから、そこに書かれている処理を理解して、実際に自分の頭の中で処理を実行するというシミュレーションができないと、理解することができません。 人のコードが読めないと、自分でそれよりも優れたコードを書くことは、中々難しいでしょう。 ここで重要なのは、無駄に長いプログラムを書く技術という訳ではなく、複雑なプログラムをキチンと管理できるかどうかという点を間違えないようにしましょう。

処理時間の長いコードを書く技術

スマートフォンって、１０年前の高価なパソコンの数倍のスペックを持っているのってご存知でしょうか？ 信じられないぐらいに高い処理能力を持っているんですが、パソコンを自作していた時代によく言われていた言葉で「１年経ったらゴミ同然」と話しながらパソコンを購入していたのを覚えています。 毎年、性能の高いCPUや周辺機器が登場するのを分かっていながら、その時の最高スペックを購入しておかないとITスキルの向上につながらないですからね。 その当時のITエンジニアは必要投資としてやっていたにちがいありません。 プログラムを勉強する時に、サンプルコードは一瞬で結果がでるものを扱いがちですが、実際に仕事で数時間かかる集計処理などを構築した時に、その処理が正しいのかどうか、数時間待って確認しなければいけないという仕事で、やきもきしながらプログラミングしたのを覚えていますが、 実際に数時間毎にデバッグしながら、修正を行っているというだけでは、生産性が悪すぎます。 こういう処理を構築する際には、最短時間で実行が確認できる（または、不具合が検出できる）構造体にして、不具合検知が出来る仕組みと、処理を継続出来る仕組みを考えるのが重要になります。 こうした処理時間の長いプログラムをコーディングするプログラマーの出来の良し悪しは、そうした論理的なコーディング作業ができるかどうかで判断できるでしょう。

寿命の長いコードを書く技術

10年後も使い続けられるプログラムを書くことは重要ですが、簡単ではありません。 世の中の誰もが知っているWEBサービスであっても、定期的にプログラム変更が行われています。 UI/UXを最新の社会の動向に合わせていく事や、セキュリティ対応の為に、必要な作業のように思われていますが、おそらくは殆どの場合は、プログラムコードの書き方を変えるために行われることが多いようです。 技術責任者が変わったとした場合に、その責任者の持っているプログラムポリシーに合わせるためにコード変更が行われることがありますが、同時にそれによる不具合発生も起きています。 原因はなかなか公表し難いので、「セキュリティ向上の為」という名目で、「想定外のトラブル」として原因公表するケースが多く、利用ユーザーは真実を知る機会は少ないのですが、不具合の原因というのは、比較的シンプルで、凡ミスがほとんどであることの方が多いはずです（あくまで僕の見解ですが・・・） 話がそれましたが、一般的にプログラムの寿命を長く保ちたい場合には、以下の点を考えるのがいいようです。

・上位下位の互換がしっかりしているプログラム言語の選定 ・ブラウザや端末の環境に依存するようなプログラム機能を使わない ・少なくても開発チーム内で誰もが読めるコーディング

必要最低限の事ですが、言語選定から行うのは非常に有意義であると言えます。 WEBサービスの場合は、サーバー環境に依存しないような思考をもたせるだけで、長期間の維持が簡単に行えるようになります。 例えば、新しいディストリビューションが主流になりそっちに載せ替えたら全く動作しないというコードよりは、apacheであれば、xampやmampでも、コンテナ環境であっても、問題なく動作できるという方が、長期間動作するコードという事になります。

プログラミングにおけるコードを各技術のまとめ

プログラミングは、何を持って良いのか悪いのか、という議論は、プログラマーでは色々とよく議論されます。 今回のテーマである、「長いプログラム」というのは、ボリュームが大きければ良いという訳でも、処理速度が長いほうが良いという訳でも、長く使い続けられれば良いという訳でもありません。 ボリュームのあるプログラムを書けるプログラマーでしっかり管理できるのは良しとされ、ボリュームはあるが、単にコピペされまくって、修正をするのに苦労するようなプログラムは、誰が考えてもいいプログラムとは言えません。 また、実行時間は長いよりもより短い方が、効率的だし、良いプログラムと判断できます。 ここでは、戻り値を得るまでの時間が長いプログラムをキチンと管理できるプログラマーが良しとされます。 それでは、長期間同じプログラムを使い続けられるコードは優秀なコードのように思われるかもしれませんが、コードは常に環境に左右される事が多いため、出来る限り改修がしやすいような構造になっているプログラムで、より最新の修正が行われている方が、いいプログラムと考えても良いかもしれません。 ただ、長期間修正されなくても、使い続けてボロが出ていないプログラムを素晴らしいとするのも、あるべき姿かもしれません。 ここで考えたいのは、コーディングされたプログラムの良し悪しよりは、プログラマー自身の良し悪しが優先されるべきであって、悪いプログラムはすぐにでも作り直せばいいのです。 「コードを憎んで人を憎まず」という言葉をチームプログラミングに置いて、よく聞きますが、同じチームでプログラムの出来の優劣をつけるよりも、チームで作り上げるコード（サービス、製品）が、競合会社よりも優れている事を競ったほうが、全てが上手く事が運ぶので、コーディング技術を追求する開発チームは、自分たちのチームの信頼度をより長く保てるように心がけるのがいいと思いますよ。