開発力を上げるうえで重要な考え方

開発をする上で重要な考え方について教えてもらったり、記事を読んだりすることがあるが、いずれも教えてもらうことは同じ内容が多かったりする。それだけ重要な考え方というふうに捉えているが、自分自身もなぜ重要かということについて腑に落ちてきた部分があるので、まとめてみる。

情報は公式サイトから探す

分からない部分があると、Qiitaのような2次ソースで情報を探しがち。公式サイトのような1次ソースに比べて読みやすく、探しているのに近い情報がすぐ出てくるので2次ソースで探しがちになるが、情報の正確性・最新度という面では1次ソースが優れている。したがって、まずは公式サイトで検索し、欲しい情報がない・情報がわかりにくいとなればQiitaなどの2次ソースを検索するのが基本だと考えている。

しかし、公式サイトは検索方法にやや癖を感じていて、欲しい情報がすぐに見つけられないことも多い。その点を課題に感じている。少しでも探しやすくするため、Googleのsite:タグを使って検索している。これで、少しは検索しやすくなるかなと感じている。

用語の定義はちゃんと押さえる

エンジニアの知り合いで、用語の定義にうるさい人がいる。用語が多くてそれぞれ定義を覚えるのは大変だが、ここをしっかりしていないと開発でのコミュニケーションに齟齬が生じる可能性があるからだろうと考えている。意味の理解がおぼつかない状態で用語を使うのもよくないと思うので、定義が不安な用語は少しずつでも都度調べるようにしている。

エラーが発生したらエラー文をちゃんと読む

エラーが出ると、よく読まずにGoogleに投げてしまったりするパターンを見かけるが、よくないと考えている（自分が頭まわっていない状態で長いエラー文を見ると、ついやりたくなってしまうけど…）。基本的には、エラーが出ている原因はエラー文に書いているので、まず熟読した上で対処を行ってみるべきである。その上で、書かれている意味がわからなかったりする場合は検索してみるのはありかと考える。

ちなみにやや脱線するが、素直に読んで書かれている意味が分からない場合は、全角スペースといった変な文字が入っているなどで記法がおかしいケースもまあまあ見かける気がする。また、初期化関連の措置（プロジェクトのクリーン、再起動など）を行うと、うまくいくケースも散見される。

また、エラー文を見かけるシチュエーションは複数あるが、その中でもサーバでの作業といった場合にエラー文を見かけにくいことがある。そのような場合でも、ログといった形でエラー文がどこかに残っていることがあるので、作業がうまくいかないときはまずエラーログを探すべきだと考える。Linuxサーバの場合、/var/log配下にログが残っていることが多い。エラー文がぱっと見で見当たらないと、原因対処にならないような措置をあてずっぽうでやりがちになるが、エラー文を特定できると、案外素直な措置で原因が解消できることもある。

しかし、やっかいなパターンとして、エラーが発生しないが作業がうまくいかないというものがある。例えば、DBがやけに重いといったシチュエーションである。こうなると、原因をすぐに特定するのは難しい。できることとしては、Windowsの場合はタスクマネージャーといったツールを使うことで、リソースの使用率がどうなっているかを見ることである。そして、使用率が高いプロセスを終了させてみるといった具合である。

また、挙動がおかしそうな部分があれば、その周辺で使っているライブラリなどを別のものにしてみるのもアリである。例えば、圧縮処理を使っているシステムにおいて、圧縮処理自体は正常終了するが圧縮ファイルを解凍できないという事象が起きた場合、圧縮処理を行うライブラリを変えてみるという具合である。

コードの意味を理解せずコピペしない

初めてのフレームワークなどを使う時は大変だが、コードを他から持ってくる時はその意味を理解した上でコピペするようにという考え方である。

この考え方は、理屈では正しいと理解しているが、完全に実践するのが難しいこともある。しかし、全部を完全にすぐ理解できなくても、少しずつでも意味を理解しながら時間をかけてコードを書けるようになると、システムの挙動に説明がつけられるようになったりすると考えている。さらに、コードの意味を理解していないと、似たようなコードしか書けず、柔軟に対応できなくなるのだろうと考える。

また、ツールの設定を変更したりするときなども同様である。手順で設定の変更などが示されていても、変更して何がどう変わるかということについて理解した上で実施すべきである。知識不足などで、どれだけ時間を費やしても理解が追いつかない時などは仕方がない面もあるが、少しでも理解しようという姿勢は重要かと考える。設定変更などによるついて理解できていないと、変更後に挙動が変わった際に説明がつけられず、一人称で切り分けができなくなると考える。

終わりに

以上の考え方は、基本的だが完全に実践するのは難しい部分もある。しかし、このような開発の考え方が理解できていると、開発力も上がっていくはずなので、継続して実践するようにしたい。