グロービスにバックエンドエンジニアとして参画している @ymstshinichiro です。
僕は今年の5月から本格的にGLOPLA LMSの開発にジョインしました。
本記事では、そこから今日までの7ヶ月を通して自分に起こった変化について書いてみたいと思います。
参画以前は
僕は約10年飲食の業界にいましたが、約4年前にキャリアチェンジで SIer > Web業界(社員) > Web業界(フリーランス) という流れで現在に至っており、新卒できちんと先輩から教わったとか、スクールで先生についてもらったみたいなことがありませんでした。
なので、基本的に独学でプログラミングを学び現場のコードを見ながら/直しながら覚えていくという感じでやってきており、
- 「こうあるべき」みたいなのは書籍を読んで得たものが基本
- とはいえ現場では現場のルールや状況がある
- 結果、その時々で対応していくので、背骨のある設計/実装、綺麗で汎用性の高いコード みたいなのがあまり身についてこなかった
という実感がありました。
一方で、急なトラブル対応やスピードを求められる仕様変更、古代に練り込まれたコードのメンテ、色んな意味ですごいSQLなど、アンチパターンや決して教科書通りには行かない現場でどう対応していくかみたいなことに関しては多少経験が積めたかなと思っています。
今のチームでは
GLOPLA LMSは、プロダクトの試作段階から経験豊富なメンバーが携わっており、開発当初から下記のような設計方針が貫かれています。
- 要件を定義する段階でWHYを突き詰める. 無駄なものをできる限り作らない
- Railsの持つ柔軟なコード表現を積極的に活用していく
- gemも活用＆常に新しいものを使う仕組みを回す
- 冗長になってもいいのでテストケースのコンテキストはできるだけ抜け漏れなく実装する
- その上で、shared_example等を活用し読みやすく再利用性の高いテストコードを実装する
- 時間が経過しても、実装の意図が正確に伝わる表現にこだわる
端的にまとめると「場当たり的な実装ではなく、長期にメンテナンスしていけるための設計/実装を意識したコード」を書くということになります。
そのような現場に入って、自分の意識や行動がどう変わったかを書いていきたいと思います。
全員が維持できるコードを書く
「多少保守性を犠牲にしてもリリースを優先する」というコードを書くことは許されません。(余程の事情がない限り)
わかっている情報の中で可能な限り未来を予想し、メンテナンスのコストも含め最もベターな選択肢はどこか？というwhyとhowを考えた上で実装します。
これはユニットテストに関しても同じ（というかむしろテストの精度を上げていくことが本題）で、なぜこのテストケースが存在すべきか誰が見てもわかる状態を目指すべきです。
この結果、テストのコンテキストを分割する、コミットを分ける、コミットメッセージと実装を矛盾なく一致させるなど、コード(と、PR)がどう見られるか？どうやったらレビューしやすいか？を意識するようになりました。
こう書くと当たり前のようですが、以前の僕は特にコミットの仕方に関しては本当にできていなかったですね。。。所属した現場でのルールや意識に影響されたのと、仕事以外でのOSS活動などをやってこなかったというのが大きいと思っています。
外のリポジトリに興味を持つ
以前に在籍していたいくつかの現場では、様々な理由によりあまり積極的にgemを使うということをしていませんでしたが、GLOPLA LMSではそういったことはありません。それが必要であれば積極的に使っていこうという姿勢です。
となると当然ですが、使おうとするgemが本当に我々の望む機能を有しているのか、今後の保守に耐えうることができそうかということを見極める必要が出てきます。
そのために何をするか。
これも当たり前のことなんですが、公開されているリポジトリのソースを読みに行きます。
この時、自分にある変化が起こっていることに気づきました。
以前の僕はこういう外のソース読みに行っても「んーなんかすごい複雑で読むの大変やな...」というのが先に来ていたんですが、"どう読まれるか"を意識してコードを書くようになると「どこから読んだら分かりやすそうか」の勘が働くようになるので、以前よりも全然スラスラと読めるようになりました。
また、「おっ この書き方は分かりやすくていいな」とか、現場でコードを書くだけでは中々気づけなかったテクニックを発見したりと、自分で作る楽しさだけでなく誰かが作ったものに触れる面白さというのがプログラミングにはあるんだなと、今更ながらに気づくことができました。
ちなみに、GLOPLA LMS(というか、Globis全体)の開発メンバーは日常的にOSSコントリビュートしている方が結構多いです。
これも結構珍しい現場なのでは？と個人的には思っています。
そして自分も作る
そんなこんなで開発にも慣れてきた頃、チームで使っているGithub(Zenhub)のissueチケット作成が面倒だねーという話になりました。(具体的には、全員で編集したMarkdownのファイルをベースに、チケットを手動で何枚も作り直すという手動コピペが常態化していた)
ちょうどGithubのAPI触ってみたいな〜と思っていたところだったので、Markdownをパース → JSONで固めてGithub APIに投げる、という簡単なgemを作って、初めて公開してみました。
Copyist
https://rubygems.org/gems/copyist
これまで書いてきたようなメンテナブルなコードになっているか？と言われるとちょっと怪しいんですが笑、「このツールをどこかの誰かが使うかもしれない」と思うと、少なくとも致命的なバグは起こさないようにとか、せめて説明ぐらいはわかるように書かなきゃな、とかコードを書く以外にも色んな手間ひまがあってライブラリは作られているんだなという実感があり、改めて世のOSS開発者の皆さんに感謝せねばならんなという気持ちになりました。
また一方で、作って公開することは決して特別なことではなく少し気合を入れれば自分にもできることなんだから、もっと世に貢献するようなコード・プロダクトを作って、これからも楽しみながらエンジニア生活を送って行きたいな〜と思った2021年の師走でした。
最後に
GLOPLA LMSをはじめGlobisでは一緒にプロダクト開発をするエンジニアを募集しています。
先述の通り、OSSコントリビュートを積極的に行っていますし、某有名Rubyエンジニアの方が開発に参画していたり、RubyWorld conferenceのスポンサード等、エンジニアの活動を支援する組織文化があります。
また、リモートワークや開発環境など働き方の面でも非常に過ごしやすいです。
なんといっても「プロダクトを綺麗に作っていきたい」という思いをお持ちの方、ここにはそれを受け入れる土壌があります。
ぜひ一度コンタクトいただけると嬉しいです！
自分語りな記事を最後までお読みいただきありがとうございましたmm
2022年も、皆様にとって実りと学びのある一年になりますように〜