READYFOR Tech Blog

READYFOR のエンジニアブログ

10年近く1つのサービス開発続けて「こうしとけばよかったな」と思う細かなTips

f:id:toyoc:20201203180624p:plain

こんにちは!READYFORで主にバックエンドエンジニアをやっております、toyocです!
この記事はREADYFOR Advent Calendar 2020の10日目の記事です。

さて、年末ということで、みなさまも色々と振り返る季節ではないかと思います。
私も振り返りますと、業務委託としてREADYFORに長年関わっておりまして、10年目の今年に改まって社員として入社しました。 (エモい振り返り

そんな中、今までのサービス開発を思い返すと、あの時こうしとけばよかったな〜〜〜、みたいなことがちらほらでてきました。(以下、サービス開発を、特にWebサービス開発のことを指すものとして読んでください🙏)
ということで、これからサービス開発始める人or始めたばかりの人に役立てられそうなものをTipsとして紹介します!

前置き

あの時こうしておけばな〜みたいな話ってよくあると思うんですが、大体は言われる方からすると、「わかるけどそんなことやる暇なくない??」というものになりがちです。 なので、今回は下記の前提条件を設けて厳正な審査を自分の中で行いました!

前提条件

  • サービス開発始めたばかりで、これから大きくしてくぞ!という人向け
  • サービス開発始めた時点でやる分には負担が少ないこと
  • (今から取り組むには若干手遅れなこと…)

この前提条件に則ったもので厳選した結果、以下の4つのTipsになりました!

Tips

サービス名や自社住所は定数化しておこう

これは特にエンジニアの方向けのTipsです。

みなさんの大事なサービス名、いろいろなところに書きますよね?
ヘッダー、フッター、サービスの説明ページ、自動メールの署名欄、各種規約類などなど…地味にいろんなページに載せることになると思います。
しかし、このサービス名、しばらくしてから変えることがままあります。そんな時に一つ一つ置き換えしていくのはサービスが大きくなればなるほど大変ですよね。
そんな時のために、早いうちにサービス名はソースコードの中で定数化しておきましょう!

かくいう弊社も、今まで2回、地味に名称変更しています。

f:id:toyoc:20201209075343p:plain
READYFOR? → Readyfor → READYFOR
さすがに READYFOR? はもうほぼ見かけないですが、Readyforはたまーに見かけたりします。

もし、サービス名は絶対変えない!という方でも、オフィスはどうでしょう?
サービスが成長したり、コロナのような予期せぬ事態が起きたときなどオフィスを引っ越すことはありそうですよね。
オフィスの住所もサービス名と同様にいろんなところで使われると思うので、せめてこちらだけでも定数化しておくことをおすすめします!


機能の追加・修正をいつ誰がやったか残るようにしよう

これ以降はエンジニア以外の方でも役立つTipsになります!
サービスの開発をどんどん進めていくと、月日があっという間に過ぎて行きます。半年前にどこを改修したか、あの機能が先だったっけ?このデザイン変更はまだやってなかった?と、やったことは覚えてるけどいつ誰がどんな経緯でどういう役割でやったか、みたいなところはだんだん忘れていってしまいます。

理想で言えば、いつ誰がなぜこの仕様で機能やデザイン改修を行ったか、みたいなドキュメントが残ってると後から入ってきた人にはとてもありがたいと思います。 しかし、特に初期の頃はほんの数人で始めてたりするので、「今は自分たちでわかってるから大丈夫」「そんな細かくドキュメント書いてる暇ないよ」なんて思う方もいるかもしれません。たしかにしっかりドキュメント書くのって人によっては時間かかってしまうし、それも大事だけど早くサービスを作りたい!って気持ちになったりしますよね。

それならばせめて、あとから思い出せるような取っ掛かりとなる記録を残しておきましょう。具体的には機能のリリース日などをカレンダーに随時入れておくのをお勧めします!

例えばREADYFORでは「プロダクト開発カレンダー」を作って、各自がこの日にこの機能をリリースする、という予定を入れています。

f:id:toyoc:20201210080249p:plain
(GitHubのPRやissue番号とともにリリース予定を各自でつけています)
さらにカレンダー内に関連するリンクを貼っておいたりすると、後から見る人のとっかかりとなるのでベターです。


GitHubのissue書くときに検索しやすいようにキーワードいれとこう

こちらも↑のTipsと同じような話で、後になってから、このリニューアルってどこまでの機能追加をやったんだっけ?とか、あのプロジェクトっていつごろからスタートしてたんだっけ?みたいなことが気になったりすることがあります。 そんなときに探しやすくするために、issueのタイトルや内容に後々キーワードになりそうな文言をいれておくと便利です。

例えばキーワードをタイトルに入れておけばこんな感じでわかりやすいですよね。

f:id:toyoc:20201210082502p:plain
(SEO対策ってなにやったっけ…?みたいな時にぱっと検索しやすいようになってます)


リンクを貼りつつ引用かスクショも貼ろう

GitHub issueやドキュメントを書く際に、「経緯の書いてあるSlackはこちら…」とか「旧仕様はこのドキュメントです…」など、今それを書いているサイトとは別のサイトへリンクを貼ったりすることがあると思います。

それ自体はあるとわかりやすいし、後から見ると助かるんですが、チャットツールやドキュメントツール、ToDo管理ツールなどは別のサービスに移行することがままあります。(理由としては、機能がもっとリッチだから…とか、コスパが良いから…とか色々あると思います)

そうなった時に、今まで貼っていた移行前のサイトへのリンクを全部移行後に張り替えるのって現実的ではないですよね。 なのでリンクを貼る時は、ついでにスクショやコピペをついでに引用しておくのをお勧めします!

f:id:toyoc:20201210104033p:plain
GitHub のコメントにリンクを貼ってる図。スクショも載せた方が単純に読みやすさが増しますよね。


後書き

ということで、地味目ですがじわじわ効いてくるかもしれないTipsいかがでしたでしょうか。
現在READYFORはどんどんエンジニアが増えおりまして、今まであったものを掘り返してより良く新しくしていく動きがあちこちで起こっております。 そんな中でふと過去の経緯とかを振り返る時に「こうしとけばよかったなー」と思ったことを書いてみました!

明日はREADYFORの要素セレクタ警察として名高い neripark さんです!お楽しみに!