私は趣味でも仕事でもプログラミングしていますが、趣味と仕事ではやり方を変えています。趣味でコード書くのは楽しいけど、仕事でやるとつまらないという方も、取り組み方を工夫すれば、仕事と趣味で違ったプログラミングを味わうことができます。そんなわけで「趣味と仕事のプログラミングの違いと、その切り替え方法」を紹介します。趣味の場合、好きな書き方をすればいい仕事の場合、コーディング規約や他人の書き方に合わせる趣味と仕事で手法の使い分けをしよう!何を作るか?趣味の場合、自分が作りたいものを作れる!趣味では自分が作りたいものを自由に作れます。作ってる途中で仕様を変えたくなったら自由に変えられますし、作るのが面倒臭くなったら未完成のままやめることもできます。仕事の場合、要求されたものを作る!仕事では要求された仕様のソフトウェアを開発しなければなりません。良い仕様を思いついたとしても、勝手に仕様を変えることはできません。「絶対こっちの方がいい!」と思って提案しても受け入れてもらえないこともあります。そんな時は割り切りが必要です。仕事とはそういうものであり、良い提案をできた時点でベストを尽くした時点で成功です。ベストを尽くした上で意に沿わない結果が起きた場合は、淡々と仕事として処理をすれば良いでしょう。理想を追いすぎず、現実に流されすぎず、淡々と最善を尽くす、これが正しいスタンスなんだと思います。理想と現実のギャップに苦しむ仕事に嫌気が差して、無関心になるといったことにもならないでしょう。いえ、IT業界には根本的問題があります。IT業界なのにIT素人が多すぎるきちんと考えられたビジネス要件で仕様が決められているのならいいのですが、プランナーや顧客の勘でなんとなく仕様が決定されておかしなソフトウェアができ上がる場合もよくあります。プランナーや顧客のITリテラシーが低い場合にこういうことが起こりがちです。この問題に取り組んでいる企業もあります。楽天では英語の公用語化の後、プログラミングも公用語化することが発表されました。プログラマーではなくてもプログラミングをある程度分かっていないと良いITサービスを設計することなどできないという考えからだそうです。私もこれには賛成です。プログラミングをやることによってわかるコンピュータの特性があります。コンピュータは命令した通りにしか動かないから厳密な手順を明確にする必要があるということです。プログラミングをすると、これが肌感覚で分かります。知識としてわかるのと肌感覚でわかるのとでは全然違います。場合、使いたい技術・言語を使えばいい「使いたい」といっても、いろいろあります。知っていて得意だから使いたい使ったことないからどんなものか使ってみたいどのような理由でも構いません。自分が使いたい技術・言語を使うことができます。決まっているのでそれを使うしかありません。決めるフェーズに参加できる場合があります。その場合にも、自分が使いたいという理由だけでは不十分で、その技術を使うことで、システムに求められる要件を満たせるそれらの技術を使える要員を集めやすいなどの説得材料が必要です。アーキテクチャ趣味の場合、好きなアーキテクチャを使える趣味で作るソフトウェアの場合、実験的なアーキテクチャを採用できます。うまくいかなくても困るのは自分だけですからね。仕事の場合、指定されたものか、要件に合ったもの大抵の仕事はアーキテクチャが指定されています。アーキテクチャは以下の2つに大別できます。OS・ミドルウェア等のシステムアーキテクチャライブラリ・フレームワーク等のアプリケーションアーキテクチャシステムアーキテクチャは決まっているけれどアプリケーションアーキテクチャはプログラマーが決めていいという場合もあります。いう場合にも、自分が使ってみたいという理由だけで選ぶのではなく、利用技術・言語と同様にシステム要件や要員の集めやすさ等の条件を満たしているものを選びます。趣味の場合、好きな書き方をすればいい趣味なので自分の好きなスタイルで書くことができます。仕事の場合、コーディング規約や他人の書き方に合わせるコーディング規約がある場合はそれに従った書き方をします。ない場合も他のメンバーのスタイルに合わせるようにしています。Debug.Log("Hello");}のように中括弧の前に改行を入れるスタイルのプロジェクトの場合は、プロジェクトの書き方に合わせます。他人のコードを読み、まねすることで学べることもたくさんあります。あまりに変なコーディング規約の場合は変更を提案します。あるJavaを使うプロジェクトのコーディング規約に「static変数、staticメソッドは使ってはならない」と書かれていました。「static変数なしでSingletonをどうやって実装すんだよ?」と思い、あまりにおかしな規約なので、「この規約はおかしくないですか?」と聞いたら、「あー、あれ別プロジェクトから適当に持ってきた規約だからおかしな所は変えていいよ」と言われました。合わせるだけでなく、おかしな所を見つけたらルールを改善する提案して良いと思います。趣味と仕事で手法の使い分けをしよう!趣味と仕事では、それぞれに特性があり、できることできないこと、向き不向きがあります。趣味の方が自由度が高いから全て良いってことでもありません。仕事という制約があるから、優れたソフトウェアを作ることができる面も多々あります。