日々の開発tipsみたいなやつ

新規サービスをリリースするときに、seedデータを揃えることがある。
この際に直接SQLを叩いて、業務用のデータ(例えば、公開された記事 / 非公開の記事みたいにシステムの事情が入ったデータ)を作ろうと思うと、後々めんどくさい。

SQLで直接作るよりも、アプリケーションのロジックを再利用してデータ投入用のインタフェース or CLI or GUIを作った方が良さそう。

それをするためにもアプリケーションのロジックを再利用できる形にしておけると良さそうだなと思った。

ロギング is めちゃくちゃ大事。
Rails使ってた時はRailsがバックトレース込みのログを自動で出してくれたが、他だとそうはいかない場合がある。自分はGoで開発しているが、その辺りを作り込みたい気持ちで一杯になる。

なぜなら、本番実行時にどういう理由でそのリクエストが失敗したのか、すぐさま知ることができないと、バグの解消に無限に時間がかかってしまう。
それだとユーザーの便益を満たせず、ソフトウェアの目的を達成できない。
ロギングがしっかりとできていれば、問題解決の速度は数倍にもなるはず。
だから、この辺りはちゃんとやりたいと思った次第。

長過ぎるプロジェクトについて思うこと
長すぎるの定義は色々あるが、1つのサービスを出すのに、開発開始から1年以上掛かっている場合、それはだいぶ長いと思っている。

長過ぎるプロジェクトにメリットは一つもない。

• 人の入れ替わりによって発生する知識の消失
• 市場 / ニーズ / 社内の意思決定の変更による要件手戻り
• 開発チームの士気低下

などがざっくりあげられる。

こうなったときにどうするのか、難しいなと思う。

新人教育について思うこと。

• 自分で獲得してもらう
  • 自身で獲得したもののほうが身につきやすいと思う。
• Howを伝授する
  • Whatを与えるとそれ以降課題に遭遇した際に以前の経験を活かすことができない。なので、どうやってその課題を解決するかの思考方法やデバッグ方法など、それ以外の課題に使えるHowを伝える。
• 周辺のコードを読んでもらう
  • 0-1じゃない限り周辺にコードがあるので、それを読んでもらう。網羅的に技術について学んでほしいが、常に100%の状況でタスクに取り書かれることは基本ない。なので、タスクを進めるために周辺のコードを読んで、適用して、意味を調べて、PRを作り、マージする。これを繰り返しつつ、網羅的に技術勉強をしてほしい。