Findy Tech Blog

弊社テックブログの最初のターニングポイントとなった記事です。おそらくこのシリーズが出ていなかったら、総PV数が10万を超えることはなかったでしょう。

2月末にテックブログを開設してから1ヶ月程度が経った頃にPart1が公開され、想定以上の反響があったため、Part2、Part3と続けてシリーズ化された人気シリーズの1つです。

もともとテックブログを開設した理由の1つに、エンジニア採用を強化したいという狙いがありました。

採用を強化する上で技術的な発信は重要ですが、それと同じくらい文化の発信も重要だと考えており、まずはどんなエンジニア達が働いているのかを知ってもらいたいという思いからこのシリーズを企画しました。

おかげさまで多くの方に読んでいただき、上半期のPV数の3割はこのシリーズが占めています。

内容としましては、弊社エンジニアたちの自宅での作業環境を写真付きで紹介しており、ガジェットやキーボード、デスク周りのアイテムなどが紹介されています。

ちなみに記事のタイトルですが、タイトルを考えるのに行き詰まった私がChatGPTにタイトル案をいくつか生成してもらい、その中から選んだものですｗいや〜生成AIって便利ですね！

開発生産性指標を向上させるためにやってはいけないアンチパターン

記事単体のPV数としては上半期1位の記事です。

開発生産性を向上するためにやったほうがいいことは多くの記事が発信していますが、こちらはその逆でアンチパターンを紹介しています。

一見、「そんなの当たり前やろ」と思うかもしれませんが、その当たり前をきちんと明記したことに価値があると思います。

やってはいけないことを理由付きできちんと説明できるからこそ、正しい方法を理解、実行できるのです。

開発生産性に興味関心がある方には是非一読していただきたい記事となっています。

開発生産性を上げるために開発をする前に考えていること

記事単体のはてブ数としては上半期1位の記事です。

こちらも開発生産性に関する記事で、実際にコードを書く前にやるべきこと、準備すること、考えることを紹介しています。

いかに速く、シンプルに、効率よくリリースしてユーザーに価値提供をするか、という視点で書かれており、開発において重要なポイントがまとめられています。

Findyの爆速開発を支えるテクニック

弊社は開発生産性、とりわけ開発スピードには非常に拘っています。

この開発スピードを継続し、更に速くするために弊社で実践しているテクニックをいくつか紹介しているのがこの記事です。

タスクの分解の仕方やPull requestの粒度、テストコードの考え方などをシンプルにまとめている記事となっています。

開発生産性の向上に着手したいけど何から着手したらいいのかわからない。という方には是非読んでいただきたい記事です。

Findyの爆速開発を支える「システムを守るテストコード」の実例3選

先ほど紹介した「Findyの爆速開発を支えるテクニック」の記事で紹介したテストコードに関する内容を更に掘り下げた記事となっています。

実際のテストコードを交えて、具体的にどのようなテストコードでシステムを守るのかを説明しています。

実際に読んでみると、抜け落ちていた視点などもあるかと思いますので、ジュニアエンジニアの方にもシニアエンジニアの方にも是非1度読んでいただきたい記事です。

Wallaby.jsを使ってフロントエンド開発のテストを効率化しよう

Wallaby.jsはフロントエンド開発において非常に便利なツールです。

多数のIDEに対応しており、ほぼリアルタイムに修正内容を反映しつつテストコードの実行結果を表示してくます。

この記事では、Wallaby.jsの使い方や設定方法、実際にどのように活用しているかを紹介しています。

フロントエンドのテストコードを書くのが苦手だったり、テストコードをもっと効率的に書きたい！と思ってる方にオススメの記事です。

ファインディにエンジニアとして入社していいなと思ったこと3選

実際に弊社にJOINしてくれたエンジニアが、入社して1ヶ月程度経ってから感じたことをまとめた記事です。

JOIN直後のエンジニアが弊社の開発環境をどのように感じているのか、どのような点が良かったのかなど、長年弊社に在籍している自分からは気づかない視点もありました。

弊社に興味を持ってくれている方には是非読んでいただきたい記事となってます。

まとめ

いかがでしたでしょうか？

ここでは紹介しきれなかった記事も多数ありますので、それらも是非読んでみてください。

全体的に見て、開発生産性やフロントエンド関連の記事に対しての反響が大きかったように感じます。

下半期も引き続き、これらのトレンドを追いつつも技術的な挑戦を続け、社内の文化、雰囲気なども含めてテックブログを通じて発信できればと思います。

今後とも弊社テックブログをよろしくお願いします。

現在、ファインディでは一緒に働くメンバーを募集中です。

興味がある方はこちらから ↓ herp.careers

2024-08-05

ファインディの爆速開発を支えるモノレポ管理ツール「Nx」について

2024年8月

ファインディ株式会社でフロントエンドのリードをしております新福(@puku0x)です。

この記事では、ファインディで導入しているモノレポ管理ツール「 Nx 」について紹介します。

モノレポとは
Nxとは
Nxワークスペースの作成
Nxの機能
まとめ

モノレポとは

モノレポは全てのコードベースを単一のリポジトリで管理する手法です。

monorepo.tools

コードの共通化や可視化、ツール・ライブラリの標準化、一貫性のあるCI/CDパイプラインを構築できるといったメリットがあります。また、マイクロサービスと相性が良いとも言われています。

circleci.com

ファインディでは主にフロントエンド系のリポジトリをモノレポとして運用しています。

アプリケーションとそれに関連するフィーチャー、UIライブラリがひとつにまとまっているため、複数のリポジトリを移動することなくコードを参照できます。

Nxとは

Nxはモノレポ管理やアプリケーションのビルド、テストの実行、コード生成などの機能を備えた統合的なツールです。

https://npmtrends.com/lerna-vs-nx-vs-turbo

モノレポ管理ツールは他にもLernaやTurborepoなどがあります。アプリケーション開発において有用な機能が多くあることや、コミュニティが活発で継続的なメンテナンスが見込めること、前職で導入実績があったことなどがNxを選んだ理由です。

後述する「変更検知」や「キャッシュ機構」といった機能は、Pull Requestの粒度を細かくするファインディの開発スタイルと高い親和性があり、導入当初から私達の開発を支える頼もしいツールとなっています。

大手企業でも採用事例が増えており、Nxはモノレポ管理ツールとして有力な選択肢といえるでしょう。

（個人的に推していたOSSがここまで有名になったことには感慨深いものがありますね！）

Nxワークスペースの作成

create-nx-workspace を実行するとワークスペースを作成できます。

Reactをはじめ、メジャーなフレームワーク用のプリセットもあるためすぐに開発を始められます。

npx create-nx-workspace@latest <ワークスペース名> --preset=react-monorepo --appName=<アプリケーション名> --bundler=webpack --e2eTestRunner=playwright --style=scss --nxCloud=skip

詳細は公式のチュートリアルをぜひご覧ください。

Nxの機能

コード生成

nx generate コマンドでプロジェクト（アプリケーションやライブラリ）を作成できます。

npx nx generate @nx/react:application --name=<アプリケーション名> --directory=<ディレクトリ> --routing=false --e2eTestRunner=playwright --projectNameAndRootFormat=as-provided

npx nx generate @nx/react:library --name=<ライブラリ名> --directory=<ディレクトリ> --bundler=rollup --unitTestRunner=jest --projectNameAndRootFormat=as-provided

nx generate で実行できるGeneratorは自分で作ることもできます。

ファインディではフィーチャー用のファイル一式を生成するGeneratorを作って開発を効率化しているチームもあります。また別の機会に紹介できればと思います。

変更検知

Nxはプロジェクト間の依存関係を自動的に算出する機能を備えています。

npx nx affected --graph を実行すると次のように依存関係を可視化できます。

npx nx affected --target=build のように指定すると、変更のあったプロジェクトとそれに依存する他のプロジェクトを全てビルドしてくれます。

個人的なおすすめは、npm-scriptsやCI上で実行するコマンドを nx affected ベースにすることです。

"scripts": {
  "build": "nx affected --target=build",
  "test": "nx affected --target=test",
  "lint": "nx affected --target=lint",
  ...
},

必要なタスクのみ実行されるためスピーディーに開発できます。

依存関係の管理

Nxが持つプロジェクト間の依存関係はLintルールにも応用されます。

ファインディでは、@nx/enforce-module-boundaries ルールを適用し、意図しない依存関係の逆転が起こらないように制御しています。

具体的には、各プロジェクトに次のようなタグを設定し、

{
  "name": "utils",
  "sourceRoot": "libs/utils/src",
  "projectType": "library",
  "tags": ["scope:shared", "type:util"],
  ...
}

- apps/
  - app1                (scope:app1)
  - app2                (scope:app2)
- libs/
  - app1/
    - feature-dashboard (scope:app1, type:feature)
    - ui                (scope:app1, type:ui)
  - app2/
    - feature-user      (scope:app2, type:feature)
    - ui                (scope:app2, type:ui)
  - utils               (scope:shared, type:util)

.eslintrc.json に対応するルールを設定しています。

"@nx/enforce-module-boundaries": [
  "error",
  {
    "allow": [],
    "depConstraints": [
      {
        "sourceTag": "scope:shared",
        "onlyDependOnLibsWithTags": ["scope:shared"]
      },
      {
        "sourceTag": "scope:app1",
        "onlyDependOnLibsWithTags": ["scope:shared", "scope:app1"]
      },
      {
        "sourceTag": "scope:app2",
        "onlyDependOnLibsWithTags": ["scope:shared", "scope:app2"]
      },
      {
        "sourceTag": "type:feature",
        "onlyDependOnLibsWithTags": ["type:ui", "type:util"]
      },
      {
        "sourceTag": "type:ui",
        "onlyDependOnLibsWithTags": ["type:ui", "type:util"]
      },
      {
        "sourceTag": "type:util",
        "onlyDependOnLibsWithTags": ["type:util"]
      }
    ]
  }
]

設定したルールを図にするとこのようになります。scope がプロジェクト間の依存関係、type が内部のレイヤーの依存関係を表します。

@nx/enforce-module-boundaries ルールが設定されたプロジェクトでは依存してはいけないモジュールに対してエラーが表示されます。

大規模なコードベースの管理においては、モジュール同士の依存関係の制御が非常に重要であり、こういった「かゆいところに手が届く」機能を持っていることがNxの魅力でもあります。

キャッシュ機構

Nxは一度実行されたコマンドのキャッシュを保持しており、同じコマンドが実行された場合にキャッシュから結果を再現する機能を持っています。

また、関連サービスである「 Nx Cloud」のリモートキャッシュ機能を有効にすると大幅なCI高速化が可能です。

実際にファインディでは、キャッシュの活用で毎月1,000時間以上のCI時間を削減できました。

自動マイグレーション

NxにはCodemodやAngular CLIの ng update と似たコマンドが備わっています。

npx nx migrate latest
npx nx migrate --run-migrations

nx migrate を実行すると、Nx本体と各種プラグイン、react や eslint、typescript などの依存ライブラリ・ツールがまとめて更新されます。

バージョンアップに伴うマイグレーションは手動で対応すると大変ですが、Nxでは自動化されています。メンテナンスの手間が省けると同時に属人化も抑えられるため重宝しています。

まとめ

この記事では、Nxの概要と基本的な機能について紹介しました。

Nxは単なるモノレポ管理ツールに留まらず、「開発者体験の改善」や「開発生産性の向上」といったポテンシャルを秘めています。

✨✨✨ Nxはいいぞ！ ✨✨✨

Nxはいいぞおじさんから伝えたいことは以上です。

より詳細な活用法やNx Cloudの高度な機能については、今後の記事で取り上げる予定ですのでご期待ください。

ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。

herp.careers

2024-07-23

【エンジニアの日常】これが私の推しツール！〜日々の開発を豊かにするおすすめツール〜 Part1

2024年7月

こんにちは。

Findy で Tech Lead をやらせてもらってる戸田です。

突然ですが皆さんは、開発をするうえで欠かせないツールやOSSはありますか？

キーボードやマウス、マイクといった物理的なツールは机を見ればわかりますが、他のエンジニアがどういったツールを使って効率化しているかは、その人の画面を見ないとわかりません。

そのため、他のエンジニアがどういったツールを使って効率化しているのか、実は意外と知らないということが多いのではないでしょうか？

そこで今回は 推しツール紹介 と題して、弊社エンジニア達が日々の開発業務で愛用しているツールやOSSを紹介していきます。

それでは見ていきましょう！

推しツール紹介
- 戸田
  - git-cz
  - git-cz-for-api-developer
- 新福
  - Nx
  - vscode-spell-checker
- 森
まとめ

推しツール紹介

戸田

git-cz

まず紹介したいのがgit-czというツールです。

このツールはnpmのパッケージで、ステップに沿って選択、入力を行うことでコミットメッセージのフォーマットを統一することが可能になります。

パッケージをインストールしてコマンドを実行すると、cliで次のような出力が表示されます。

hoge@fuga Piyo % npx git-cz
cz-cli@4.3.0, @commitlint/cz-commitlint@19.2.0

? Select the type of change that you're committing: (Use arrow keys)
❯ feat:       A new feature 
  fix:        A bug fix 
  docs:       Documentation only changes 
  style:      Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) 
  refactor:   A code change that neither fixes a bug nor adds a feature 
  perf:       A code change that improves performance 
  test:       Adding missing tests or correcting existing tests

ここでコミットの種類を選択します。

機能追加、バグfix、ドキュメント修正などの選択肢を選び、その後にコミットメッセージを入力すると、自動的にコミットメッセージが作成されます。

選択肢だけではなく、コミットメッセージの内容を入力するステップもあり、全部のステップを通ると自動的にコミットメッセージが作成されコミットを実行します。

hoge@fuga Piyo % npx git-cz
cz-cli@4.3.0, @commitlint/cz-commitlint@19.2.0

? Select the type of change that you're committing: docs
? What is the scope of this change? (See README for more details; e.g. project name): piyo
? Write a short, imperative tense description of the change: (max 188 chars)
 (13) update readme
? Provide a longer description of the change (press enter to skip):
 
? Are there any breaking changes?: No
? Does this change affect any open issues?: No
✔ Preparing lint-staged...
✔ Running tasks for staged files...
✔ Applying modifications from tasks...
✔ Cleaning up temporary files...
[test-git-cz aaaaaaa] docs(piyo): update readme
 1 file changed, 1 insertion(+), 1 deletion(-)

弊社では各リポジトリに導入しており、コミット時に実行することでコミットメッセージのフォーマットの統一を行っています。

フォーマットが統一されているため、リリース時のリリースノートを自動生成したり、リリース内容の分類を自動で行ったりすることが容易になります。

git-cz-for-api-developer

git-czをForkして、API開発者向けにカスタマイズしたものもあります。

こっちのツールを利用してコミットメッセージを作成することで、SemanticVersionに対応したコミットメッセージを作成できます。

hoge@fuga Piyo % npx git-cz-api
? Select the release type of change that you're committing: patch:      patch update
? Select the type of change that you're committing: ✏️ docs:       Documentation only changes
? Write a short, imperative mood description of the change: 
  [-------------------------------------------------------------] 49 chars left
   patch-docs: update readme
? Provide a longer description of the change:
  fix hoge fuga
? List any breaking changes
  BREAKING CHANGE: 
? Issues this commit closes: 
[git-cz-test aaaaaaaaa] patch-docs: ✏️ update readme
 1 file changed, 1 insertion(+), 1 deletion(-)
hoge@fuga Piyo % git log
commit aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (HEAD -> git-cz-test)
Author: test <example@gmail.com>
Date:   Wed Jun 26 17:27:10 2024 +0900

    patch-docs: ✏️ update readme
    
    fix hoge fuga

弊社ではAPIを提供しているリポジトリで導入しています。

コミットメッセージのフォーマットが統一されているため、SemanticVersionに対応したリリースノートを自動で作成し。major updateがある場合に一目でわかるように仕組み化しています。

興味がある方は是非試してみてください。

新福

フロントエンドTech Leadの新福(@puku0x)です。好きなツールを発表します。

Nx

一番は何と言っても「Nx」です。社内のフロントエンド系のリポジトリのほぼ全てに導入しました。Nxのコア機能自体はフレームワーク非依存であるため、バックエンド系のリポジトリに導入される日もそう遠くないでしょう。

元々は前職でCRAに代わるツールを探していたことがきっかけで触れるようになりました。今ではCI高速化に欠かせない存在となっています。Nxはいいぞ。

余談ですが、Nxで作成したプロジェクトには、VS Code拡張として「vscode-jest-runner」が推奨されています。

ファイル単位でテストを実行できるので、Wallaby.jsと同じぐらい重宝しています。

Wallaby.jsをどのように活用しているか気になった方はこちらの記事もご覧ください。

vscode-spell-checker

VS Code拡張については他にも「vscode-spell-checker」がオススメです。タイポの検出に一役買ってくれます。