はじめに

今でこそ「わからないことがわからない」状況というのはなくなりましたが、新人の頃の僕はそれはそれはひどいものでした。

けれど継続は力なりとはよく言ったもので、気づけばいろいろなことが出来るようになっていました。

そんな僕が過去に教わったことや学んだことで未だに大切にしている心得の中で、特に新人時代に知っておいたら良いものをピックアップしたので紹介させてください。

１０の心得

(1)点をたくさん作ること

点はいずれ線になり、線はいずれ面になるという話です。

• 点：学んだり経験したりする工程
• 線：異なる事柄を関係づけられるようになり、それらの理解を深める工程
• 面：これまでに得たものを組み合わせ、創造する工程

最初のうちは自分が今学んでいることがきちんと理解出来ないと思います。どう役に立つのかもわからないと思います。でもそれで大丈夫です。結果的にいつかそれらは結びつきやがて何かを生み出せる力になります。

つまりなにをするにしても全く無駄にならないから、いろいろやってみよ！って話。

(2)言語は自然といろいろ身につく

プログラミング言語はひとつずつ習得していくというよりも、自分の使う言語を同時に伸ばしていくイメージです。

面白いのがある言語を使っていくと、気づけば他の言語の理解も深まっていたりします。

もし勉強している言語が難し過ぎて辛いと感じたら、興味があったり業務で使う他の言語を勉強してみるのが良いですよ。

(3)ユーザーはソースコードを見ない

住む家の良し悪しを決める時に基礎部分を見ないのと一緒で、システムを使うユーザーはソースコードなんてどうでも良いんです。ユーザーはシステムの良し悪しを見た目やユーザビリティで決めます。

新人のうちは力の入れどころを間違いがちですので、このことを頭の片隅に置いておいてください。

(4)最新 ≠ 最良

新しい技術が出てくると使いたくなるのが心情です。ただ、少し待って考えて欲しいのが、本当にその技術を使うべきなのか。新しい以外に理由が見つからないならその技術は使うべきじゃないし、例え理由があろうと他により良い技術があるのならそちらを使うべきです。

新しいものにアンテナを張ることも、勉強することもとても大事ですが、使いどころは落ち着いて考えましょう。この業界、どうせ5年後には古い技術です。

(5)まずは自分を疑う

• 人と意見が違う
• システムで不具合が発生した
• ライブラリやフレームワークが使いにくかった

上のような状況に遭遇したらまずは自分を疑ってみてください。もしかしたら自分が何か勘違いしていないか、自分のソースコードがおかしくないか、自分がそれの正しい使い方を知らないだけじゃないか。

自分は間違っていないと思っていても、初めのうちはだいたい自分が間違っています。

(6)セルフチェックは必ず行う

自分が作ったものは自分で動作確認を行ってから提供しましょう。

• コンパイルが通るか
• コンソールエラーが出ないか
• 動作保証ブラウザで動作しているか
• 正常系は問題なく動作する

全ケース動作確認をする必要はないと思いますし、セルフチェックに時間をかけ過ぎる必要もありません。
ただ、最低限上に挙げているものぐらいはチェックするのがマナーです。

動かないものや崩れているものを提供するのは言語道断です。

(7)ソースの否定 ≠ 人格否定

コードレビューの際に自分が書いたソースコードを指摘されると、まるで人格を否定されたかのように感じる人がいるらしいです。（自分は遭遇したことないです）
自分のソースコードを自分の人格と同化するまでにこだわり抜いて書いたのは素晴らしいと思いますが、指摘内容が正しい指摘なら、より良い書き方を学べたと思ってむしろラッキーと感じてください。人格否定どころかレビュアーは優しさを持って指摘しています。

と言うか、そもそもコードレビューをしてもらえる環境そのものがラッキーです。

(8)保守性とは優しさ

ユーザーはソースコードを見ていないと言いましたが、それはユーザー視点の話で、仕様通りに動いていればどんなソースコードでも良いかと言うとそれは全く別の話です。
システムは完成後もずっと仕様変更やメンテナンスで手が加わるものです。そのときにあなたが書いたソースコードをあなた以外の人が触るかもしれないし、その時にあなたは近くにいなくて当時の状況を聞けないかもしれません。

後から触る人のことを考え、読みやすいソースコードを書いたり、しっかりとドキュメントを残すようにしましょう。

(9)なるべくタイピングしない

タイピングが速い人にありがちなのが、全部タイピングしようとします。
なるべく補完機能を使ってください。だいたいの場合Tabキーを押すと入力候補が出て来ます。

タイピングをすればするほどタイプミスの確率は上がり、つまり不具合が入り込む可能性が上がります。

(10)仕様理解の近道はDBにあり

自分の扱うシステムの仕様を把握したいけど、仕様書が膨大だったり、そもそ仕様書が存在しなかったりで仕様がなかなか理解出来ない場合、まずはDBを理解する努力に注力してください。
どういうテーブルがあって、どういうデータが入っていて、どういうテーブルと結びついているか。これを理解出来る頃には仕様もほぼ理解出来ているはずです。

DBを制す者はシステムを制します。

さいごに

僕は特に不出来な新人だったので、たくさんの先輩や上司からいろいろなことを学びました。それらを思い出しながら書いていたので、懐かしくてついつい長々と書いてしまいましたが、どこかでこれらのことに共感してもらえる瞬間が来れば嬉しいです。それでは今回はこのへんで。ではでは。