後悔を供養するために書いています。
最初からパイプライン作っておけばよかった
あとからCI/CDパイプラインを導入しようとしても余力がなかったり、偉い人を説得しなきゃいけなかったりして現実問題けっこうハードル高いので、最初からどさくさに紛れて導入したほうがよかったです。(=パイプライン・ファースト)
パイプライン自体は最初は雑な設計で良いと思います。とにかく導入さえしてしまえば後から改善可能なのでこちらの勝ちです。
ドキュメンテーションしっかりしておけばよかった
ドキュメントが整備されていないとサービスのスケールに比例してコミュニケーションロスが大量発生します。パイプライン同様後から整備しようとしても時間なんてありません。
- モノを作る前に仕様のドキュメントを書く(ドキュメント駆動)
- 口頭じゃなくてドキュメントでやりとりする(ドキュメントコミュニケーション)
がめちゃくちゃ大事です。最悪READMEだけでも良いのでつべこべ言わずに書きましょう。
コードとドキュメントは一緒に管理しておけばよかった
上のドキュメント書きを頑張ったところで参照しにくいと本末転倒です。
おすすめはコードとドキュメントをGitで一緒に管理することです。なるべく両者を近い場所に置いておくことで参照しやすくなります。
参照しやすい状態なら多少は編集のモチベーションも上がりますから、ドキュメント駆動がうまいこと回ってくれて、一生更新されない化石ドキュメントの発生を抑えることができます。
最悪バージョン管理さえできればそれぞれ別のシステムで管理しても良いっちゃあ良いんですが、やはり面倒なのでgitが一番です。
テストコードを書いておけばよかった
当初はあまりテストコードもオブジェクト指向も、もちろんTDDもあまり知らずとりあえず動けばいいやの精神で書いてましたが、後々になってそのままコードの規模が拡大していき、堅牢性のなさに怯えながらストレスフルな日々を過ごす羽目になりました。
テストコードを書けばついでに他人にその意図も伝わるので、引継ぎの意味でも書いておかないと損です。
ただしテストコードを書くのに慣れてない人だと進捗が悪くなって(本人が)精神的に辛くなってくるので、慣れるまでは上級者によるアクセラレーションが必要です。(理想的にはペアプロですが、小一時間通話するだけでも十分かと。)
アジャイルをきちんと解釈すればよかった
私はマネージャーではないし、当初アジャイルをあまり知らなったという言い訳をしておきつつも「包括的なドキュメントよりも動くソフトウェアを」の後者に傾倒しすぎて品質を疎かにしてしまったことは大きな反省点のひとつです。
たしかにとにかく短期間で動くモノを作るというのはアジャイルの基本的な精神ではあると思うのですが、べつに「包括的なドキュメントを軽視する」なんて一言も言ってないですし、「左記のことがらに価値があることを認めながらも」ってちゃんと書いてあります。
(アジャイルソフトウェア開発宣言: https://agilemanifesto.org/iso/ja/manifesto.html)
そして個人的には
「包括的なドキュメント」≒「なくても動くけど必要なもの」
と解釈していて、それはドキュメントだけでなくテストコードやCIその他の仕組みなんかも含んでいるんじゃないかと思います。
とりあえず動くモノを作り終わって放置するのではなく、後のスプリントでも、たとえビジネス上優先すべきタスクがあったとしても、少しでいいので継続的に育ててあげることが大切であると学びました。
最後にひとこと
負債解消頑張ります🩷
Discussion