  |
はてなキーワード: 回帰テストとは
プログラミングの話題と相性がいいんじゃないかと思って、昔読んだことがある達人プログラマー (1999年に出版された第1版の方、2019年に出版された第2版ではない) をぱらぱら見返してみた。プログラマーとしての姿勢やプラクティスなどは一般に普及したかどうかの判断が難しい。間違いなく一般的になったなと思えるものに絞って書く。インフラ面の進化が大きいと言えそう。
フリーレン「わずか数年で人類の開発方法論に組み込まれ、新しいインフラによってシステム開発の生産性を向上させた。」
でも今のチームはソースコード管理システムを使っていないんだけど……
恥ずかしいと思ってください！ そして、これが伝道師となる機会だと受け止めてほしいのです。しかし、彼らが自ら進むべき道を見つける時まで、あなた一人ぼっちであってもソース管理を使うようにしてください。
フェルン「いまのはバージョン管理システムです。」
いつリファクタリングを行うべきなのか？
コードがうまくなじんでいないと感じたり、まとめるべき 2 つの事柄を見つけたりといった何か「おかしなもの」に遭遇した場合、手を入れることを躊躇してはいけません。
テストの文化
あなたの記述したソフトウェアはすべてテストの対象になります。あなたやあなたのチームの人間がテストをしなければ、最終的にユーザーがテストを強いられるのです。このため、テスト計画を徹底的に練る必要があります。しかし、事前にものごとを少し考えるだけでメンテナンス費とヘルプデスクへの呼び出しを大幅に削減できます。
(中略)
テストは技術というよりは文化なのです。こういったテスト文化は、使用する言語に関係なくプロジェクトに植え付けることが可能なのです。
フェルン「いまのはテスト駆動開発です。」
多くのプロジェクトでは、こういったレベルのビルドは毎晩自動的に実行されています。つまり、プロジェクトの特定部分を夜間ビルドで作成すると同時に、個別のテストよりも完全なテストを実行できるのです。これによって、完全なビルド実行時に行うテストをすべて実行させることも可能になります。結果として、その日のうちに回帰テストの問題を見つけられるようになるわけです。ソースの変更後、できるだけ早い時点で問題を検出できれば、バグの検出と修正を円滑に進められるようになるはずです。
[B! エンジニア] 自社開発メガベンチャーをわずか半年で鬱退職した雑魚エンジニアの話｜JoanOfArc
あのさ、リファクタリングを扱った書籍では「まずテストを書け」ってほぼ確実に書いてあるんだよ。
意図せずバグが発生するように、意図せず挙動を変えて壊してしまうことは不可避だから。
なのでまず（粒度は荒くてもいいから）回帰テストをできるようにする。
リファクタリングはその後の話。
だというのに、元記事には一切「テスト」というワードが出てこないんだよ。
挙動を保証せずに「挙動は **たぶん** 変わってません」と言ってソフトウェアを壊したら本末転倒だろ。
リファクタリングという手法の上っ面だけマネして、中身をまったく理解してないんじゃないか。
設計はしても設計レビューしない(できる人がいない)、納品で必要となるドキュメントしか作らない、スケジュールは引かれるけど遅れが出たら「頑張って挽回します」と言うだけ(そして残業するだけ)、ソースレビューも行わない(そもそもプロパーはコードレベルの話にはタッチしない)、構成管理を職人と化したパートさんがやってる、コード修正しても必要な回帰テスト行わない、そこそもテストをすべて手作業でやっている、ドキュメントの版管理が各人任せなのでどれが最新ドキュメントなのかわからない、その他諸々の問題を抱えた(そして、それらの問題を認識できていない)大手SIerプロジェクトなんてザラです。
プロジェクト管理については組み込み、Webよりレベル低いところ多いですよ。
技術については言わずもがな。新しい人が入ってきてもろくに教育しないから同じような機能の関数がそこら中で再生産されるとか日常茶飯事だし。
