やっぱり失敗しちゃいますよね？
- stackoverflow, Qiita記事のコピぺ
- エラーを解決できずに、数時間死にたくなる
- ゴミコードを書いてしまい、デバックで苦労する。などなど。
こんにちは！新米エンジニアのりゅうです。今日から、新年の抱負の一つである、エンジニアとしてのスキル、知名度をあげる。それを達成するためのto doとして、キータ記事の週一更新をやっていこうと思います（まだ、新年ではないのにフライングしている事はすみません笑）
記念すべき、第一投稿としましては、僕がエンジニアとして働いていた中での失敗点を列挙させていただきます。
技術的な失敗
1. チュートリアルやstackoverflow記事のコピぺ
エンジニアなら一度は経験があると思う コピペ
問題点
- コードを説明できない。
- エラーが発生した時に、なぜエラーになったのかわからない。
- コピペしたので、コードの書き方、意味を憶えない。同じ課題に直面した時にまた調べないといけない。
改善点
- ライブリー、フレームワークを使用する時は一度公式のdocumentをしっかりと読む。
- エラーが発生した時にstackoverflowなどで解決策をしらべるのはいいが、なぜ、それがエラーになったのか、どのように解決したのかをしっかりと理解する。
2. 雑なエラーハンドリング、ログを残さない。
独自エラーの作成が一番めんどくさくないですか？
問題点
- ログを書かかないと、コードが長くなった時にどのコードの前後にエラーが発生して処理が止まったのかがわからない。
- エラーをしっかり書かないと、チーム開発の際に、発生したエラーが無視していいものなのか、そうでないのかがわからず無駄に時間をかけてしまう。
改善点
- 複雑or大事な処理を行う際はlogを残すようにする。
- 発生したエラーに対して、どのようなエラーなのかを簡単にざっくりと理解できるようなエラーメッセージを残す。
- Not implementedを使用する。
3. 型を指定しない、docsを書かない
docsを書くのめんどくさいですよね。
問題点
- 型を指定せず、関数の引数を定義する。
- docsを書かかないで関数を定義すると、どのようなデータを入力して、何が帰って来るのかがわからないので、エラーになった時、解決に時間がかかる。
- 複雑な関数の場合、理解するのに時間がかかる。
改善点
- 常に型を指定する(Typescriptの使用など）
- Docs generatorを使用して、短時間にわかりやすいdocsを書く。
精神的な失敗
1. 質問を怖がる
質問するのって勇気がいると思いませんか？
問題点
- エラーが発生した時など、質問するのを躊躇って、無駄に時間を消費してしまう。
改善点
- とにかく、具体的でわかりやすく、解決方を提示しやすい質問を作成して、質問をする相手が嫌がらないような質問をする。
- 勇気を出す。
2. 100点のものを最初から作ろうとする。
完璧を目指したいですよね...。
問題点
- 時間がかかってしまう。
- 自分の視点で完璧なものは他の視点から見た時に完璧でないことが多い。
改善点
- 70点のものができたら、一度feedbackをもらうようにする。
- 一度に完璧なものを作るのではなく、徐々に完璧にしていくようにする。
#最後に
拙い文章ですが、以上で締めたいと思います。最後まで読んでいただきありがとうございました！
本当に僕個人の反省点のまとめになったのですが、僕の失敗が誰かのやく立つことを祈っています。