新人向け押さえてほしい概念リスト

Who Are You

一応、立場表明として記載しておきます。
私は旧職業能力開発総合大学校 (ここで敢えて「旧」とするのは、小平"分校"の方でなく、相模原の方だったからです) の長期課程・電子情報システム工学科の卒業生です。
新卒でとあるちびっちゃい……なんと言えばいいのでしょう。一応請負もやるけど、殆どは派遣で稼ぐような会社 (サバ読みまくって30人規模) に入り、諸々故あって転職、"文化的な生活"というものが送れるようになった、一人の職業プログラマであります。

これといって特筆するような技能も実績もありませんが、テスト用とはいえ100台規模のネットワークを組んだり、かと思えばWebをやり、C++やVBAを読み、Android/iOSからWin10への移植に携わり、C#の (どうしようもなく悲惨な出来の) コードをいじり……と、あれやこれやと携わった「なんでも屋」です。
(一応これでも社会人4年目とかそんな程度なんですがね……)
強いて言うなら、人生の9割弱をコンピュータとともに過ごしてきたのが自慢でしょうか。

さて、この私から見た「ここを教えるべきではないか」「新人はこういうことを押さえるべきだろう」というものを、いくつか並べておきます。

なお、本文章は、これまで現場に出て見かけた (ときには尻拭いをさせられた) 「ひどい連中」を基準としています。そのため、「いやそれは……」な内容が含まれる可能性が大いにありますし、逆に「いや、本当にひどい奴らはこれ以前にこんなんもできんのだ！」というものが存在する可能性も大いにあります。あくまで参考程度にご覧ください。

プログラムは「文章」である

「プログラミング言語」というのは伊達でも真田でもありません。文章を書くから「言語」なのだ、と言っても良いでしょう。
別段面白い話でもありませんが、数学は大の得意という人間でも、プログラムは碌に書けない / 悲惨な出来上がりになる、ということは珍しくありません。

• 文章を読み書きすることに慣れておいてください。数学はほっといてもどうにかなります。
  • 少し前は「ミーティングこそプログラマの仕事」みたいな話もありましたが、ミーティングさえも「それ大抵はチャットでええやん」みたいな流れになっている昨今、プログラマの仕事は一日中文章を読み書きすることです。
  • 数学はどうにかなるといいましたが、例外として「集合演算」と「論理演算」だけは知らないとどっかでコケます。「ANDとかORとかのアレ」レベルでいいので、多少は知っておきましょう。
• 調べることに慣れてください。特に英単語は自信がなければ即調べましょう。
  • 辞書を買う必要はありません。スラングや略語は珍しくないので、大抵ググったほうがいいです。
  • 英語を話せるようになる必要はありません (日本の場合、ごく限定的な職場を除く) 。
• 読み書き中の違和感を大事にしましょう。慣れてくると、変な文章に当たった時「なんか変だな？」と違和感を覚えるようになるものです。
  • 散々言われているのに、未だに regist とか isStart とかやらかす馬鹿がいます。これらに違和感を覚えるようになれば、それだけでも「マシ」な証拠です。
• とにかくまず読みましょう。答えは、大抵何処かに書いてあるものです。特にエラーが出たときは、まずエラーをしっかり読みましょう。
• さらっと読めるように書きましょう。重要なことは、貴方の書いたものは誰かが読むということです。読んだ時違和感があれば、その分読むのに時間がかかります。

プログラムは「小さな作業の塊」である

以下は高齢・障害者求職支援機構の公開している資料です。
https://www.jeed.or.jp/disability/supporter/intellectual/om5ru8000000c5rn-att/om5ru8000000c659.pdf
これは作業分解票と呼ばれるもので、見ての通り「作業をバラし、小さな動作の積み重ねに還元する」ために存在します。漠然と全体を見るよりも、細かく裁断して並べたほうが問題がよく見えるものです。

• コンピュータはアホです。人間のようなファジーさは最近ようやく進歩してきた程度です。まずはアホでも理解できるレベルまで物事をバラすところから始まります。
• 困ったことに人間も人間でアホです。ときに意味不明なミスをします。このため、バラすことで理解しやすくするのは人間にも有益です。
• まずはとにかく小さくしていきましょう。行き過ぎは問題ですが、大抵は行き過ぎよりもやらなさすぎて死んでいます。小さくほぐして初めて見えるものは腐るほどあるのです。
• 抽象化しましょう。具体的なものの代わりに、カテゴリや特性を埋め込めませんか。例えば上記の例は「ピーマン編」ですが、ピーマンでなくてもある程度適用できる気がしませんか？「野菜」としてしまえば、別のものにも適用できるかもしれません。
• 「誰がやることなのか」意識しましょう。作業を分解した結果、それぞれの作業を別々に割り振ったほうがよくなることは珍しくありません。

プログラムは「契約」を果たす

何もかもを分解していくと、最終的にどこかへ行き着きます。しかし、その全てをバラバラに扱っていてはいくらなんでも死んでしまいます。
大抵はばらばらに分解した「作業」たちを何らかの形で「ひとまとめの作業」にして扱います。この時重要なのが**「契約」の概念です**。

「作業」に問題がなかったことを保証するためには、「検査」が必要です。
「検査」を行うためには何が必要でしょうか？「前提」と「結果」です。「結果」が「前提」から導き出される想定通りなら正常、そうでなければ異常です。

「前提」が保証される限り、「結果」を保証しましょう。おかしな結果を返すぐらいならエラーを吐いて止めましょう。これが「契約」です。
これをかっこよくいうと「事前条件」と「事後条件」、そして「例外」になります。
重要なのは、この「契約」が守られている限り、「契約」を満たすためにどういう処理をしているかは気にしなくて良い (はず) ということです。だって、「契約」の通りに動くんだから。

これが保証されると、一度作ったものを再利用できる可能性が生まれますし、他の部分の「検査」もしやすくなります。だって、その部分は「契約」の通りに動くんですから。

番外: 辛くなったら逃げよう

例えば片道3時間通勤になったとか。
例えば給与8万減らすと言われたとか。
例えば残業代がごまかされてたとか。
そういうことがあったら、さっさと逃げて転職しましょう。耐えるのは貴方だけでなく、社会全体への不利益です。
(なお、恐ろしいことに上記の3つは全て私が新卒で入った会社で経験したことです。フィクションだったら良かったんですが……)
逃げることは悪ではありません。対策の一つです。
対策を取らないことは、不適切な対策を取ることよりも邪悪です。