偉大なプログラマになるのは難しいが、良いプログラマには努力すればなれる。
良いプログラマになりたい！
というわけで、良いプログラマになりたいんです。そこで、どうすればなれるのか考えてみました。まだまだ自分で実践できていない部分が多くてアレですが、この方向性だなーと今は感じています。
また、今回のまとめは、情熱プログラマとUNIXという考え方、Team Geekなどの本から強い影響を受けています。要はこの3冊を読めばいいんですが、自分の中でこれは！と思ったものをピックアップしています。
内なる3つの美学
有名なラリー・ウォール先生によるプログラマの三大美徳ですね。
- 無精（Laziness）
- 短気（Impatience）
- 傲慢（Hubris）
外なる3つの原則
Team Geekで紹介されていたHRTの原則です。
- 謙虚（Humility）
- 尊敬（Respect）
- 信頼（Trust）
あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ
と書かれているように、当たり前のように感じるかもしれませんが大切です。
テストコードを書く
自分の書いたコードを目で何回も確認するとか正気ですか？明日の自分が今書いているコードについて理解できますか？動くかどうか不安を抱えながらコードを書き続け、デプロイするの精神的につらいですよ。ただし、テストコードにも良いテストと悪いテストが存在するので、ただ書けば良いというわけではないのが、難しいところですね。
ドキュメントを必要最低限整備する
自分の作ったシステム、誰かに説明するとき、いちいち自分でその人の所まで行って解説しますか？面倒くさいですよね。ドキュメントを運用し続けるのが大変とか課題はあるけど、いったん書いてみましょう。そして習慣にしましょう。
エラーログと常に向き合う
プログラムが動かなくなったら、なんで真っ先に自分のコードを見るのでしょうか。まず確認すべきは画面に表示されるエラーメッセージや、エラーログです。そこにヒントが書かれている可能性が高いです。
技術を知ったつもりにならない
Twitterなど日々流れてくる技術トレンド、文字面だけ追って知ったつもりになってませんか？実際に、コードを読み、動かして、体感をしましょう。サンプルコードを動かすだけでも違います。できれば、それを使って何が出来るのか自分で想像し、アウトプットしてみましょう。
毎日、少しずつより良くしていく
目の前にクソみたいなコード（簡単にクソコードというのは止めよう）が樹海のように広がっていて、誰も仲間がいなく孤独な戦いを強いられている状況であっても、くじけず毎日少しずつ、良くしていくことを心がけよう。そして小さなことで自分では大したことじゃないと思っていても、周りにアウトプットしよう。
アウトプットをクセ付ける
極端な話だけど。自分がなにか偉大なことをしたとしても、誰かに認識されなければそれは無かったものに等しいです。場所ややり方は何でもいいけれど、誰かに見てもらう努力。
誰のために、何のために働いているかを考える、分かろうとする
今書いているコード。何のためか理解していますか？そんなこと関係ない、仕様書があって、それを実装するだけだ。これでは、モチベーションも維持しにくいです。それに理解を超えたコードを書くことは不可能です、つまり、良いコードが書けない可能性が高まります。依頼者の気持ちを考えてみてください。自分が実現したいことに対して、理解してくれない人と一緒に働きたいですか？自分もそう考えているはずです。
自走し続け、周りを巻き込んでいく
1から10まで全部教えてもらうような人は、良いプログラマとは言えないです。2〜3くらいまで教えてもらった後は、自分で取りに行く必要があります。それができないのであれば、性質的にプログラマに向いていないかもしれません。一人っきりで独学をしろという意味合いではなく、周りに興味を持ってもらいながら、助け合い一緒に楽しむことも大事です。
なにかに気がついたら、自分で行動する
道端を歩いていてゴミが落ちていたら落ちてるよと言うのではなく、自分で拾って捨てる。つまり、指摘するだけじゃなくて、行動で解決してあげるのがベスト。もちろん規模によっては、不可能なことはあるけど、少しでも動くことで、誰かが幸せになる可能性がある。
一番のヘタクソであり続ける
手っ取り早く成長するには、経験豊富な達人のそばにいること。考え方・行動すべてが参考になります。もし身近に自分よりも、なにかが得意な人がいないのなら（そんな環境はめったにないと思うけど）、より高みを目指して飛び込んでみよう。会社を変える・勉強会などに潜り込む・コミュニティに出入りするなんでも良いです。
なぜ／どうしてを考える
なぜこのコードは（動く｜動かない）のだろう
人に教えてみることで、自分の理解を深める
人に教えるなんてとんでもない、なんて考えていないで、試しに人に教えてみよう。結果、教えられる側以上に得るものがあるはずです。
毎日少しずつ成功体験をして、アウトプットをする
退屈な作業を楽しめるものに工夫する（競争／目に見えるものにする／より完璧に）
今やっている仕事が退屈だとしたら自分が楽しめるような工夫をしてみましょう。例えば、テストコードのカバレッジ100%を目指すとか、応答パフォーマンスや消費メモリを改善したり、スケーラブルなものに対応したり、隣の同僚と競うというのも良いです。
自作のコードをアウトプットする
一人のエンジニアとして外部から見られた時に、どうやって自分の価値を伝えますか？もっとも手っ取り早いのは書いたコードを見せることです。コードを書いてどんどん公開しましょう。
実際にユーザ体感をする
自分が書いたコードが、どっかで使われているわけですが、エンドユーザと同じように体験することで、そのコードをより良くすることが出来ます。それは実体験からくる改善案への納得感であったり、自分が作ったものが、実際には思っていたように動いていないなど。
複数の言語を学ぶ
一つのプログラミング言語を学び続けるよりも、複数の言語を平行して学ぶほうが、言語をより良く理解できるはずです。なににも影響を受けていない言語というのは、ほぼ存在しません。どうしてこういう仕様になっているのか、その背景を理解するためには、異なるパラダイムの言語を使うことです。
スモール・イズ・ビューティフル＆一つのプログラムには一つのことをうまくやらせる
小さい事による利点。すぐ分かる、すぐ動く。
複雑な引数やオプションを受け付けるメソッドは、内部で解読できないような分岐が存在しています。そんなの誰もメンテしたくないし、使いたくないです。INもOUTもシンプルに。そうすることで、複数のプログラムを組み合わせて作ることが簡易にできます。
ソフトウェアであること：早めの試作を作る
ソフトである特徴を活かし、仕様は常に変わっていきます。つまり、作るモノも変わっていきます。完璧な完成品を最初から作っていては、途中で捨てることになるし、フィードバックを得る機会も失います。分からなかったら、まず動くもの試作を作ることです。そうすることで、作るまでは気が付かなかった事が分かります。例えば、設計のミス…とかです。
良いプログラマは良いコードを書く、偉大なプログラマは良いコードを借りる
全部を自前で書き上げる必要はありません。書きたくなる衝動は分かります。でも、時と場合を考慮しましょう。世界には素晴らしいOSSや製品が溢れています。むやみにサードパーティのものを使うのも考えものですが、OSSと向き合う覚悟があるのであれば、積極的に使いましょう。
質とスピードを両立させる
仕事でコードを書いている時、どうしてもぶち当たる壁。品質向上とリリーススピード。両方を成立させるための方法を考えましょう。残念ながら銀の弾丸のようなものはありませんが、ヒントはあります。自動化とテストです。
今書いたコードと信念を疑う
本当に正しいですか？今書いたコードは間違っている可能性があります。正しいという定義にもよりますが。もっと良いコードが書けるかもしれない、そう頭の裏側で考えながらコードを書きましょう。また、自分が良いと信じているモノ。それ自体も疑いましょう。このアーキテクチャが世界最強だ！とかありえないですし、NoSQLでなんでもできるわけでもないですし、逆にRDBMSでなんでも出来るわけじゃないです。長所短所をちゃんと見極めましょう。