はじめまして、新卒エンジニアのrikuです。4月に入社し、はや３ヶ月が経ちました。そろそろ4ヶ月に近づいております。
開発現場に入り、2ヶ月が経とうとしております
本日の内容は、私が2ヶ月開発に携わった所感を元に書こうと思います。
必ずしも「これが正しいから気をつけろ」というつもりもないですし、間違っているところもあると思います。
⚠︎これは所感です。（大事なことなので二度いいます）
そして、今回上げることは、私自身まだできておりません。
自分の戒めとして半分書いておりますので、エンジニアの先輩方がこの記事を読む場合は、温かい目で読んでいただけたら幸いです。
それでは本題の方に入っていこうと思います。
- 1. 変数名や関数名には気をつけよう
- 2. 悩みすぎには気をつけよう
- 3. 自分の勝手な解釈で進めるのはやめよう
- 4. 仕様書、要件定義はできるだけ読み込もう
- 5. 仕様書と要件定義に差異があれば迷わず聞きにいこう
- 6. 時間を意識しよう
- 7. 自分の書いたコードは説明できるようにしよう
- 8. リーダブルコードを読もう
- 9. 結論から話そう・説明しよう
- 10. プルリクはしっかり書こう
- 11. 人の書いたコードを読もう
- 12. プログラム以外も覚えておこう
- 13. コマンドはどこかにメモを取っておこう
- 14. ショートカットを覚えよう
- 15. 聞きにいく前に話を整理しよう
- 最後に
1. 変数名や関数名には気をつけよう
変数名、関数名、クラス名の名前は意味のある名前をつけましょう。
変数名を他の人がみた時、後日自分がみた時にこれがなんなのかを簡単に理解できるかどうかが、いい変数名かどうかの判断材料になります。
次にみた時に、わからない名前なら変えた方がいいと思います。
実際に私も経験があり、すぐに名前を変更しました笑
良い変数名の付け方は後述する「リーダブルコードを読もう」で少し紹介します。
2. 悩みすぎには気をつけよう
悩むだけに1時間とか取らないようにしましょう。そんなに時間を使ってもきっと解決しません。
そんな時は、すぐに先輩に聞くか上司に聞きましょう。すると、すぐに問題が解決します。
自分の悩んでいた1時間はなんだったんだって感じになります笑
「でも」と思う方いると思います。たしかに、自分で解決した時の達成感、成長した感は尋常じゃありません。しかし、その使った時間分だけ他の人はいろいろなことを経験しています。
悩むことも大事です。悩まないと成長しませんから。だけど、悩みすぎはやめましょう。
悩みすぎはどこからかという方いると思います。正直新卒の私にはわかりません。ですが、自分である程度見切りの時間は決めることができると思います。
私の場合は、長くて1時間、短くて30分ほどの時間を設けております。上司や先輩に時間を設けてもらえることもあると思います。言われたら言われたその時間いっぱい悩む、調べる時間にしましょう。
3. 自分の勝手な解釈で進めるのはやめよう
これものすごく重要です。
実際に体験したは話なのですが、私が勝手な解釈で開発を進めて、プルリクを送りました。上司の期待通りに動作せず、これじゃないよと言われ再開発になりました。
これの何がまずいかというと、開発時間が伸びることです。その機能を作るのに期間が設けられます。その機能の開発期間が伸びてしまうと、そのあとの他の機能の開発に影響が出てしまいます。
最悪、全体のスケジュールを再調整しなくてはいけない場合があります。そうならないように、実装中に疑問が出た場合すぐに聞きにいくようにしましょう。（自分に言い聞かせている）
4. 仕様書、要件定義はできるだけ読み込もう
機能を作る時、何も見ずに作ることはまずありえません。
どんな機能を相手は期待していて、実現して欲しいのかを仕様書、要件定義に落とし込んでいます。それをまずは読みましょう。
自分の作る場所だけを読むのではないです。もちろん自分の作る機能のところは必ず読みます。ですが、それだけで終わってはいけません。
その機能が、どこで使われるのかを理解して作っていかなくてはいけません。
軽くでいいので、要件定義を全て読みましょう。そして、全体の流れを掴んで開発に取り掛かりましょう。そうすると、開発が楽しくなります。（個人の感想です）
5. 仕様書と要件定義に差異があれば迷わず聞きにいこう
仕様書ではここをこうして実装して欲しいと書かれていると思います。ただ、要件定義にはまた別のことが書いてある場合もあります。もしくは、完成図と仕様書で違う場合があります。
そうした場合、聞きましょう。ここを独自の判断で勝手に実装してしまうのはまずいです。
仕様書の方がきっと正しいのだと思うかもしれません。ですが、会議でもしかしたら仕様が変わった場合も否めません。
自分の判断では決められない場合、素直に聞きに行きましょう。そこで悩んでいる時間の方が勿体無いです。
それに、聞きに行って完成させたものが、仮に間違っていたとしても、悪いのは上司のせいです。人の責任にできるのです。（ゲス顔）
嘘です。もちろん冗談です。ですが、わからないことは素直に聞きにいくのが吉です。
6. 時間を意識しよう
開発には期間が存在します。そして、機能を作るのにも期間が存在します。一機能半日だったり、一日だったり期間は機能によって様々です。
そして、開発はコードを書いて終わりではありません。コードを書いて単体テストを行いバグがないかを確認して、プルリクを送りマージされるまでが開発です。マージまでを期間の間に終わらせなくてはなりません。
調べている時間が長くなってしまうと、その分実装する時間、バグがないかを検証する時間がなくなっていきます。設けられた期間内をどう使うかを逆算して開発を行っていくことが重要になります。
難しいことですが、時間を決めておけばいいと思います。「調べる時間は1時間かけよう」とか「わからなければ聞きにいこう」のように時間管理をすることでおおむね期間内で機能を作ることができます。
7. 自分の書いたコードは説明できるようにしよう
なんでそのようなコードになったのかをしっかり説明できるようにしましょう。
例えば、if文がネストしている説明だったり、for文がネストしている説明だったり、エラー判定のコードをそこに入れた理由だったり、書いた本人は書いたコードの意味を説明できるようになりましょう。
そして、そのコードを読み返してみましょう。きっと無駄があるかもしれません。
説明した通りに動いていないかもしれません。そのように自分の書いたコードの間違いを見つけることができる可能性が増えます。
コードにコメントを残すでもいいですし、プルリク時に残すでもいいです。なんらかの形で説明してみましょう。
8. リーダブルコードを読もう
リーダブルコードという本をご存知でしょうか。これは、より良いコードを書くための本になります。
優れたコードを書くための実践的なテクニックが数々のっている良書です。
例
＃1で前述していた「いい名前」の付け方についてです。
いい名前とは「誤解されない名前である」ことだとリーダブルコードには書いてあります。
例えば、getListこれだけ読むとリストを取得するんだとわかりますが、何のリストを取得するのかがわかりません。
もう少し具体的に書くべきです。曖昧な言葉ではなく、直感的にわかる名前をつけることが大切だとこの本を読んで知ることができました。
他にも、的確なコメントの書き方、深いネストを避ける方法、いいコードについてなどプログラムを書く上で注意するべきことがまとめられた素晴らしい本になっていおります。まだ読んだことないよという方は、ぜひ買って読んでみてください。
9. 結論から話そう・説明しよう
上司も暇をしているわけではありません。
仕事をしています。それも私たち、新卒以上の仕事量を。そんな方の時間を奪うわけです。
長々と前置きを述べられても時間の無駄です。説明している私自身も。
時間をあまり奪わないようにするために、先にことの本題を伝えましょう。
私も先にいいわけを、一言ふたこといってから本題に入るたちでした。ありがたいことに先輩にご教授頂きました。
最近は、意識して本題から入るようにしています。意識するようになって、円滑なコミュニケーションを取れるようになった気がします。
10. プルリクはしっかり書こう
開発ではバージョン管理を行うと思います。そして、自分の作ったものをマージして欲しいと、プルリクエストを申請するはずです。
その時に、しっかりと何を作ったのか、何を行ったのかを、書きましょう。レビュー者はそれがないと、何を作ったのかをわからないままコードを読んでいかなくてはなりません。
何を作ったのかをわかった上で読むのと、何を作ったのかを知らないまま読むのでは対応の早さとコードの指摘の仕方が変わってきます。
それを避けるために、相手に伝える努力をしましょう。
11. 人の書いたコードを読もう
例えば、他の人のプルリクを読むそれだけでも勉強になります。
綺麗なコード書き方、変数の名前の付け方etc...、コードから学べることはたくさんあります。
また、自分のコードと比較できます。「あ、ここの書き方は私のコードの方が綺麗にかけてる」こんなことを思った時のモチベーション上昇は計り知れません。
逆に、「ここ、こういう風にかけるんだと」気づくことができ、すぐに自分のコードに反映することができます。
同じ開発を行っているので、書かれているコードの理解は比較的に早いと思います。
ですので、読んで理解して自分のものにするにはうってつけの時間になります。
他の方のコードを読んで、技術を盗みましょう。
12. プログラム以外も覚えておこう
コードを書くことももちろん大事です。
ですが、それ以外にも大事なものがたくさんあります。
環境構築、SQLの使い方、ライブラリの使い方、他のツールとの連携の仕方、gitの使い方etc...,覚えることはたくさんあります。
これらを使いこなせるのと使いこなせないのでは、開発スピードに雲泥の差が現れます。わからなくても、とりあえず調べてそして動かしてみましょう。
とくに、SQLの使い方はやっていて損はありません。web系はSQLの扱い方が重要になってきます。開発を行う前に取り組んでみましょう。
13. コマンドはどこかにメモを取っておこう
特によく使うコマンドは、素早くアクセスでき、かつわかりやすいところに残しておきましょう。
私の場合は、スプレットシートにツールごとに分けて残しております。
短いコマンドならいいのですが、よく使う長いコマンドだったり、調べたりするなら、スプレットシートからコピペするほうが楽で効率がいいです。
いかに時間を短く作業ができるのかを考えながら作業をしていきましょう。
14. ショートカットを覚えよう
windowsならwindowsのmacならmacのショートカットを覚えましょう。
できれば、どちらも覚えておくといいかもしれません。
ショートカットを覚えるだけで開発スピードはぐんとあがります。いちいちマウスをいじらなくてすみます。
マウスを触る時間を出来るだけ少なくしましょう。些細なことかもしれませんが、「ちりつも」です。
本当に些細な時間の短縮です。ですが、確実に時間は短くなっていきます。その短くなった時間だけ他に割り当てられるようになります。
15. 聞きにいく前に話を整理しよう
先ほどから、わからなければ聞きに行こうと書いてきました。
ですが、聞きに行く前にしなくてはならないことがあります。聞きに行く前に聞きたいことを整理することです。
「すみません。ここがわかりません」この言葉を相手に伝えても、相手は何がわからないのか理解することができません。
仮に画面を見せてもそれは同じです。一旦、コードを処理を追わなければわからないです。それでは、時間の無駄になります。
そうではなく、しっかりと何がわからないのかを事前い自分の中で論理立てるのです。
今何につまずいているのか、処理の書き方がわからないのか、仕様書の行っている意味がわからないのか。いくらでも考えることができます。
自分の中で聞くことが整理ついたら聞きにいきましょう。きっと答えを知っていますから。
最後に
ここまで書いてきましたが、正直全然できていないです。なんなら、意識しないとできないことの方が多いです。
本日書いたことは、自分自身に刺さる15個であり、開発に入る前に知っておきたかったなと思ったことだったので、これをみた学生の方、新卒の方の参考になれば幸いです。
また、オススメの本がございましたら、コメント欄に是非是非お願いします！！
最後までご高覧ありがとうございました！
