そもそもコンピュータはどうやって動くのか?

私は、アセンブリ言語(アセンブラ)の仕事からはじめたので、CPU、レジスタ、アドレスバス、データバス、スタック、割り込みなどがどうのこうのとか、はたまたマルチタスクとか、そもそもコンピュータはどうやって動いているのかということから必要に迫られて学びました。
リソースなども含めマシンスペックがあがり、高級言語が常識で、オブジェクト指向とか、マルチパラダイムとか、そんな世界になった今、そもそもコンピュータでどうやって動くの?ってなことは開発者であってもはや知る必要もないんでしょうか?

たぶん知らなくても仕事はでき、十二分にちゃんと動くシステムは作れるのでしょう。特に、新人で全体の構図が見えていないで細分化されたモジュールを設計どおりに組んでいるならば。
しかし、具体的なことはともかく、超基本的な概念は知っておいくというか「理解」しておく必要があると考えています。
いずれプロセスやスレッドの話は避けて通れなくなりますし、リソースの消費量などの感覚も変わってくると思います。

開発言語の動向

人気のプログラミング言語についての情報がありますね。
たとえば ferretさんのサイトとか、TechAcademyさんのサイトとか。

ferretさんの記事はこちら
TechAcademyさんの記事はこちら

自分が今後IT業界で生き残っていくためにはどの言語を勉強しておくかということはとても気になることだと思います。

上記サイトの情報だと、

Java、C、C++、C、Python、JavaScript、php、VB、Ruby といったところで、古参の方は全部できる、あるいは全部かじったことぐらいはあるという方も多いと思います。

この中だと私の近いところという狭い範囲で一番マイナーだったのはPythonです。

これはAIでよく使わるということで広がりを見せているとか。書籍やセミナーも多いですよね。ランキング上位に入っているからあまりまえか。

今後も生き残っていくためには、仕事で使っているものの熟練度をあげるのはもちろんのこと、こういう情報に触れて、やったことがないものを学んでいくべきなのだと思います。

プログラマといえば若手

システムエンジニアといわれる人も状況によってプログラムします。小規模なシステムなら、要件の分析、設計、プログラミング、テスト、運用のすべてのフェーズを一人で行うことすらあります。
一般的なIT企業では、プログラマ、PGと言えばまず若手です。
実際にプログラムする仕事もやるとしても、中堅どころ以上はシステムエンジニア、プロジェクトマネージャなど、設計、管理系の仕事が求められます。
ある程度の年齢になれば、私はプログラマですということでは、仕事はないと考えておくべきです。

現在は高齢化が著しく、ひょっとしたら、定年後の仕事として高齢者にプログラムの仕事が多くなる可能性がなくもないかもしれません。私が知らないだけで、既にそうなっているのかもしれません。
しかし、そうなったとしても、プログラムマという役割は若手と高齢者のみで、中堅、中年層はシステムエンジニア、管理系の仕事が求められるでしょう。

やはり、早くプログラマから脱却し、システムアンジニア、プロジェクトリーダー、プロジェクトマネージャになれるよう努力しましょう。

デバッグと単体テスト

プログラマはプログラムを行ったらテストするものです。コーディングしっぱなしということはまずありません。
開発現場でいう「単体試験」までは行うのが普通でしょう。
それ以前にデバッグを行います。これは、試験仕様書に基づいて試験項目をチェックするものとは違い、プログラムが正しく動くかプログラマ本人が確認する作業で、実際は確認しながらコーディングしていくことになることが多いので、コーディングの一部とも言えます。
この作業は、自分がコーディングしたものが意図どおり動くことを見ることができる作業なので最も楽しいとことでもあります。動かないと大変ですが。。。WEB開発の場合、IDEなどのツールを使ってブレイクポイントを張りながら細かく動作を確認していきます。

こうした作業が完了し、モジュール分割の単位で、すべての機能をみたすかをチェックするテスト、すべてのパスを通ったか(カバレッジ)をチェックするテストをおこないます。このフェーズが単体テストになります。

プログラマ時代

一般的に、IT企業で開発をするならまずはプログラマということになると思います。どのようなシステムを開発するかによって使う技術は異なります。
まずは与えられた仕事をしっかりがんばりましょう。
IT企業に勤め続けるには、いつまでもプログラマというわけにはいきません。
プログラマ時代に次のステップに上がるために準備をしましょう。
具体的には、次のステップはシステムエンジニアです。
システムエンジニアの仕事は設計できることであり、設計するために必要なことを学んでいく必要があります。現場では、設計書を見ながらプログラム(コーディング)していくはずなので、設計書に記載されている用語、どういう観点で設計書が記述されているのかなど、設計書の記載内容を日ごろから意識して、何が何だかわからないという状況を徐々に変えていきましょう。
DBならERDやテーブル設計、アプリケーションの構造ならUMLなど、与えられた役割内ではもしかしたら目にしないかもしれないものでも、設計とはどういうことをしてどういう出力(設計書)を行うのかを十分意識して情報を集めておきましょう。

プログラマーの現場での心得

プログラマーは時間との戦いと言っても過言ではないでしょう。限られた時間内でいかに良いシステムを開発するかがポイントになります。残業が多いイメージもありますが、その要因はやはり客先から仕様変更等の依頼があって、予定よりも作業量が膨大してしまったり、また事前見積もりミスで実際に開発すると予想より工数がかかってしまったという感じです。

それでも、プログラマーとして期日までに仕上げる義務が有る為に、残業が発生してしまいます。あまり残業が多くなると、会社としても人件費がかかり利益が削られてしまうことになるでしょう。

となると、やはりどんな状況に陥っても、いかに限られた期間内で完成させることが出来るプログラマーが望まれることになります。その為のポイントとしては、現場の他技術者を上手く利用することです。自分の知らない効率の良さを知っているかもしれないので、技術を盗むような感じで聞いたり、また自分しか知らないことであればシェアすることも大事です。