お疲れ様です。
現場・プロジェクトに参画するようになって２年目のエンジニアです。
基本的な学習状況は下記
・Java 1年
・Javascript 現場で使うようになったのは3ヶ月目
・HTML/CSS 普段の勉強でちょこちょこ。 実質5ヶ月目くらい
・PHP 現場で使うようになったのは2ヶ月目
・Kotlin →IT'S NEW!!! っていう状況です。
今回、ちょうど2年目になったので、1年間でやってきた失敗を反省しつつ
あのときはああすればよかったんだなーと、答え合わせ含め
なんらか参考になる方法ところがあればいいなと思い書いてます。
###環境構築編
現場・プロジェクトに入ってまず最初にやるとおもいます。環境構築。
#####これがまぁ大変。
なにが大変って現場・プロジェクトによってさまざまなんです。設定が。
基本的にEclipseとかNETBEANSとか
最近だとVISUALSTUDIOCODE（エディタみたいなもんですが）とかINTELIJとかありますが、
いま上がっただけで4つあります。
これ＋ 使用する言語・フレームワーク・ライブラリも変わってくるので
（ライブラリはあまり意識しないところ「も」ありますが、重要です）
本当に設定するのに1～2日かかります。
そこで私がやった大失敗。
####1.入れるブランチとリポジトリ間違えた
そこでは参画するプロジェクトに応じてリポジトリが分かれていたのですが、
何入れたらいいですかね？→「これ入れとけばいいよ～」と従って入れたら
フェッチ・プルに1時間待ちの上に、まぁ入れるリポジトリが違う。
このメソッドなんだけど～って言われて検索しても出てこない。
そりゃ出てこねーわな。
いま思うと、使うリポジトリ、ブランチ、把握した上でやりゃよかったなぁ。と
激しく後悔。
####2.環境構築したやつぶっ壊した
これは未だに恥ずかしくなるし泣きたい気持ちがありますね。
PCがかなり重かったのもあり、いろいろと設定（Eclipse.ini）をいじくってしまったのです。
あとは、なんかあっても再インストールすればいいか～と思っていろいろ消したら。
#####結果Eclipseが起動しなくなった
使ったことあるかたならわかると思いますが
Eclipseって重いうえにダウンロードに時間かかるんスよ。
復旧に1日かかって、スケジュールに遅延をもたらしたっていう黒歴史。
・最初はわからないうちはいじくるのをやめよう。
・いじるにしても、メモリのところだけを過去の文献みながらにしよう。
※未だに調べながら指差し確認しながら設定変えるときはやっている。
・あとちゃんと設定ファイルのバックアップでもコピーでも何でもいいから残しておこうな。
####3.Gitであれこれ起きて気づくのに時間がかかった
これはGitを使うようになって間もない頃のこと。
未だに仕方がないと思える面もありつつ、気をつけようと思う所存。
Gitの既存のリモートリポジトリをA、ブランチを仮にA’としたとき
A'に別の方がプッシュしていて、そのブランチを使ってね～と
言われていたのでそのA'ブランチを使用。
※この時点ではコミット履歴を見て、予めブランチのログを見て、
「ああ、このブランチで合ってるな」と確認。
######ただし、この時点でこのブランチはこのリポジトリにプッシュされるブランチでは無かった。
どういうことかというと、APIを入れておくリポジトリがあったのですが、
API1、API2と似たような名前で置いてあったのです。
######結果、このブランチが切られた時点でそもそも間違ってた
※本来はAPI1の方にあるべきブランチだが、API2の方に切られてた。
むしろどうやったんだ
気づいたのはさて、プッシュして帰るか～とプッシュした後。
「ん？なんか今おれ違うリポジトリにプッシュしなかった？」と思い確認したところ。
急いでGoogle先生に GIT PUSH 取り消しの方法 と調べました。
その後はちゃんと正しいリポジトリにプッシュしてきれいにしましたが
あのときは背中に冷たいものが流れました。
※後日談として、先にブランチ切ってくれた方の
NETBEANSのプッシュの設定やら分岐の設定やらがいろいろと
ごっちゃになってたのがそもそもの原因でした。
教訓として、
・IDEの設定は気をつけよう。
特にGIT周り。破壊と混沌のもとです。
・GITでミスっても焦らずに。
究極、コミットもプッシュもやり直せるので。
むしろ焦ってgit reset --hard HEADとかを連打される方がやばい。
…まだまだあるけど胸が痛いのでこのへんで。
###実装・設計編
###1.設計でものの見事に外部設計書と違うものを作った。
これもいまだになぜああなったのか、悔しくも恥ずかしくもある。
外部設計書にget～～～っていうメソッドがあって、
「ふむ、このメソッド呼んで既存の処理を上書けばいいんだな」と思っていて
レビューに出したら
#####そのメソッド呼ばない
#####しかも、既存の処理の上書きじゃないし、新規に作るメソッドを作る処理だった。
死にたくなった。翌日出勤したくなかった。
これは本当に勘違いでもあるし、ちゃんと理解していない状態で設計に入った戦犯。
これ以降「今の説明を聞いてこういう認識ですけどこういうことであってますか？」
「今の設計って、この処理と分けたほうがいいですよね？」とか
細かく聞くようになった。調べた上でわからないものはちゃんと聞こう。
自身の認識の方向性があってるかもすごい疑うようになった。
未だに近隣の人には迷惑をかけているかもしれないが、
実装後に迷惑かけるより遥かに良いだろうと思っている。
###2.コピペで失敗した。
既存の処理を新しく作るクラスに持ってきたいんだが、
いろいろとごちゃごちゃしたクラスなので、使える部分を持ってこようとした。
######結果、規模がでかすぎてファイル何個作ったかわからなくなった。
BEANとかUTILだけで10個くらい作ったんじゃなかったろうか。
これは最終的に一つ一つ紐解いて、必要な処理を持ってきて、
新規で作るクラスにふさわしい処理を書いて泣きながらやった。
本当にこのときはコピペの害悪を知った。
#####安易なコピペはやめよう。
処理はしんどくても一つ一つ書いたほうがいい場合もある。
（もちろん使えるところをちゃんと理解した上で使うのは問題ないとおもいます）
ただ、理解もしないまま使うのは本当に本当にやめよう。
修正すらもできなくなる。後々困るのは自分なのです。
#####3.リアルなコーディングでの失敗
もうそろそろ胃が痛いので箇条書きで。
######・NULLチェック忘れた
→これは引数に必ず数値がわたってくること前提で考えてて
NULLだった場合Exceptionないしはエラーを吐かせるという処理を
すっかり忘れて、テストやって気がつくという失態。
二度とパラメータチェックを忘れない。
#####・DBから取れる型と、実装で想定している型を間違えた
これは正直、私のせいではないと思っているものの、
気をつけたいなと思っているところ。
DBのテーブル定義書を読んで設計したにもかかわらず型が
設計段階ではDATE型だったのがいざ実装に入るとDATEではなく、INTEGER。
to_dateすればいいっちゃいいんですが、どうやら
######テーブル定義書が古かった
もうね。Gitでfetchしてちゃんと最新にしてた俺の苦労。
これに関してはもうどうしようもないですが、
諦めないで型変換に気がついてよかった。
######漏れていても諦めない心は重要。
もうそろそろ胸が痛いし、
穴があったら入りたくなってきたのでこのあたりで。
皆様本当にご迷惑をおかけしております。
引き続き、頑張っていく所存ですので心を広く教えていただけますようお願いいたします。
心から。切に願います。