良いプログラマになるにはどうしたらいいでしょうか?この難しく泥臭い課題について論じた2016年のブログ投稿「8 Ways to Become a Better Coder」の抄訳です。

少し前の記事ですが、根強い人気記事の一つです。


そろそろ本気を出して、プログラミングのスキルアップを目指すタイミングかもしれませんよ!

キャリアアップの目標として「めっちゃすごいプログラマになるぞ」と言うのは簡単ですが、ゴールまでの道のりは単純ではありません。まず最初に「もっと上手くなりたい」というためには「もっと上手くなる」ということについて認識していなければなりません。そこに到達するための方法を考えずに、キャリアアップを目指してしまっているかも知れません。

そこで、あなたのプログラミングスキルを向上させるためのフローチャートとして、8つの実用的なガイドラインを紹介します。これはコンピュータ業界の35年間の歴史における先人の知恵であり、その多くはソフトウェア工学を文書化て定義したごく一部の人々の足元で、下等なキリギリス(訳注: いつでも潰されたり餌にされたりする危険のある存在、という意味でしょう)として生き残ったものです。

1. 学ばなければならないことを思い出そう

何かを学ぶ上での最初のステップは、自分が知らないということを認識することです。当たり前のように聞こえますが、経験豊富なプログラマーは、この個人的な思い込みを克服するためにどれだけの時間が必要だったかを覚えているでしょう。数多の計算機科学の学生は、「自分が一番よく知っている」という傲慢さと、「自分は何でも知っている」という強固な確信を持って卒業し、新しい同僚にそれを証明しなければならないという強烈な必要性を感じています。言い換えれば、あなたの「自分が何をしているか知っている!」という態度は、何か新しいことを学ぶ場面では邪魔になるということでもあります。

2. 己の正しさを証明するのはやめよう

単に良いプログラマにとどまらず、優秀なプログラマになるためには、経験から学ばなければなりません。でも、ちょっと待って!経験は、悪い行動を繰り返したり、悪い習慣を作ってしまうこともあります。8年の経験を持つプログラマがいたとします。もしその人が、毎年同じことを8回繰り返しただけだったら…。このような症状を避けるには、「どうしたらもっと良くなるだろう」と自分自身で問い続ける必要があります。

初心者のソフトウェア開発者は、長年の経験者だったとしても、自分が書いたコードの素晴らしさを語るために、自分のコードを使います。テストコードは、テストを失敗させるようなことをせず、コードが動作することを証明するためだけに使います。真に優秀なプログラマは、自分たちが間違っている箇所を積極的に探します。そうすることで、最終的にユーザが遭遇するかもしれない欠陥を見つけられる近道であるということを知っているからです。

3. 「コードが動いた」というのは、終わりではなく始まりである

はい。最初の一歩は常に、仕様を満たした良い品質のソフトウェアを書くことです。並のプログラマはそこで仕事を終わりにして、次の仕事に取り掛かります。

しかし、「できた」と思って止めてしまうのは、ある時点でのスナップショットを残して、それを芸術作品のように扱うようなものです。優秀なプログラマは、最初のイテレーションは始まりでしかないことをよく知っています。コードが動いた!おめでとう!でも、そこで終わりじゃない。そこからより良くしよう!

このプロセスで重要なのは、「より良い」とは何なのかを定義することです。より速く動く?ドキュメントが充実してる?再利用性が高い?信頼性が高い?答えはアプリケーションの状況によりますが、どこに価値があるのか検討することは必要です。

4. 3回書く

良いプログラマは動作するソフトウェアを書きます。一方、優秀なプログラマは、とても良い感じに動作するソフトウェアを書きます。それは、最初の試みで実現することはほとんどありません。最高のソフトウェアはたいてい、3回目に現れます

  1. 1回目は、自分自身(またはクライアント)に、解法が実現可能であることを証明するために、ソフトウェアを書きます。他の人はPoC(Proof of Concept)だと認識しないかもしれないですが、書き手はそのつもりなのです。
  2. 2回目に、とりあえず動くようにします。
  3. 3回目に、正しく動くようにします。

このレベルの仕事は、トップレベルの開発者の仕事ぶりを見ても、よくわからないかもしれません。ロックスターな開発者がやっていることはすべて素晴らしく見えますが、見えていないところで、1番目と2番目の作品を捨てているはずです。コードを捨ててやり直すのは、「より良い」を実現するための強力な方法になりえます。

そうでなくても、「3回書く」というのは課題へのアプローチが複数あることを気づかせてくれます。そして、惰性に陥ることを防ぐことができます。

5. コードを読んで、読んで、読みまくる

あなたは多分、このアドバイスがあるだろうことを期待していたと思いますし、実際、コードを読むことはプログラミングスキルを向上させるための一般的な方法であり、最短な方法の一つでもあります。でも、理由はあまり知られていないかもしれません。

他の人が書いたコードを読むことで、その人がプログラミング上の課題をどうやって解決したかを知ることができます。しかし、小説を読むのとは少し異なります。それは教訓とチャレンジを読み解くものなのです。次のようなことを考えながら読むのがコツです:

  • このコードブロックは、自分ならどう書くだろうか?別の解決策を見た今、あなたならどう違うことをするだろうか?
  • そのコードから学んだことは何だろうか?過去に書いたコードに応用できるテクニックはあるだろうか?(「そこで再帰下降を使えるなんて、思いつかなかった…!」などなど)
  • このコードを改善するにはどうしたらよいだろうか?それがオープンソースプロジェクトで、より良い解法を思いついたなら、貢献しよう!
  • 著者のスタイルでコードを書いてみよう。これを実践すると、ソフトウェアを書いた人の頭の中を垣間見ることができ、共感力が上がります

これらのステップをただ漫然と考えてはいけません。個人的な日記であれ、ブログであれ、コードレビューのプロセスであれ、他の開発者とのコミュニティフォーラムであれ、あなたの答えを書き出してください。友人に問題を説明することで解決策を整理するのに役立つのと同じように、自分の分析を書き留めて共有することで、なぜ他人のコードに特定の方法で反応してしまうのかを理解するのに役立ちます。これは、先に述べた内省の一環であり、自分の強みと弱みを冷静に判断するのに役立ちます。

警告: 偉大なプログラマーになることなくコードをたくさん読むことは簡単です。多くの開発者は、オープンソースや他のソフトウェアを見て「答えを見つける」ために、そしてほとんどの場合、同じような問題を解決するように見えるコードをコピー&ペーストするために見ています。そうすることで、あなたは実際にはより悪いプログラマになることができます(夏のピクニックよりもバグが多いかもしれません。取り込むコードを読むことすら惜しむとしたら、あなたはバグ製造器をペーストしただけだと気づかないでしょう)。

6. コードを書くことは、ただの担当の割り振りではない

個人のプログラミングプロジェクトに取り組むことには、多くの利点があります。一つは、現在の仕事では使えないツールや技術を学ぶことができ、次の仕事に向けてより市場価値を高めることができるということです。オープンソースのプロジェクトに貢献したり、コミュニティでのボランティアの仕事を引き受けたりすることで、技術的なスキルと自信を身につけることができ、自分の技術力を証明することができます(さらに、あなたが学習を止めることのないセルフスターターであることを雇用主にアピールすることができます)。

楽しむためにコードを書くことのもう一つの利点は、自分で物事を解決しなければならないということです。難しいからと言って他の人に任せることができないので、すぐに助けを求めることがなくなります。

プロのコツ: 個人プロジェクトを選ぶ場合、失敗を避けてはいけません。失敗は必要です。失敗を防ぐのは、失敗が許されない仕事や、デッドラインがある仕事のときだけにしましょう。

7. 他の開発者とペアで仕事する

他の人の意見に耳を傾けるのは良いものです。ペアプログラミングをしたり、ハッカソンに参加したり、Vermont Coders Connectionなどのプログラミングのユーザーグループに参加するのもいいでしょう。オープンソースプロジェクトに貢献するときは、ユーザーや他の開発者からのフィードバックに注意を払いましょう。彼らの批判にはどのような共通点があるでしょうか?

幸運にも、コーディング技術からキャリアの決定に至るまで、あなたを指導してくれる信頼できる個人的なメンターを見つけることができるかもしれません。このような機会を無駄にしないでください。

8. ツールを学ぶのではなく、テクニックを学ぶ

プログラミング言語、ツール、方法論はどんどん変わっていきます。だからこそ、できるだけ多くの言語やフレームワークで経験を積むことが大切なのです。プログラミングの基本に集中しましょう。基本はそれほど変わるものではありません。プログラミングよりもアーキテクチャに注意を払ってみましょう。何かをするためには正しい方法が一つしかないと思っているなら、それは現実を確認するときかもしれません。ドグマ(宗教上の教義)は新しいことを学ぶ能力を妨げ、変化に適応するのが遅くなります。

何かを続けるのが大事なときもあるかもしれません。しかし、「いつやめるかを知る」のは、自己改善の重要な原則でもあります。

Code, learning, reading, and collaboration images courtesy of Shutterstock.com.

kotani@newrelic.com'

New Relicではシニア・カスタマーサクセス・マネージャーとして、New Relicプラットフォームを使い倒していただく係をしています。それまでは業務システム業界でSEとして7年の経験を積んだ後、広告配信サービスを構築・運用をリーダー/CTOとして8年ほど経験し、スクラッチからのアプリケーション開発、クラウド利用推進、開発組織の改善などなどやってました。よく使う言語はScala, Go。好きなビルドツールはMakeです。 View posts by .