LoginSignup
2
1

More than 3 years have passed since last update.

効率よくコーディングするための考え方

Last updated at Posted at 2020-05-28

はじめに

久しぶりに丸々一本実装したのですが、思った以上に時間がかかってしまいました。
何がいけなかったのかを反省するとともに、効率の良いコーディングに結び付けるにはどうするかについての徒然メモです。

動作確認の時間を減らす

コンパイルの回数を減らす

1つ実装するたびにコンパイルして動作確認をしていいると、着実に少しずづは進んでいきますが、実装のスピードは遅くなります。ある程度のまとまった単位の実装が終わったタイミングで動作確認するように意識しましょう。

インプットのデータ量は最小減にする

データの読み込時間は意外と侮れません。確認したい箇所に到達するまで1分かかるのと10秒ですむのとでは、10回確認した場合であっても9分近くの差が発生します。
一定量のデータを使った動作確認はテスト工程に任せましょう。
但し。パフォーマンスを意識する必要がある場合は、別途、パフォーマンス検証を事前にする必要があります。

デバッグログをしっかり仕込む

想定通りに動かなかった時の原因特定でハマるとかなりの時間を費やします。
デバッグログは、バグの原因特定だけでなく、各処理が想定通りに動作していることを確認する際にも効力を発揮します。

変数・定数

極小スコープ以外は固有の変数名を付ける

「s」や「i」、「row」や「data」などの変数名で宣言した場合、他でコードを借用した際に、借用先のコードと変数名が被ることがあります。
結果、借用元か借用先のどちからの変数名を変更することになりますが、変更漏れによるバグが意外と多いです。また、同じことをしている部分の変数名が処理によって異なるとメンテもしづらくなります。
汎用的な変数名は、他のロジックが這いこむ余地がないくらいの極小スコープでのみ使用するようにしましょう。

別の変数の一部分となる変数名を定義しない

IDEが貧弱な場合「item_code」と「item_code_limit」のような名称を付けると、「item_code」で検索すると「item_code_limit」まで引っ掛かってきます。リファクタリンク機能のない環境で置換をせざるを得ない場合も危険です。
同様の理由で、スコープが長い変数・定数に「s」や「i」のような名前をつけるのもメンテしづらくなります。

同じ値を関数ごとに別の名前で定義しない

「item_code」が「item_code」として意味するのであるならば、どの関数の中でも同じ名前で宣言しましょう。「item_cd」「ic」「item」みたいに、別名で宣言されると可読性が下がります。よそからコードを拝借した場合は、面倒がらずに統一感のあるソースに整形しましょう。

SQL

insert、update、delete、truncate はテーブル名まで1行で書く

今回の趣旨とは外れますが、データ更新系のSQLは、1行でテーブル名まで書いておくと、そのテーブルで grep すれば、CRUDを簡単に調査できます。

おわりに

一定のレベルに達していれば、コーディングの効率を上げることは、品質のよい成果物を作成することに直結すると思っています。
こんなことを意識したら、コーディングの効率があがりましたといった実体験のコメント頂けると嬉しいです。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1