Đang chuẩn bị liên kết để tải về tài liệu:
Code Leader Using People, Tools, and Processes to Build Successful Software phần 2

và một đảo ngược của container kiểm soát. Bằng cách sử dụng hai công nghệ này lại với nhau, bạn có thể loại bỏ gần như tất cả các vấn đề phụ thuộc thời gian chạy và dễ dàng thay thế phiên bản thử nghiệm của tất cả phụ thuộc của bạn tại thời gian thử nghiệm. Tiêm phụ thuộc và đảo ngược của kiểm soát rất phức tạp | Introduction How This Book Is Structured This book is organized into three sections Philosophy Process and Code Construction. The following is a short summary of what you will find in each section and chapter. Part I Philosophy contains chapters that focus on abstract ideas about how to approach a software project. Each chapter contains practical examples of how to realize those ideas. Chapter 1 Buy not Build describes how to go about deciding which parts of your software project you need to write yourself and which parts you may be able to purchase or otherwise leverage from somewhere else. In order to keep costs down and focus on your real competitive advantage it is necessary to write only those parts of your application that you really need to. Chapter 2 Test-Driven Development examines the Test-Driven Development or Test-Driven Design philosophy and some practical ways of applying it to your development life cycle to produce higher-quality code in less time. Chapter 3 Continuous Integration explores the Continuous Integration philosophy and how you can apply it to your project. CI involves automating your build and unit testing processes to give developers a shorter feedback cycle about changes that they make to the project. A shorter feedback cycle makes it easier for developers to work together as a team and at a higher level of productivity. The chapters in Part II Process explore processes and tools that you can use as a team to improve the quality of your source code and make it easier to understand and to maintain. Chapter 4 Done Is Done contains suggestions for defining what it means for a developer to finish a development task. Creating a done is done policy for your team can make it easier for developers to work together and easier for developers and testers to work together. If everyone on your team follows the same set of steps to complete each task then development will be more predictable and of a higher quality. Chapter 5 Testing presents some .