【プログラマーを目指す人へ】プログラミングの楽しさと難しさ

私は10年以上プログラミングをしているエンジニアです。

主な言語はC#ですが、状況によってはC++やPython、Matlabなど別のプログラミング言語も書くことがあります。

そんな状況なのでプログラミングの楽しさや難しさを肌で感じる日々なんですね。

この記事では、そんなベテランエンジニアである私が経験したプログラミングの醍醐味や大変なところをお伝えできればと思います。

これからプログラマーを目指そうとしている方や、プログラミングに興味のある方の参考になれば幸いです。

プログラミングの楽しさ

プログラミングを楽しいと感じるときはこんなとき。

• 書いているだけで楽しい
• プログラムが意図したとおりに動く
• 複雑なコードの簡略化
• 通勤・通学中にプログラミングのことを考える

書いているだけで楽しい

まず、コードを書いているだけで楽しいです。

これはプログラミングに限らず、子供の頃に初めて自転車に乗るのと同じことです。初めて何か新しいことに挑戦したときって楽しいですよね？

プログラムが意図したとおりに動く

自分の書いたプログラムを動かすときのドキドキ・ワクワク感というのは、プログラミングの醍醐味でもあると思います。

例えば、自分で料理を作った後に食べるとき凄く楽しみですよね？そして、とても美味しいと感じたときは嬉しさも感じるでしょう。

プログラミングも同じで、自分の意図通りにプログラムが動くと凄く優越感に浸ることができますし、嬉しい瞬間でもあるのです。

複雑なコードの簡略化

プログラミングしていると長くて複雑なコードを書かざるを得ないときがあります。

そういったときはとても気分が萎えるのですが、改めてリファクタリング(コードを見直して改善すること)すると複雑だったコードが大幅に簡略化できたりします。

そういったときは、まるで難しい難問を解けたかのような嬉しさがこみ上げます。

ちなみに、リファクタリングの作業はとても重要なので、定期的に自分が書いたコードを見直す習慣を付けましょう！

これをするだけで、プログラマーとしてのレベルが上がります。

通勤・通学中にプログラミングのことを考える

これは前述の「複雑なコードを簡略できたとき」に繋がってくるのですが、私もそうですが、私の周りでは意外と仕事以外でもプログラミングのことを考えているエンジニアが多いです。

そして、なぜか仕事以外のふとした時に良いコードを思い付いたりすることがよくあります。

どうしたらもっと良いコードが書けるか考えている時間はとても楽しいですよ。

もちろん、仕事に追われているときはそんな流暢に考えていることができませんが、基本的には　「考えている時間=楽しい」です。

プログラミングの難しさ

• 何から学んでいいかわからない
• 納期が間に合わない
• 突然の仕様変更が加わった
• システムに最適な言語を選択する
• 他人のコードを保守
• 古いシステムの対応

何から学んでいいかわからない

私もそうでしたがプログラミングって何から学んでいいのかわかりませんよね？

プログラミングにおいて正しい勉強法というのはありません。

一番オススメしない方法は、参考書を買って丸暗記しようとすることです。

昔はネット上の情報も少なく教材が必要になる場合もありましたが、今ではネット上に情報が溢れていますから、参考書を買う必要はありません。

そして、プログラミング言語も日々バージョンアップを繰り返しているので、購入した参考書の情報は既に古かった、なんてこともあります。

最新情報がすぐに手に入るネットを活用しましょう。

progateやドットインストールといったオンラインの動画教材もあり、無料で受けられるものもあります。

あるいは、最近ではGitHubに様々なソースコードが公開されているので、他の人が作ったコードをシャドーイング(真似る)することもできます。

シャドーイングはピアノと同じでやればやるほど上達しやすいため、オススメの練習方法です。

納期に間に合わない

趣味レベルの話しでは納期なんて気にする必要はないですが、仕事としてプログラミングしている以上は当然納期が発生します。

納期が間に合わないと調整が大変です。

もちろん、力技でプログラムを作ってしまうこともありますが、たいていは機能を削ったり検証を他の人にやってもらったりと、周りの協力を仰がないと仕事が進みません。

プログラミング中は自分の世界に入れて楽しい半面、仕事では周りと協調しないといけませんから余裕を持って計画的に作業するようにしましょう。

突然の仕様変更が加わった

少なくとも私の会社ではあるあるです。

仕様を出すべき企画部門が機能していないばかりに、開発部門に設計まで丸投げされることがしょっちゅうあります。

そして最後の最後、あとはシステム検査して終了というところまできて、今まで大人しかった企画部門から突然茶々が入って大幅な仕様変更なんてことも珍しくありません。

これに関しては外的な要因が大きいことは間違いないです。

しかし、いついかなる変更が加わってもある程度は対処できるようにコーディングしておくことを心掛けましょう。

また、定期的にリファクタリング(コードの見直し)することで、こういった突然の仕様変更にも対応できるようにもなります。

システムに最適な言語を選択

プログラミング言語1つですべての分野に対応させることは不可能です。

プログラミング言語にも向き不向きの分野というものが存在するのです。

例えば、Windows系のプログラムであればC#が得意とする領域ですし、AIやディープラーニングならPythonです。

このようにシステムに最適な言語は必ずあって、うまく適切な言語を選択できないとこのような問題が出てきます。

プログラムを書き始める前には自分で判断しないでベテランのプログラマーに事前確認する習慣を付けましょう。

他人のコードの保守

他の人のコードというのは基本的に見にくいです。

まず、何がどこに書いてあるのかがわからない。

そして、コードを編集した影響範囲の規模が完全に把握できないところが難しいです。

ただし、綺麗なコードを書く人のコードを見たときは、とても見やすくて感動します！

他の人のコードを見るということも勉強になるのでメリットもありますが、たいていの人はそこまで綺麗なコードが書けていないため保守するのは大変です。

古いシステムへの対応

社会人エンジニアであれば多くの方が苦しんでいるのは「古いシステムの保守」です。

製品のライフサイクルが短ければあまり気にすることはないですが、長い場合はレガシーシステムにも対応できるような設計を考慮しないといけません。

例えば以下のような状況です。

• WindowsXPにも対応
• 32/64bitのドライバを両方対応
• 古いインターフェースを流用

私の担当製品はライフサイクルが長いので、レガシーシステム対応はとても苦労する項目の1つです。

そのため、新しいFrameworkやAPIが使えないこともしばしば起こります。

このような場合は、プログラミング以前に調査に膨大な時間が掛かったり、がんばってプログラミングしたけど結果動かなかった、といったことも起こりえます。

解決方法としては先にも挙げたとおり先輩エンジニアやベテランの方に意見を仰ぐのが得策です。間違っても自分ひとりの判断で進めないようにしましょう。

まとめ 

何事もそうですが、プログラミングにも楽しさ/難しさがあります。

大変なことも多い職業な反面、やり遂げたときの達成感は表現が難しいくらい充実したものがあるのもプログラミングの醍醐味だと私は感じます。

これからプログラマーを目指そうとしている方がいましたら、この記事が少しでも道しるべになれば幸いです。