2019-09 → 2020-03 - cidermitaina

仕事について

去年の9月にSmartHRのフロントエンドエンジニアとして転職をしました。 3月で入社して6ヶ月になるので、少し振り返ってみようかなあっと思って書いています。

入社してからの3ヶ月

はじめてのお仕事は、比較的小さいアプリのフロントエンドリニューアルのお仕事。

既存のrailsアプリにReact, TypeScriptを入れて、作り直しました。

私にとっては、はじめてのReact, TypeScriptでとても刺激のある3ヶ月でした。

やったことは、

既存railsアプリにWebpackを入れてフロントエンドを切り分けた

既存のRailsアプリにReact, TypeScirptを入れてフロントエンドリニューアルをする際に、最初に悩んだのが、 Reactを入れる、動く環境を作るためにはどうしよう？

でした。　

webpackerをいれる
自分でwebpackを用意する
上記以外の何か別の何かの方法...?

上記3つの方法を検討していたのですが、

フロント部分の細かな設定がしたい
webpackerだと
- 細かい設定が大変
- webpackerの学習コストやwebpackのバージョンアップについていけないことが辛い
他のプロダクトと設定を統一したい

という理由から、自分でwebpackを用意し、フロントエンドを切り分けることにしました。

React, TypeScriptで作り直す

はじめてのReact, TypeScriptだったので、慣れるまではとても時間がかかりました。。。(しんどかった…)

苦労したところは、はじめてやることなので時間がかかるでした。

なので、

↑の本を読んだり、先輩に教えて貰ったり、ちょっと早めに出社して勉強したりしながらやっていました。

UIのコンポーネント化

もともとスタイルははscssで書かれていたのですが、フロントエンドリニューアルにあたって、Styled Componentsを使用することにしました。

Reactはコンポーネント・ベースでUI開発することに特化したJavaScriptライブラリなので、個人的にはコンポーネント単位でcssを管理したく、コンポーネント単位でスコープが生成されるStyled Componentsで書き直すことにしました。

他のプロダクトもStyled Componentsなので、統一したかったっていうのも理由のひとつです。

UIのコンポーネント設計部分はAtomic Designを採用しました。フロントエンドリニューアルするプロダクトは開発人数が少ないため、UI設計の共通認識が持ちやすそう、またメンテナンスしやすいUI開発がしたいと思い採用しました。

こちらもはじめてのStyled Components、Atomic Designだったので、

↑のdocsを読んだり、Atomic Designの本を読んだりしてました。

Ruby on Rails

フロントエンドのリニューアルなので、あんまりバックエンド部分は触ることはなかったのですが、どうしても修正しないといけない箇所があったりで、コードを読んだり、修正したりしてました。

railsはあんまり得意ではなく… 事前にその話をしていたので、先輩がすぐに助けてくれたり、丁寧に教えてくれたりしたおかげで少しだけrailsのこと理解できた気がします。（たぶん）

入社してからの4ヶ月目~今

今年に入ってから、新しいチームに配属になりました。

以前やっていたプロダクトよりも大きいプロダクトで技術スタックはRails, React, TypeScript、そして半年ほど専任のフロントエンドエンジニアがいなかったチームです。

フロントエンドエンジニアの人数が少ないので、チームのフロントエンドエンジニアは私一人だけです。

私一人で大丈夫かな、私で大丈夫なのかなって不安がたくさんあったのですが、チームのみんなは、困ってるとすぐに助けてくれたり、いっしょに悩んでくれたり、とても心強く、楽しく開発できています。

今のチームに入ってからやったこと＆やっていることは、

tslintをやめた

TSLintは現在非推奨になっています。

なので、TSLintはやめて、eslintに変更しました。

既存のUIをSmartHR UIに変更

SmartHRには共通のコンポーネントライブラリSmartHR UIがあります。また、SmartHRにはたくさんのプロダクトがあり、プロダクトによっては少しUIが違っていたり、カラーが違っていたりしています。プロダクト間でのUIの統一をし、多くの人に使いやすいと思ってもらいたいので、既存のUIをSmartHR UIに変更しています。

（まだ途中で、置き換え作業中です。）

フロントエンドの問題点の洗い出し

しばらく専任のフロントエンドがいないプロダクトだったので、フロントエンド部分のコードを良くしていきたい、底上げをしたいと思っています。

フロントエンドのコードに関して

どんな問題点、課題があるのか、
将来的にどうしたいのか

を洗い出しました。

↑を踏まえてフロントエンドの技術顧問の方に相談したり、先輩に相談したり、チームのみんなにも共有して協力してもらったりしています。

jsのts化

もともとjsで書かれていたのですが、以前チームにいたフロントエンドの先輩が半分以上TypeScriptにしてくれていました。

ですが、まだjs部分が残っています。。。

堅牢性をあげたいので、早くts化を終わらせたいなあと思っているので、ちょっとずつTypeScriptにしようと頑張っています。

ビルド周りの改善

以下は、私がやったことではなく技術顧問の方がやってくださりました。

以前はTypeScriptのコンパイル部分をawesome-typescript-loaderを使用していたのですが、ts-loaderに変更しました。変更することで、コンパイルの速度が速くなりました。

また、ESModulesのままwebpackに渡すようにしてTreeShakingを有効にしました。

これで本番ビルドのファイルサイズが削減されました。

// tsconfig.json
{ 
  "compilerOptions": {
    "target": "es5",
    "module": "esnext",
    "sourceMap": true,
    ...
    ...
    ...

TypeScriptコードのimport文とexport文がコンパイラによってCommonJSとして変換されるため、Tree Shakingの効果を得るためには明示的にES Modulesをコンパイルオプションで指定するみたいです。

上記2つは、技術顧問の方にPRを出していただいたのですが、私自身ビルド周りが詳しくなく…勉強になりました！

振り返り

半年を振り返ると、はじめてなことばかりで大変だったけど、出来ることが増えて嬉しい気持ちとやりがいがあります。

今やってるプロダクトのフロントエンドが良くなっていくのを感じる度に、私のフロントエンド力も一緒に成長している気持ちになっています。

入社して半年がたち、このままこのプロダクトと一緒に成長していけたらなあ、前職、現職含めお世話になった人にお仕事で恩返しができたらなあ、と日々思いながらお仕事をしています。