懺悔めいた前置き(長くなってしまった）
今のプロジェクトに入るまでしばらくコーディングから離れていた。
プログラミングが苦手だったので、意図的に実装フェーズに関わらないようにプロジェクトを選んでいたので当たり前なんだけども。
なんで苦手かといえば、
- ソースが読めない
- 意図した通りにプログラムを組むことが出来ない
そんなのプログラマとして致命的だし向いてないからエンジニア辞めろ！という感じだが、 辞めず（追い出されずに、と言ってもいいかも）にこの業界に残れているのはひとえに周りに助けられてきたから。
ゴミエンジニアである自分が存在している時点で関わったプロジェクトの迷惑になっていて、それ自体は本当に申し訳ないんだけども、周りのおかげでなんとかエンジニアとして生きながらえさせてもらっていた。
前述の通り実装に不安を抱えていたので、ここ数年はテスト設計フェーズからのプロジェクトに参画していた。
いくつかWEB系プロジェクトのテストフェーズに関わり、そのままテストエンジニア（名前だけで中身は伴ってない）としてエンジニアを続けていければよかったのだけども、WEB系プロジェクトでテスト設計から関わってみて気づいたのが、自分が持つ「標準的なWEBアプリケーションに関する知識」が足りてないという実感。
今まで業務系システム（C言語でオンプレミス）ばかり関わってきていたので、WEB系は本当に門外漢もいいところ。
WEBアプリケーションの基本部分を知らないと、業務的にWEBアプリケーションとしてテストすべき観点等が 曖昧になり、テスト設計がきちんと出来てこない。 という認識が漠然とある。
知識がないので、確認すべきこと・確認しなくてもよいことの判断も出来ない。
テストとして不足していることにも気づけない。
内部の動きがわからないので、きちんと動いているかどうかをWEB画面上で表面的にしか確認できない。
もちろんWEBの知識が不完全でも、テスト設計するのは自分だけではないのでテストケースが出来上がらないということもないし、
レビューで指摘を受ければ足りないことを加筆修正することは出来るので、テスト設計自体が「まったく出来ない」訳ではない。
やはりずっと心理的に 「プログラムから離れていると不安である」ということを抱えているのかもしれない。 なので、テスト設計と併せてWEBアプリケーションの実装もさせてもらえるような条件を探してもらって今のSES先に入りこんだわけです。
今のSES先ではプロジェクト自体はいくつも並行で走っていて、
そのうちの一つに関わっている。周りにいるプログラマはそれぞれ別のプロジェクトに関わっているので、関わりは全くない（全く無関係ではないが、今のところ直接関係してない感じ）。
自分の担当プロジェクトでは、「リーダー」の下に自分だけがいるという構成になっている。久々に実装をしていて、
毎日めちゃくちゃ怒られている。
怒られているし、呆れられている。
（自分の仕事の出来なさに改めて泣きそうになっているが泣いたら終わりだと思うので踏ん張っている。）
目的と処理（手段）を分けて考える
前置きが長くなってしまったが、毎日何に怒られているかというと、
- 変数の目的・役割をきちんと理解・把握出来ておらず、曖昧な状態でわかったふりをしているから。
今更「変数」か、という感じだが、本当にそのレベルなんです。すみません。 ただこれは基本だけどすごく大事なことで、変数だろうがメソッドだろうが、クラスだろうが同じことになる。
例えば、「成績優秀な生徒の名前を表示する処理」というような以下のソースがあった場合に、 （showという名前のメソッドのくせに表示する処理がなかったり、配列一つしかないのにforループしていたり、goodというフラグを作ってフラグを立てたり無駄なコードが入ってますがお気になさらず）
var students = {"name": hime,"testResult":100}; function showStudents(students){ var good = false; var goodStudents = [ ]; for(var key in students){ if(students[key].testResult > 80){ good = true; goodStudents[key].name.push({ "name":students[key].name }) } } }
goodStudentsは成績が80点以上の生徒名が入る変数ではあるけれども、成績が80点以上の生徒名を入れるためではなく
成績優秀な生徒として表示したいから作られた変数であること
という理解が大事だと教えられている。
今まで、
studentsは生徒情報を入れる変数goodStudentsは成績が80点以上の生徒名を入れる変数
というように、「なんのため（目的）の変数なのか」ではなく「何をしている（処理）変数なのか」という読み方でコードを読んでいたし、プログラムしていた。
目的が曖昧だと「何をしているか」はわかっても「どうしたいか」の理解があやふやになる（自分の場合）。
このあたりの理解があやふやだった自分は、showStudents()を生徒名を表示する処理と中途半端に理解した気になって、
studentsとgoodStudentの役割の違いをきちんと言語化出来なかった。
ソースを修正したり、修正案を提示するたびに
- 「これはなんのためにあるの」
- 「どんな条件で変数に値を入れるの」
- 「〜したいときはどうするの」
- 「なぜここで初期化されているの」
と一つ一つ詰められている。答えられないということは理解がまだ出来てないということ。
これは変数に限った話ではなくて、関数だってクラスだってそれぞれ目的がまずあって、そのための手段をどうするかを考えるわけで、 ソースコードを読むときに目的をきちんと理解した上で読めば最終的に何をしたいのかわかる（と思う）。
小さな処理の単位で「何を目的に作られたのか」「なぜここで作られたのか」を理解出来れば どう処理を作ればいいのかも同時にわかる（実現の難易度とは別）。
ずっと詰められて頭が真っ白になってストレスでおかしくなる寸前で、 まだ消化できてなくて自分の言葉でわかりやすいようにアウトプット出来てない部分もあるけれど （わかりにくい文章だったらごめんなさい） まずは「目的」をきちんと把握するようにソースコードを読めば、理解できないこともないかなと思い始めている。
