Top Trends in Cybersecurity for 2024 | 
TDDとは？
ビジネスの文脈において、ソフトウェアの目的はそのビジネスに価値を付加することである。 このため、あらゆる開発努力の重要な課題の1つは、ビジネス要件と目的を対応するシステム要件にマッピングすることである。 これらの要件を満たすソフトウェアをどのように記述するか、プロジェクトとコードベースが拡大するにつれて、ソフトウェアがこれらの要件を満たし続けることをどのように保証するか「テスト駆動開発」へ。
Test-Driven Development（TDD）は、ソフトウェアを記述し実行するテストを書くことによってソフトウェアを書くための組織的な方法論である。 TDDの基本は、失敗したテストを書く、合格する、リファクタリングするという3つのステップの繰り返しである。
概念は開発されているどんなソフトウェア機能のための機能の部分を記述するテストから始めることである。 テストするコードがまだ書かれていないため、そのテストを初めて実行すると失敗になる。 当然のことながら、次のステップは、オリジナルのテストに合格することを目的として、機能を実装することである。 3番目の、そしておそらくライフサイクルの最も重要なステップは、コードをリファクタリングすることである。
ソフトウェアを書くことは、その本質的な性質のためだけでなく、その動的な性質のためにも挑戦的である。 ビジネス要件は絶えず変化し、その結果、ソフトウェア要件は適応できる必要がある。 今日書かれているコードは今日のニーズに合っているが、明日、あるいは明日から1か月後に何かが変化し、その結果、今日のコードは特定の問題を解決する最良の方法ではなくなるかもしれない。 ソフトウェアを比較する仕組みを導入することで は ソフトウェアが何を記録しているか すべきである 今、私たちは恐れを知らないうちに、コードをリッピングしたり、書き直したり、コードを再配線して今日の要件を最もよく満たすことができる強力なツールを手に入れた。
TDDを使用する理由
ヘルシンキ大学が2014年に行ったレビューでは、多くの場合、TDDは欠陥、品質、複雑さ、保守性の面でプラスの効果をもたらしたが、これらの改善は開発努力の増加を代償にしていることがわかった。 追加のテストを書くには追加の努力が必要であることを考えると、これは驚くべき結論ではない。しかし、このような性質の研究で除外されているように見えるのは、フィードバックであるTDDの主な利点である。
フィードバックループを閉じることは、変化を起こして何かを学ぶのにかかる時間を短縮することを意味する。 これを速くすればするほど、より機敏になれる。 開発生産性を定量化しようとするほとんどの指標は、時間の経過とともに作業単位に関連しており、実用的なフィードバックを受け取る時間を短縮することで、TDDは貴重なリソースをより効率的に使用することを可能にする。 時は金なりと言われてきたので、経済的利益は自明である。 もし誰かがソフトウェア開発ライフサイクルの中で「左シフト」と言っているのを聞いたことがあるなら、これはまさに彼らが言っていることだ。
アプリケーション用のテストスイートを持つことのもう一つの利点は、自動化できることである。 開発者はこれらのテストを開発ライフサイクルの一部として実行できるだけでなく、他のシステムでもスモークテストやCI/CDパイプラインの一部として実行することができる。 コードを市場に届けるためのステップを自動化することで、製品全体をより迅速に届けることができ、ユーザーからのフィードバックを迅速に受け止め、次のイテレーションに適用することができる。
この2点の相乗効果は明らかである。開発者がビジネスニーズに合わせてコードベースを継続的に適応させることができるコードベースと、ビジネスが顧客から迅速にフィードバックを求めることができるコードベースにより、チームがより少ない作業からより多くの価値を提供できるシステムとなっている。
TDDを最大限に活用する
テスト駆動開発は、ソフトウェアのテストに対する多くの異なるアプローチの1つにすぎない。 どのような方法で実装しようと、重要なのは、それが組織に価値をもたらすことである。 他の規律のように、あなたの組織の必要性に完全に基づいて、それを使用して自由に感じるべきである、またはあなたが適当と思うようにそれを適応させるか、または全く使用しないべきである。 そうは言っても、もしあなたがTDDの道を歩むことを選択した場合、預言者クラプトンが予言したように:「それはあなたがそれを使う方法である」。
他のツールと同様に、TDDの有効性と価値はその実装に依存している。 ソフトウェア開発では、プロジェクトの失敗や欠点を説明するためにさまざまなツールやテクニックがスケープゴートになることが多すぎるが、彼のツールを非難するのは貧しい職人だ。 そこで、TDDを最大限に活用する方法に焦点を当てよう。
文化的リファクタリング
TDDの最後の、そして最も重要なステップはコードをリファクタリングすることである。しかし、TDDが機能するために必要なリファクタリングはおそらく、それだけではないだろう。 何らかの形でテスト駆動型開発を実装することを選択した場合、周囲の文化もこの開発哲学のスタイルをサポートするように適応することが重要である。
TDDの場合、最も一般的な失敗は、書き込みテストを合格させ、リファクタリングが実際に完了することはなく、リファクタリングのステップをスキップして短絡することである。 問題となるのは、TDDやその他の特定の技術ではなく、むしろソフトウェアが開発されている文化そのものである。
ドキュメントとは異なり、リファクタリングは、締め切りや予算が厳しくなると、最初に捨て去られてしまうようだ。結局のところ、誰かがこれらのテストをすべて書かなければならないからだ。 そのため、クランチタイムにはテストやドキュメント、その他ミッションクリティカルではないと考えられているものはすべて破棄される。 コードベースの全体的な品質が着実に低下し、その代わりに技術的負債の蓄積が続く。
リファクタリングは、単純に動作するコードを、よりクリーンで保守性の高いコードベースに変換しようとするプロセスのステップである。 開発者が一歩下がってシステム全体の中のパターンを認識し、より汎用性の高いものに適応する方法や新たに出現するアンチパターンを認識してそれを軽減するための措置を講じる方法について、十分な情報に基づいた決定を下すことができる部分である。 アーキテクチャ全体を個別のマイクロサービスや無数の潜在的な改善に分割する時期を認識することとの違いかもしれない。 このステップがなければ、内省と段階的な改善の機会を逃すことができ、最終的にコードベースが徐々に(またはそうでない)大きな泥の塊に変換される危険性がある。
テスト駆動型開発のメリットを享受するには、プロセス全体とその可能性を長い目で見て、適切な部分だけでなく、完全な「赤、緑、リファクタリング」サイクルを適用することに時間を費やすことが重要である。
シャイニー・ニュー・トイズ
システム設計全体として考えると、実際にコードを書かずにシステムの詳細を計画するのに時間がかかりすぎることが多い。 「グリーンフィールド」プロジェクトは、一枚の紙に関連するすべての予測可能性を伴うエキサイティングなものであり得る。 エンジニアや建築家は、この試みの犠牲になる。そこでは、月ごとの風味技術の使用を提唱し、この特定のプロジェクトには適していないかもしれないという警告サインを無視して、何か新しいものやクールなものを試す機会を求めている。 数か月後には、フレームワークのdu-jourがチームのニーズを満たしておらず、コードの品質が低下しており、プロジェクトの悪い結果に対する技術がスケープゴートになる部分に戻っている。
最終的に重要なのは、TDDを促進するために使用される技術、方法論、フレームワークがチームとビジネスのために機能することである。 もしあなたがあなたのツールに邪魔されているならば、彼らは価値を付加していないだけでなく、彼らはあなたに対して積極的に働いている。 どのようなフレームワークを使用しようとしているかを徹底的に評価し、それをどのように使用するかを正確に理解するために時間をかける。 このアプローチは、TDDに関連するものだけでなく、すべての設計決定に当てはまる。
ラッピングアップ
一言で言えば、TDDのようなもののアイデアは、コードベースにバグが現れるのを防ぐための単なる技術ではなく、より適切な方法でフィードバックを収集するためのフレームワークを提供することである。 どちらのアプローチを選択しても、重要なのは、変化するトレンドとビジネスニーズにより迅速に適応できるようにすることである。 TDDとそれに対応するものは、単に開発チームに実装を依頼して忘れてしまうようなものではないことに留意する。また、これらの技術を効果的に活用するには、フレームワークやツールなどの実装の詳細に飛び込む前に、文化レベルでアプローチを受け入れ、有効にするように注意する必要がある。
