プログラマーとして習慣づけるべきこと

新装版 達人プログラマー 職人から名匠への道

目次

目的

株式会社ソニックガーデンの代表である倉貫義人さんのブログで、「プログラミングの初心者を抜け出すための習慣」という記事を読みました。自分は流石に初心者ではないですが、かと言って上級者ですとも自信をもっては言えません。
今回読んだ記事に書いてあることは一見当たり前の事ですが、精神的に余裕が無かったりするとついつい疎かにしてしまうものばかりだったので、今後も意識していけるように、記事の概要及び読んだ感想をメモしておこうと思います。

参考記事

記事の原文は以下のリンクよりご覧になれます。
kuranuki.sonicgarden.jp

エラーが出ても慌てず、メッセージを読もう

最近の自分は、エラーメッセージは一応見ますが、その後はググるのが先になってしまいますね。。エラーが起きたコードの行数とかエラー内容がちゃんと表示されているんだから、それをちゃんと見れば原因は分かったはず。
正直、ググって参考情報を探し回っている時間が勿体ない。

ネット情報を鵜呑みにしない

ネット情報だけでなく、自分が今参考にしようとしている情報に本当に誤りがないかを事前に確認すべき、ということをここ最近の開発業務で痛感しました。
あるロジックを実装しようとした際に、その参考にした論文の数式に間違いがあることに後で気づく、なんていうことがあるので注意が必要です。

公式ドキュメントから読もう

ググるのが先行してしまうので、ついついQiitaやStack Overflowで同じ悩み抱えた人の投稿を探してしまいますが、確かにその通りですよね。。
公式ドキュメントなんだから、正しい情報が確実に書かれているはずですからね。

当てずっぽうで試していかない

エラーが出たり、動いているけど期待通りの動作ではない時にはデバッグが必要ですが、どこに原因がありそうかを論理的に考えてから手をつけないと逆にややこしくしてしまいます。
自分が開発をするときは、変更前のコードとの差分と、自分が新たに追加したコードの中身をあらかじめ整理してから動作確認を行うようにしています。

未知のものは、まっさらな環境で試そう

自分の場合は本番ソフトはC言語やC++で実装するのですが、いきなりそこに新しいロジックを織り込むことはせず、まずはMATLABやPythonでプロトタイピングしてシミュレートして、自分が今からやろうとしている事が正しいと確信できてから本番のコードに移植します。
こうすることで、事前のシミュレーション結果と比べて答え合わせしながら動作確認できるのでいいです。

ライブラリを見つける力と目利きを鍛えよう

今や様々なライブラリが無料で使える時代なのですが、ブラックボックスで中身が全然分からないというのも嫌なので、自分はついつい自分で頑張って一から実装しようとしてしまいがちです。
後々のことを考えれば理解は深めた方がいいですが、開発に掛けれる時間には限りがあるので、あまり余裕がないときには割り切って世の中のライブラリの助けを借りるという選択も大事だなと感じています。

大雑把に理解できる力を身に着けよう

最初は完璧に理解してやろうと意気込む訳ですが、途中でついていけなくなって心が折れたり、ふと他に気になることが見つかって脱線したりすることが多々あります。
自分が今与えられてる時間とその時点での実力を考慮して、ざっくりやるのか細かく追及するのかを臨機応変にやらないといけないと思いました。

一度に大きく作ろうとせず、小さく進めよう

これは自分も日頃から欠かさない事ですね。ちょっと書いては実行し、ちょっと書いては実行し、を繰り返していきます。中には一気にガーっとコードを書いてからデバッグに進む人もいますが、エラー出まくりで混乱するんで自分には無理ですね。

コミットする前には、動作確認しよう

これは流石に忘れることはありませんが、個人的に大事だと思っているのは、新たに追加した部分だけを確認して終わりにしないという事です。
新たなコードを追加している間に思いもよらぬバグを仕込んでしまうというのはよくある話なので、変更前まで正常に動いていた部分も大まかに確認しておくと後々のトラブルを防ぎやすくなります。
また、動作確認をする前にテストケースとその実施手順をあらかじめ作っておいて、それらを一つ一つちゃんとチェックしたという証を残しておくことも必要です。

最初にTODOリストを作ってから始めよう

自分もある程度作業を細分化してリストアップするようにしていますが、今回読んだ記事では、一つのTODOは30分～1時間で終わる程度にして、その単位でコミットするのが良いと紹介されています。確かに、それくらいの短時間でサクサク消化できる方がやる気も持続できていいですね。

頭から順に書き始めずに、構造化しよう

まずは自分の頭の中でロジックが回るようにしておかないと、ソフトに織り込んだって期待通りに動くわけがないですね。また、その中でデバッグ時にポイントになる部分を見つけておき、仮に正しく動作していればこの変数はこういう値を示すはず(例えば0～1の範囲に収まるとか)、というのを押さえておけばそこに注目することでデバッグがしやすくなります。

頭で理解しきれないなら、絵にしてみよう

これはプログラミングを勉強し始めた時にかなり序盤で教えられたことですが、そういうもの程常に重要であり続けるものだなと感じています。むしろ、まずは絵を描くところから始めてもいいのではないでしょうか。

メンテナンスの前に、コードを読み込もう

なんならリファクタリングしてしまえ、と紹介されていますが、そこまで考えたことはなかったですね。もとのコードをそのまま理解しようとしてしまいますが、大抵は実際にそのコードをいじってみる方が良く理解できるものなので、リファクタリングしようとするのは良い習慣だなと思いました。