いつにもなく抽象的なタイトルですが、久々の投稿。
webシステムを構築する際に実装方針はある程度あると思うけど、
- 開発初期と後期で色々変わる
- 変更したいけどテストが不十分で治すのが怖い
- 本当はもっといい書き方があるけここだけ治すのもちょっと
などの理由で一貫性のあるコードを書くのは実は難しかったりするのではないかと。
実装方針が明文化されてないために迷いながらコードを書くのも生産性に悪影響ですよね。
前提
- ここでいう実装方針とは開発する上で何をどこに書くかみたいなやつ
- ある特定の言語やフレームワークに依存する話でもない
- 品質も定義が難しいけど、ここではお客さんが求める品質ではなく開発者的にとりあえず実装方針に準拠してるか否かみたいなので定義
目標
新規メンバーのオンボーディングや、引き継ぎの際に実装方針をちゃんと話せるようにできるところを目指してる
実装方針は極力言語化してwikiに残す
実装をしていく過程でよい書き方が見つかったとか、実は今まで書いてたコードが書き方は世の中的に良くないとか、
変数名の付け方が人によってはよって揺らぎがあるとか、レビュワーがいればあれですが、
レビュワーも人間なので設計方針が変わったりすることもあるのではないかと。
ので、テックリードなりアーキテクトな人は常に自分が思う設計方針をwikiなりに言語化しておくのがよいかと。
このwikiは開発初期に書いてもいいですし、開発中もどんどん更新して良いかと思います。
これは悪手だったとか、筋悪だったとかそういったものも見つかるだろうし、開発中期でようやくドメインが表層化してくることもあるかと思います。
このときテストがちゃんとかけてることが前提になりますが、方針が更新されたら過去のプロダクションコードも見直していく、
みたいなフィードバックループが回せればなんでこうなったみたいな現象も減らせるのではないかなと。
ワタシはgithub wikiに思ったことや気づいたこと、良かったことを逐一更新するようにしてます
自分の設計に自信が持てない時は誰かがに多様なことやってるリンクや記事を引用して自信を持つ。。。！
そもそも書かなければ方針とか考えなくてよい
自分で頑張って書いたコードは実はFWでそれ簡単に実装できるよとか、ライブラリで解決できるよとか結構あるかと思います。
これ実はFWで簡単に解決できるんじゃね？とかメソッドオーバーライドすれば済む話だったりとかとか、実は実はコールバックで振る舞い変えられるとか、常に自分のコードに疑いをもつことは大事かなと。
テストコードも書かなくてよくなったり、負債が減るのでそういったところで生産性を高めていきましょう。
結果、そもそも実装しないという方針になり、生産性が向上する。。。はず。
テストからのフィードバック
開発後半に差し掛かると既に開発したプロダクションコードやDBのテーブル名を変更したい(しっくりくる用語が見つかった)とか出てくると思います。
主にプロジェクトの序盤で要件定義が不十分だったり、設計フェーズに時間がかけられなかったり、ドメインエキスパートとのやり取りもそんなに時間かけられないなど、
正しい設計を完璧に行うのは難しい気がしてます。
ので開発中に設計が変更になってもテストコードがあれば躊躇なくリファクタリングできるので、よりよい実装方針に追随していくためにはテストは欠かせないかなと思います。
特に知見のないフレームワークとかだと想定と振る舞いが違うとか、これはテストしにくいコードだから設計を変えようとか(時にはmockで頑張る)、実装方針へとフィードバックを行えます。
テストが正しい実装へと導いてくれる。。。はず。
CIは早めに導入してレビューをしやすく
昨今CIの導入の敷居はものすごく下がったので、早めに導入しちゃいましょう
テスト、テストカバレッジ、静的解析、コーディング規約チェックなど、運用時入った場合にも心置きなくCDできるようにしておきましょう
筆者はCIがこけるとちゃんとテストが機能してるぜい！ってなるので逆に喜びます
あと、この書き方はヤベーとか機械的にチェックしてくれてたり、コードカバレッジもテストがたりてないところが定量的に見れるので、早期に導入しておくとチーム内で書き方が統一されたり、レビューポイントが設計周りにとかに注力できるので楽です。
中盤に導入すると面倒なので序盤にさくっといれちゃうのが良いと思います。
まとめ
フリーランスや個人事業主でも小さいチームを作って開発をすすめることは多々あるかと思いますが、
事前に決めた方針通りにすすめるのではなく、常にアップデートをかけてよいフィードバックサイクルを回していくことが大事。。なはず。