元教員のエンジニア2年目です。
最近は腰痛と闘いながら業務に励んでおります。
ちょっと大変だったことを徒然書き示しておきます。
既存のコードが一番の先生
現在Laravelの案件に入って５ヶ月ほどが経ちました。
初Laravelでキャッチアップもほぼない状態でアサインされました。
ただ以前やっていたJavaに比べ、個人的にはキャッチアップコストがかからず、「思うように動く実装」に持っていくのはそこまで大変ではなかったです。
ただ、あくまで動く実装に持っていくだけであって、そこからが試練でした。
前述した通りほぼキャッチアップがない状態でアサインされたため「既存のコードが一番の先生」
しかし、
- 処理が不明瞭
- 責務がぐちゃぐちゃ
- PHPDocがない
- 型定義がちゃんとされてない
- スパゲッティコード
等不十分な箇所がたくさん。
そのため、一番の先生を参考にして行った実装だと修正依頼がたくさん・・・・
「何を参考にすればええの？」
と独り彷徨っておりました。
現在はほんの少し慣れた気がするのですが、自分みたいな彷徨い人を作らないようにするため書き示しておきます。
感覚で書くな
「なんとなくこうやって書きました」
と感覚的に済ますことも可能です。
それで動いちゃったりするのですから。
しかし後で他人が見直したときに必ず疑問が生じるはずです。
私がいた学校現場での昔話です。
学校の授業で「感覚的に〇〇だから」っていう説明ばかりしている先生の授業は平均点低かったです。
きっと「あなたの感覚と私の感覚は違う！」ってなるのでしょう。
書いたことについてちゃんと理由とともに説明できること
これが重要だと思います。
チームで必要なこと
１人１人が自信を持って書いたコードでも、考え方の差から統一感のないものになる可能性があります。
それでは私みたいな経験浅い新人がアサインされたとき
「どの書き方が正解？？」
となってしまいます。
そのため
チーム内で書き方のルールが統一されていること
これが必要ではないかと思います。
このルールは「なんとなくこう思うから」と推量ではなく「この理由だから」と断定で説明できるルール作りにより、統一感が出るのではと思いました。
理想のコードを目指して
理想のコードってなんだろう？と考えたとき、口頭でちゃんと説明できるものだと思います。
決して「なんとなくこうなっっていて・・・・」ではなく、
１メソッドが短編小説みたいな感じですらっと読めるのがいいですよね。
わからないことが多い中の作業はどんな作業であっても、誰にとっても大変なものです。
「動けばよし」
そんな風に思うかもしれません。
しかし誰かの為になると考えれば、ちょっと前向きになれるのではないでしょうか？
そんな実装ができるように日々精進します。