新卒エンジニア座学#1〜#4
ペパボでのエンジニア研修が始まって2週間ぐらい経っちゃいました。 毎日新しく学ぶことがたくさんで、今最高に楽しいです。
新卒エンジニア研修はまずRails tutorialを進めていく、 というのは前回の記事でお話した通りですが、 完全にそれだけをやっているわけではなく、 毎週火・水は社内のエンジニアの皆さんが講師になってエンジニア座学というものを1時間ほどやっています。 講師毎にトピックが違っていて、どれもこれからエンジニアとして生きて行く上で大事な内容になっているように思います。
現在の段階で4回(+1)の座学あったのでまとめます。
#1 スーパーバイザーたちのキャリアキーノート
キャリアキーノートとはなにか | blog: takahiro okumura
キャリアキーノートとは何ぞや、というお話は上記のおっくん(@hfm)の記事に詳しいです。 定義を引用すると以下のとおり。
先輩の個人史 (キャリア) を紐解いてもらう中で、 その根底に一貫して流れる基本的な考え方 (キーノート) を学ぶ場
第一回座学は、エンジニア研修のスーパーバイザー！ をしてくださっている3人のキャリアキーノートです。 お三方のキーノートな部分をざっくりまとめると、次のような感じだと受け取りました。
- @Joe_nohさん
- 人にものを伝えるときに相手の心も考える
- :innocent: 絵文字な心を持つ
- @alotofweさん
- 信念を持つことが大事！ (「機械になりたい」とか←？)
- @hfmさん
- 仲間を信じる！
- 伸びしろしかないの精神
- ここぞという節目を逃さず手を挙げる
キャリアキーノートはかなり実践されている方が多く、 今回の座学に限らず今までの研修でも他の方のキャリアキーノートを拝聴する機会がありました。 キャリアだけではなくキーノートがあるのがキモで、 実践的に気をつけるべきことに気づけるのがとても学びになるように思います。
社内の皆さんのキャリアキーノートを聞くうち、自分はどんなことを語れるだろうか、ということも考えるようになってきました。 僕も永遠に新入社員なわけではないので(もちろん)、 来年度の新入社員の先輩になることも見据えて自分のキャリアとキーノートをまとめていきたいです。
#2 TDD入門
- 講師: @ku00_さん
実は僕は今まであまりテストを書いたことがないのです。 入社してからRails tutorialでちゃんとテストを書いたり、 この座学を受けたりしてテストが重要であるということの意識が高まっているような気がします。
TDDをやる理由はズバリ、「心の平穏を保つため」なんだそうです(スピリチュアルな話ではありません)。 テストが無いと何が起こるか？ 前任者しかコードが読めない、誰も仕様を把握できない、ついにはリリースが神頼みになる……なんて弊害が起きます。
特に企業でプログラムを書くようになれば、 今までのように「自分が把握していればOK」みたいな開発とも違ってくるはずなので、 他人を意識したテストを書けるように心がけていきたいです。
座学後半ではちょっとだけテストを書いてみる演習もやりました。 ↓のリンクの"お題その1"です。
とりあえず僕が書いてみたコードは次のとおり
https://gist.github.com/ry023/68413ad85e1f7025d63bd8b095e89fba
#ex 臨時座学 "もっとgit"
- 講師: @Joe_nohさん
これからずっと付き合っていくことになるGit、本当に理解できているか？ ということで、@Joe_nohさんによる臨時座学が開かれました。
実際に演習用のリポジトリを作って手を動かしながら作業
- conflictを起こしてみる
- conflictを修正してmergeしてみる
- conflictを修正してrebaseしてみる
- revertしてみる
- merge commitもrevertしてみる
3-wayマージの原理や、merge commitを打ち消す方法など知らなかったことも多く、 Gitの使い方についてより深く知れたように思います。 実際の業務でもPRがconflictする、ということが稀に生じるらしいですね。
#3 エンジニアの情報収集
- 講師: @june29さん
できるエンジニアの皆さんはアンテナの張り方が違うなぁ、と常々思っています。
エンジニアとしてどういう風に情報収集すればいいか、というお話でした。
- ツールを活用する
- いい情報を発信している人を見つける
- 自分から発信すると他の人が教えてくれる
どれも自分に足りてない部分だなぁ…と反省する気づきが多くあったような気がします。 特に人の部分、割と今までは閉じたコミュニティの中で活動していることが多くあったので、 もっとオープンな環境に出て行く必要が多くあると思いました。 発信の部分も足りてないように思うので、とりあえずブログ記事書く頻度を増やすところから始めたいですね。
#4 LGTMについて
- 講師: @amacouさん
amacou's blog — 新卒研修でコードレビューについてお話した
LGTM...Looks Good To Me. レビューが終わって問題なさそうっていうことを伝えるときによく使われるヤツですね。
実は僕は今までレビューもあまりしたことがないのです。 学生時代にETロボコンっていうコンテストでチーム開発するとき等に短期的にやってみたことがあるぐらいで、 ガッツリとレビューの良し悪しまで考えることはなかったように思います。 研修でRails tutorialを進める際、 同期同士でレビューをしあいながら進めているのですが、ここにきてちゃんとしたレビューの難しさを感じてきています。
そんなコードレビューについての@amacouさんの講座ですが、 レビューにはバグやセキュリティホールを見つけるだけではなくざっくりと次のような効果があるとのお話でした。
- 責任を共有する
- 属人化をなくす
- コードの質を上げる
あとはPRを出す人は、まとめてデカいのを出すんじゃなくて細かく逐次出していくことが大事だというお話もありました。 PRがデカいと読む人の負担も大きくなって、「うわぁレビューか…」って辟易してきてしまうらしいですね。 小さいPRの方が書く方も読む方もレビューポイントがわかりやすいんじゃないか、と個人的にも思いました。 Rails研修でデカいPRを出してしまったせいでバグが見逃されそうになったことがあったので……
レビューもテストのお話で感じたのと同様、 これから企業で開発していく上で注意して改善していかなければならない部分だと思います。
