「納品のない受託開発を支える レガシーコードを作らない仕組み」を読んで

Team

って言ってたら

コメントを頂きました。ありがとうございます。僕のはてぶコメントが曖昧に取れるので、先にスタンスをはっきり言っておくと。このスライドいいなぁと思ってます。

どんな数字が知りたいと思ったか

  • プロジェクトの規模とかチームの人数とかメンバーのスキルってどれくらいなんだろう？
  • レガシーコードを作らないようにするためにどれくらいの時間をかけてるんだろう？

って感じです。そして、これって「具体的な回答をください！」とは思っていません。知りたいなぁってだけです。なので、勉強会などでお会いした時にちょっとお話ができたら嬉しいなって思います！

プロジェクトの規模とかチームの人数とかメンバーのスキルってどれくらいなんだろう？

コンテキストを知りたいです。1人のプロジェクトなのか、5人チームなのか、10人チームなのか、で、レガシー化を止める方法が違いそうだなと。

1人プロジェクトなら、自分が気をつけてれば大丈夫だし。5人チームで全員がスキル高い場合はプルリクエストでレビューでもしてたら良さげかなと思ったり。5人中2人はまだ育ててあげたいメンバーだったりするとペアプロするかな？と思ったり。

もし4,5人でチームを組んでるとして、相互レビューってところ、同じチームのメンバーにレビューしてもらうのか。それとも違うプロジェクトをやってるメンバーの中でスキルの高い人と相互レビューしてるのか知りたい。

プロジェクトのタイプも知りたいなぁ。お金を複雑に扱うのか、大量なトラフィックをさばくタイプなのか、社内システムなのかとか。それによっても変更に対する難しさが違いそうだから、どんなタイプでどういう対応をしてるのかなって知りたい。

それと、レガシーコードを作らないってことだけど、この話の対象は新しく立ち上げたサービスなのかなぁ。既存のシステムを引き継いで開発を始めたケースとかにはどう対応してるのかなぁ。とか。

そういうコンテキストが知りたいなと。

レガシーコードを作らないようにするためにどれくらいの時間をかけてるんだろう？

レガシーコードを作らないようにするためには、インフラやミドルウェアのバージョンアップとかもそうだし、継続的な改善もしていかないといけないと思うのですが。どれくらいの時間をそれに当ててるんだろう？と思いました。CIしてるからインフラとかのバージョンアップに対しては時間かからないとか？そういえばインフラのコードもCIしてるのかなー？

お客さんには「xx％は改善に当てます」みたいな話とか、実績の報告はするんだろうか？それとも、全部まるっと含めて「今月の開発」としてしまうんだろうか？それとも「改善」ってものは「レガシーコードを作らない」から不要なんだろうか？いや、でもお客さんと一緒に要件を発見していくタイプの場合、新しく発見した要件のことを考えると半年前に作ったものが足を引っ張るわ！とかないのかな？

とかそんな感じ想像してワクワクしてます！

すごい面白そうな開発だなー。