効率的なコーディング方法の経験的備忘録
効率的にコーディングするための経験的備忘録。
- わかりやすい変数名、関数名をつける
- 変数名や関数名は時間をかけて考えて命名する。最初にわかりやすい変数名を考えるのは時間がかかるが、後にメンテナンスする時にわかりやすい変数名がつけられたプログラムと、そうでないものとでは作業時間に大きな差が出てくると思う。
- grepしやすい変数名、関数名をつける（短すぎない、ユニーク）
- わかりやすく簡潔なコメントをつける
- 何のためにコメントをつけるか？そのコードを一ヵ月後に見たときに、すぐに理解できるようにするため。すぐに理解できるようにするためには、わかりやすく簡潔なコメントが求められる。そのコメントを理解するのに時間をかけていたようではコメントをつける意味がない。プログラミングしているときに、ここは難しいところだと感じることあれば、迷わずコメントをつける
- コーディング前にデザインする。
- 「Joel On Software」という本でも書いていたが、デザインせずにコーディングを行うと、当初予定していた作業時間を大幅に過ぎてしまうことがある。コーディングする前にデザインすることでこのようなスケジュールリスクを削減することができる。これは、デザインで何かを変更する時間よりもコーディングで何かを変更する時間のほうが長くなってしまうし、変更したものを元に戻す場合はなおさらな話だから。ここでいうデザインとは、画面設計だったり、各モジュールのＩＦをどうするかという話を意味するが、必要のない（コーディングに役にたたない）デザインは無駄なのでやらないほうがよい。また、コーディング前にデザインを行うことで共通化するべきところを共通化できて工数の削減につなげることができる。
- 午前中にデザインし、午後にコーディングする
- １日中、デザインしながらコーディングというのは集中が続かないし、夕方に疲れてきて頭が動かなくなり何をコーディングするべきなのかわからなくなってくることがよくある。何かの機能を追加する場合、午前中にデザインし（修正するモジュール、ＩＦの変更点まとめ）、午後にコーディングすることで１日を効率的に使うことができる。
- シンプルにする
- 将棋の羽生さんの本に書いてあったけど、米軍や工学の世界ではKeep it Simple, Stupid!(KISS)という言葉があるそうです。日本語に訳すると「ごちゃごちゃに考えないで、簡単に考えなさい。」ということになるらしい。プログラムの世界でも、シンプルに考えてものを作った方がたいていうまくいきます。カーネギーメロン大学教授の著書で「素人のように考え、玄人として実行する」というのがありますが、まさにそんなかんじです。
- エラーログを出力する
- システムで問題が発生したときに原因となる箇所を特定する時間は結構かかる。これはプログラムが暴走して、どの段階でエラーが起きているのかを把握するのに時間がかかるためだが、エラーが発生した際に、必要な情報をエラーログに出力しておけば、すぐに特定できる。
- ドライバモジュールを利用する
- iniファイルを作成する
- プログラムでハードコーディングするより、iniファイルでデータを持つ。最初は面倒くさいが、テストの工数を考えると、断然iniファイルでデータ持つほうがよい。
- キータイピングそのものの時間を効率化する
- 集中できる環境を作る
- プログラミングにおいて割り込みされずに連続して何かを考えることのできる環境というのが重要で、この状態がもっとも作業効率がよい。この状態は「フロー」とか「ゾーン」とかいわれる。
- 短期記憶を強化
- プログラミングにおいては変数や関数を脳の一時記憶に入れて操るということが重要で、結局この脳の一時記憶の領域の大きさがプログラマの能力を決めるのかもしれない。
- 本番環境とテスト環境の画面を比較してテストする
- 段取りを考える
- 一覧表示機能を作る前に登録機能を作る。これが逆だと、一覧表示を行うためのテストデータを登録する作業が発生して無駄な時間を費やすことになる。
- ハードコーディングで一時対処。
- 修正前のソースはしばらくコメント状態で残しておく。
- ソースを修正するときに、安易に修正してしまった結果、動作しなくなることがあるが、そんなときでもすぐに元に戻せるように修正前のコードをコメントしておくとよい。（cvsでソースを管理している場合は、不要かもしれないが。。）このコメントに何回助けられたことか、、
- ソースを修正した時に、修正内容を資料にして記録する
- 同じような修正を過去に行っている場合、修正内容を記録しておけば修正が容易になり、工数もかなり削減できる。
- ソースにToDoをかく
- ソースの修正を行っているときに、たまたま間違いを見つけて、あれも修正しないといけない、これも修正しないといけない、とかいう場面はよくある。このような場合、ソースに"// ToDo 初期化が抜けている"といった感じでコメントを入れておき、それを後でgrepで検索するようにすれば、忘れることもないし効率的。
- 難しいコーディングは体調の良い時に
- 難しいことを体調の悪いときにすると、良い時に比べて数倍の作業時間がかかるが、簡単なことは体調の良いときでも悪いときでもそんなにかわらない。
- インターフェース情報のチェックロジックを入れる
- 他のシステムから受けとった情報や、関数の入力パラメタなどをチェックすることで、バグが見つかりやすくするとよい。
- スクリプトを自在に扱えるようにする
- コードの断片をコレクションする
- これはどこかのブログで読んだ話で、例えばperlでファイルを読み込むときにどうするんだっけ？みたいな場合に、コードの断片を記録しておいて再利用できるようにすると効率的らしい
- 決定を早くする
- 変数名や関数名を何にするか、処理方式をどのようにするかなどの決定をなるべく早くしたほうがよい。でも早くするとわかりにくい変数名、関数名、処理方式が出来てしまうので、そこをクリアした上で、早く決定することを心がける。
