テストがない会社とドキュメントがない会社

thumbnail

どうも、フリーランスエンジニアとして働き始めて 1 ヶ月が立とうとしている tsu-nera です。

今日は、前の会社と今の会社の開発方式があまりにも違うことに戸惑いを覚えつつ、その内容を思うままに書きました。

ドキュメント vs テスト

簡単に概要を説明すると、前職はドキュメントはあるがテストコードがなく、 今の職場はドキュメントがないがテストコードがある、ということです。

両方あればそれはあるに越したことはないですが、 工数の関係からどこかを犠牲にするか割り切る必要があると思います。

前職: ドキュメントはあるがテストはない

前職は、ガチガチのシステム構築のエンジニアでした。

ウォータフォール形式。

上流のほうから、開発計画書、基本設計書、機能設計書、構造設計書という面々とした仕様の連なりがある。

さらに私の部署は、CMMI なるものに取りくんでいて、レベル3だかレベル4だかの環境だったので、 プロセスとドキュメントにはことさ厳しかった。言ってみれば、理想的なウォータフォールだ。

そのかわり、テストコードはありまない。まったく書かないというわけではないのだが、 組み込み開発ということもあり、実機がつかえれば実機で試した方が圧倒的に効率的であるため、 そちらをみんな選ぶ。実機が使えないときは、シミュレータやテストを買いて検証したりした。

現職: ドキュメントはないがテストはある

そして現職は、イケイケベンチャーの Web 開発。

アジャイル形式。

働き始めてから、仕様書っぽいものは見たことがない。 打ち合わせのためにつくった断片的な資料と、要件がかかれた GitHub Issue たち。 私は、この 1 ヶ月は、Issue にかかれている範囲の要件をみたすような実装とテストをしていた。

ドキュメントはないが、テストコードはある。基本的に、テストコードを買いてプロダクトコードと一緒にコミットして、 CircleCI でのテストと GitHub 上でのリーダのレビューを経由しないと、PR を master ブランチにマージできない。

仕組みとしてテストを書くことが前提のプロジェクトなので、コードもテストも綺麗。

前職のよいところ、悪いところ

よいところは、やっぱりドキュメントをしっかり書いてレビューをすることで品質を高めていくところ。 ドキュメントがあれば、開発や機能の目的、仕様や構造が決まっていて、情報共有できる。

品質が悪ければ、品質施策として仕様書をレビューすることで、仕様の漏れによるバグを潰すことができる。 バグは、コードの単純ミスって結構すくなくて、どちらかというと仕様の考慮漏れのほうが多い。

また、ドキュメントがあれば、新規参加者はプロジェクトに参入しやすい。 このプロジェクトはなんの課題を解決するのか、そしてどんな仕様でどういう設計になっているかが分かる。

また、仕様書をベースに機能分割したり、役割分担ができる。設計がしっかりしていれば、下流の人を仕事を分担できる。 前職では、優秀な Java エンジニアの協力会社さんのひととペアになって機能を開発したのだが、 わたしがひたすら機能仕様書や構造仕様書を書きまくり、もうひとりがそれにしたがって実装をするという黄金タッグによって、 短期間で比較的大きな機能を完成させることができた。

しかし、前職のわるいところは、テストをあまりかかないし、けっこうコードレビューが適当にされていた。 これは前にも述べたが、組み込み開発だからかもしれない。テストを書き継続してメンテナンスをしていくという意識はまったくない。

使い捨てのテストコードを書くこともあるが、メンテナンスはされない。 実機を利用することで想定外の挙動をすることが多すぎるので、実機が使えるならば実機を使ってしまう。 プログラミングの挙動が分からない場合は、まず実機にきくのが手っ取り早かったりする。

現職のよいところ、悪いところ

現職は、テストコードとコードレビューを重んじる。テストありきの文化が浸透している。

Rails 開発なので、Ruby は型つき言語ではないため、結構すぐに壊れるらしい。 なので、コンパイルをするようなのりで、テストコードも当然書く。

さらには、CI/CD の文化もあり、静的解析や CI によるテスト実行の仕組みがあり、コード品質は高い。

しかし悪いところは、仕様書がない、ドキュメントを文化に乏しい、というところだ。

それによって、なにが起こるかというと、私みたいな新規参入者は、開発対象の理解が意味不明に苦しむ。

直近の話で、今はあるシステムの機能改善を行っているのだが、 そもそもこのシステムがなにを解決するために作成されているのか、知らない。 システムのアーキテクチャ、専門用語やドメイン知識的なものもわからない。

ただ、issue に書いてある不具合修正を淡々と行っていく。 レビュー依頼をすると、ここの部分にも修正が必要だよと指摘をうけるものの、 そもそもそこの部分で使われてる用語の意味も、役割、影響範囲もわからなない。

まとめ

どちらも一長一短ではある。最大の論点は、メンテナンスの工数にあると思う。

前職はもっとテストコードかくべき。現職は最低限のドキュメントが欲しい。