はじめに

この記事について

表題のとおりなんですが、私は仕事のスタイル上、1〜2年くらいで現場を移っていて、とくにスタートアップだとこうしたガイドラインの類が存在しないことがあるので、毎回（要請があれば）そのチームや状況に特化した形で書いてきました。これまではその都度イチから書いていたので、どこかにまとめておきたいと考えて、GitHub に載せておくことにしました。

github.com

補足

必要なことは README.md に書きましたが、このままだとこの記事自体が空っぽになってしまうので、重複する部分もありますが、少し補足します。

あまり需要があるとは思えませんが、CC0 なのでご自由にご利用ください。

重要なのは、そのチームや状況に応じてガイドラインの中身を最適化することです。メンバーの理解度やチームの共通認識がどれくらい揃っているか、プロダクトがどのような特性を持っているかなど、ガイドラインがどこまでの粒度でどのていどの規模必要なのかを左右する要素はいくつかありますし、なによりもチームで話し合って決めることが重要です。なので、あくまでもたたき台として使ってください。

ガイドラインがなぜ必要かというと、属人性をできるだけ排除することで、できるだけストレスなく他のメンバーが書いたコードを変更できるかとか、プロダクトの品質を揃えられるか、といった点に寄与できるのと、複数の選択肢があるときにどれを採用するかいちいち考えずに済む、という利点があるからです。

コーディング標準のように自動化されたガイドラインの場合、慣れてくるとそのうち、いちいち Linter を実行せずともそのスタイルで書けるようになるものですが、自動化してない部分であってもその作用はあると思います。自分のスタイルに固執するのではなく、チームで決めた標準に従うようにしてください。

コードとチームはチームみんなのもの、です。