What do you think?
Rate this book
Robert C. Martin Series
無瑕的程式碼 敏捷完整篇：物件導向原則、設計模式與C#實踐
這本書是《無瑕的程式碼》系列書的第三冊，也是《名家名著》系列書的第三冊。主題是「敏捷開發」，而重點仍舊是回歸到「如何撰寫出好的程式碼」。
什麼是「敏捷開發（Agile Development）」呢？簡單來說，它是軟體開發的一套方法，特點是只要透過這套方法，就能使你的專案更敏捷。
我們為何非得要讓專案變得敏捷呢？原因無他，就是因為我們有慣老闆、還有慣客戶。也就是說，對於現今的市場環境而言，專案不夠敏捷是不行的。這一點，相信所有的軟體工程師都無法否認吧！
可是你可能會反駁說，各行各業都有慣老闆和慣客戶啊（至少在台灣是這樣），為什麼軟體業就要一套特別的方式來應付他們呢？這就是要回歸到一個最根本的問題，「什麼是軟體？」，或者更精確地說「什麼是軟體設計？」，而這個問題和所有的軟體工程師（或程式設計師）習習相關，因為這是工作的本質。
各式各樣的工程有著所謂的程序，例如橋樑工程師會先進行結構分析，他們會建立電腦模型並進行模擬，接著他們會建立比例模型，並在風洞中或用其他一些方法進行測試。當這些程序都完成了，才會將設計圖交給橋樑的建造工人去建造出真實的橋樑。
以上是橋樑工程的開發程序，那麼軟體開發的程序呢？在很久很久以前（真的是很久很久以前了），軟體開發也發展出了所謂的程序，也就是瀑布型開發程序。在瀑布型開發中，系統分析師會依照需求與規畫，畫出所謂軟體的設計圖（例如UML圖），然後由「程序員」根據這些圖去寫出程式碼，最後建置（build）成可使用的軟體。
依照瀑布型開發程序開發出來的軟體，客戶只能選擇要用，還是不要用。不要用的話，是否有其他選擇？如果沒有，那麼客戶即便不滿意，也就只能將就著用（只是邊用邊罵而已）。當然，這是指套裝軟體的開發而言。
用一個例子來做比方，數十年前，台灣只有國道一號的日子，一位民眾想要開車從彰化到新竹，就只能有一個選擇，即便他不滿意苗栗那段高爬坡會折損車輛壽命，他也別無選擇。但當國道三號建造完畢後，他就有了第二個選擇，因此他會選擇他喜歡的國道來行使。建造國道的總經費是昂貴的（無論是時間還是金錢），但最貴的部分是在於建造部分，而非設計部份。所以國道並不多。競爭者很少。但這種商業模式在軟體業是行不通的。
若用早期的瀑布型開發程序來對比於國道建設，真正的建造部分，其實就是軟體建置（build）的部分，這部分只要一台電腦，一個編譯器，一個連結器，還有一點點的時間就完成了。所以代價是極低的。或許有人會說，不對，建造的部分應該也要包含按照UML圖去Coding的人工與時間成本。所以這部分的代價應該也是昂貴的。
這種說法表面上看似合理，但有多少程式碼是完全依照UML圖編寫的呢？在撰寫程式碼的過程中是否會修改原有的UML設計呢？早期這類情況並不嚴重，但晚期因為客戶的挑剔，這種情況早就屢見不鮮，甚至任何軟體工程師在開發專案時，心中早有預期會出現需求發生變化的情況。
國道的建造工人是無權修改設計圖的，他只能「按圖施工」。而程序員卻去修改了設計圖，這將使得設計圖無法作為最終產品的設計文件。因此，在這種情況下，最終產品的設計文件其實只有一份是準確的，這份文件就是「程式碼」。同時，在這種情況下，程序員應該已經不再只是「程序員」或「碼農」了，因為他參與了設計，換句話說，他應該稱之為程式「設計師」或軟體「工程師」。（在敏捷開發中，並不只有那些繪製UML圖的才叫做設計人員，正確地說，繪製UML圖的人常常也是負責寫程式的人）。
好的，如果你已經承認「寫程式」也算是「設計」的一環，那麼軟體建置（build）的成本（也就是軟體的建造成本，而非設計成本），應該是無庸置疑的低廉了。這也就是為什麼，客戶說，那邊改成XXX顏色，可以嗎？你會很乾脆地回答，當然沒問題，然後五分鐘內就給客戶看改完之後的結果。想一想，如果要改的是一整段國道護欄的顏色，相信沒有客戶敢做這樣要求，因為他們能預期到，這會花很多很多的錢。
所以說，建造軟體的花費是很少的，大多數的錢都是花費在「設計」上的。但對於其他工程就不一樣了，設計花費的錢相對於建造花費的錢來說，低廉了許多。
也就是軟體的這種特殊性，導致了客戶（更有可能的是上司）常常想要東改改、西改改，需求常常在變化。在現今這個快速變化的世界裡，慣客戶與慣老闆們為了競爭優勢（他們心中的競爭優勢），提出需求的變化根本是家常便飯。
在確定了「需求會變化」、甚至是「會頻繁地變化」這個軟體工程師一定得面對的事實後，軟體工程師該怎麼辦呢？有一群大師級的軟體工程師，開始發明了一系列因應的對策，包含設計模式、極限程式設計、測試驅動開發等等的技藝，還總結了一些物件導向的設計原則。這些都有助於應付變化。最終，這些人集合起來成立了一個「敏捷聯盟」，取名為敏捷（Agile），意思是軟體開發者及軟體本身應該如何敏捷地應付需求的變化，當中牽涉到的範圍極廣，從成員的組織到程式碼的組織都必須敏捷起來，這是門現代軟體設計的顯學，國外大廠早已採用多年。
Robert C. Martin（Bob大叔）是敏捷聯盟的創始成員之一，也是當中付諸行動並且有所成效的成員之一。他擁有極具說服力的文筆與口才。在這些年中，不斷出書、演講、作為顧問實際前往開發現場指導，並自創「Clean」一詞，其著作還曾獲得Jolt大獎，《Clean Code》一書也成為Amazon該類別最暢銷的著作，這些都對於敏捷開發的推廣有著極重要的貢獻。
根據《Clean Code》內文的說法，《Clean Code》可說是本書的前傳，而本書是完整說明如何實踐敏捷的書籍。如果您也喜歡Bob大叔的著作，如果你也是Clean派的弟子，或者你想實際體驗敏捷開發，那麼你一定不能錯過這本書。
本書的寫作風格是循序漸進，由淺入深的，作者會先提出一個問題，然後分析問題，接著實作它，然後是檢討它，展現出初次實作時的錯誤與失策，接著就展示如何透過作者所主張的技術來解決這些問題。這是一本非常講究實務的實踐書籍。此外，本書主要使用的是C#程式碼，這是由Bob大叔的兒子Micah Martin根據C#與.NET平台的特性重新改寫Jolt得獎著作而來的，改寫幅度包含所有的程式碼與內文，並採用了更容易理解的案例來詳述敏捷開發。如果你平常使用的是其他語言，也不必在意，因為傳播的介質不重要，傳授的內容才是本書的價值所在。
對於一些技術細節，本書果真是大師級的作品，原創性極高，在UML章節中，Bob大叔示範了他如何使用UML（果真和一般人不太一樣），還示範了如何使用UML才能幫助你而非是製造混亂的來源。對於設計模式而言，除了GoF的知名設計模式之外，Bob大叔還在本書中提到幾個他自己常用的設計模式，有些可以視為GoF 23個設計模式的變形，有些則不是，但重點是這些模式都非常好用，可以應用在不同的應用場合，同時Bob大叔也釐清了，某些模式為何不該在哪些場合中使用，他是以效益來看待這件事的，而這也是本書的最大特色：務實。
什麼是「敏捷開發（Agile Development）」呢？簡單來說，它是軟體開發的一套方法，特點是只要透過這套方法，就能使你的專案更敏捷。
我們為何非得要讓專案變得敏捷呢？原因無他，就是因為我們有慣老闆、還有慣客戶。也就是說，對於現今的市場環境而言，專案不夠敏捷是不行的。這一點，相信所有的軟體工程師都無法否認吧！
可是你可能會反駁說，各行各業都有慣老闆和慣客戶啊（至少在台灣是這樣），為什麼軟體業就要一套特別的方式來應付他們呢？這就是要回歸到一個最根本的問題，「什麼是軟體？」，或者更精確地說「什麼是軟體設計？」，而這個問題和所有的軟體工程師（或程式設計師）習習相關，因為這是工作的本質。
各式各樣的工程有著所謂的程序，例如橋樑工程師會先進行結構分析，他們會建立電腦模型並進行模擬，接著他們會建立比例模型，並在風洞中或用其他一些方法進行測試。當這些程序都完成了，才會將設計圖交給橋樑的建造工人去建造出真實的橋樑。
以上是橋樑工程的開發程序，那麼軟體開發的程序呢？在很久很久以前（真的是很久很久以前了），軟體開發也發展出了所謂的程序，也就是瀑布型開發程序。在瀑布型開發中，系統分析師會依照需求與規畫，畫出所謂軟體的設計圖（例如UML圖），然後由「程序員」根據這些圖去寫出程式碼，最後建置（build）成可使用的軟體。
依照瀑布型開發程序開發出來的軟體，客戶只能選擇要用，還是不要用。不要用的話，是否有其他選擇？如果沒有，那麼客戶即便不滿意，也就只能將就著用（只是邊用邊罵而已）。當然，這是指套裝軟體的開發而言。
用一個例子來做比方，數十年前，台灣只有國道一號的日子，一位民眾想要開車從彰化到新竹，就只能有一個選擇，即便他不滿意苗栗那段高爬坡會折損車輛壽命，他也別無選擇。但當國道三號建造完畢後，他就有了第二個選擇，因此他會選擇他喜歡的國道來行使。建造國道的總經費是昂貴的（無論是時間還是金錢），但最貴的部分是在於建造部分，而非設計部份。所以國道並不多。競爭者很少。但這種商業模式在軟體業是行不通的。
若用早期的瀑布型開發程序來對比於國道建設，真正的建造部分，其實就是軟體建置（build）的部分，這部分只要一台電腦，一個編譯器，一個連結器，還有一點點的時間就完成了。所以代價是極低的。或許有人會說，不對，建造的部分應該也要包含按照UML圖去Coding的人工與時間成本。所以這部分的代價應該也是昂貴的。
這種說法表面上看似合理，但有多少程式碼是完全依照UML圖編寫的呢？在撰寫程式碼的過程中是否會修改原有的UML設計呢？早期這類情況並不嚴重，但晚期因為客戶的挑剔，這種情況早就屢見不鮮，甚至任何軟體工程師在開發專案時，心中早有預期會出現需求發生變化的情況。
國道的建造工人是無權修改設計圖的，他只能「按圖施工」。而程序員卻去修改了設計圖，這將使得設計圖無法作為最終產品的設計文件。因此，在這種情況下，最終產品的設計文件其實只有一份是準確的，這份文件就是「程式碼」。同時，在這種情況下，程序員應該已經不再只是「程序員」或「碼農」了，因為他參與了設計，換句話說，他應該稱之為程式「設計師」或軟體「工程師」。（在敏捷開發中，並不只有那些繪製UML圖的才叫做設計人員，正確地說，繪製UML圖的人常常也是負責寫程式的人）。
好的，如果你已經承認「寫程式」也算是「設計」的一環，那麼軟體建置（build）的成本（也就是軟體的建造成本，而非設計成本），應該是無庸置疑的低廉了。這也就是為什麼，客戶說，那邊改成XXX顏色，可以嗎？你會很乾脆地回答，當然沒問題，然後五分鐘內就給客戶看改完之後的結果。想一想，如果要改的是一整段國道護欄的顏色，相信沒有客戶敢做這樣要求，因為他們能預期到，這會花很多很多的錢。
所以說，建造軟體的花費是很少的，大多數的錢都是花費在「設計」上的。但對於其他工程就不一樣了，設計花費的錢相對於建造花費的錢來說，低廉了許多。
也就是軟體的這種特殊性，導致了客戶（更有可能的是上司）常常想要東改改、西改改，需求常常在變化。在現今這個快速變化的世界裡，慣客戶與慣老闆們為了競爭優勢（他們心中的競爭優勢），提出需求的變化根本是家常便飯。
在確定了「需求會變化」、甚至是「會頻繁地變化」這個軟體工程師一定得面對的事實後，軟體工程師該怎麼辦呢？有一群大師級的軟體工程師，開始發明了一系列因應的對策，包含設計模式、極限程式設計、測試驅動開發等等的技藝，還總結了一些物件導向的設計原則。這些都有助於應付變化。最終，這些人集合起來成立了一個「敏捷聯盟」，取名為敏捷（Agile），意思是軟體開發者及軟體本身應該如何敏捷地應付需求的變化，當中牽涉到的範圍極廣，從成員的組織到程式碼的組織都必須敏捷起來，這是門現代軟體設計的顯學，國外大廠早已採用多年。
Robert C. Martin（Bob大叔）是敏捷聯盟的創始成員之一，也是當中付諸行動並且有所成效的成員之一。他擁有極具說服力的文筆與口才。在這些年中，不斷出書、演講、作為顧問實際前往開發現場指導，並自創「Clean」一詞，其著作還曾獲得Jolt大獎，《Clean Code》一書也成為Amazon該類別最暢銷的著作，這些都對於敏捷開發的推廣有著極重要的貢獻。
根據《Clean Code》內文的說法，《Clean Code》可說是本書的前傳，而本書是完整說明如何實踐敏捷的書籍。如果您也喜歡Bob大叔的著作，如果你也是Clean派的弟子，或者你想實際體驗敏捷開發，那麼你一定不能錯過這本書。
本書的寫作風格是循序漸進，由淺入深的，作者會先提出一個問題，然後分析問題，接著實作它，然後是檢討它，展現出初次實作時的錯誤與失策，接著就展示如何透過作者所主張的技術來解決這些問題。這是一本非常講究實務的實踐書籍。此外，本書主要使用的是C#程式碼，這是由Bob大叔的兒子Micah Martin根據C#與.NET平台的特性重新改寫Jolt得獎著作而來的，改寫幅度包含所有的程式碼與內文，並採用了更容易理解的案例來詳述敏捷開發。如果你平常使用的是其他語言，也不必在意，因為傳播的介質不重要，傳授的內容才是本書的價值所在。
對於一些技術細節，本書果真是大師級的作品，原創性極高，在UML章節中，Bob大叔示範了他如何使用UML（果真和一般人不太一樣），還示範了如何使用UML才能幫助你而非是製造混亂的來源。對於設計模式而言，除了GoF的知名設計模式之外，Bob大叔還在本書中提到幾個他自己常用的設計模式，有些可以視為GoF 23個設計模式的變形，有些則不是，但重點是這些模式都非常好用，可以應用在不同的應用場合，同時Bob大叔也釐清了，某些模式為何不該在哪些場合中使用，他是以效益來看待這件事的，而這也是本書的最大特色：務實。
744 pages, Paperback
First published July 1, 2006
177 people are currently reading
1658 people want to read
About the author
Robert C. Martin
65 books1,887 followersRobert Cecil Martin, commonly called Uncle Bob, is a software engineer, advocate of Agile development methods, and President of Object Mentor Inc. Martin and his team of software consultants use Object-Oriented Design, Patterns, UML, Agile Methodologies, and eXtreme Programming with worldwide clients.
He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.
He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 38 reviews
August 12, 2018
Design patterns explicate în jurul unor exemple de aplicații, principiile SOLID exhaustiv prezentate, o introducere generală, dar suficientă a UML, clean design la nivel de componente și pachete, toate legate prin lupa principiilor agile sunt părțile constituente ale cărții, pe care le-am savurat și sorbit cu mult mai mult entuziasm decât cele din ”Clean code”. Aceasta se poate datora faptului că, fiind mai amplă, Uncle Bob și-a permis să explice mai îndetaliat toate principiile, dar și faptului că am învățat lucruri noi dincolo de poezia deja repetitivă a codului curat (traducerea sună amuzant în română).
Rămân negreșit fana lui Robert C. Martin, dar aștept cu nerăbdare să descopăr și alți profesioniști în ale programării. Am să mă dedic să îi urmăresc în continuare video-urile, ale căror intenții le înțeleg acum mult mai clar.
Rămân negreșit fana lui Robert C. Martin, dar aștept cu nerăbdare să descopăr și alți profesioniști în ale programării. Am să mă dedic să îi urmăresc în continuare video-urile, ale căror intenții le înțeleg acum mult mai clar.
May 4, 2014
With the award-winning book Agile Software Development: Principles, Patterns, and Practices, Robert C. Martin helped bring Agile principles to tens of thousands of Java and C++ programmers. Now .NET programmers have a definitive guide to agile methods with this completely updated volume from Robert C. Martin and Micah Martin, Agile Principles, Patterns, and Practices in C#.
This book presents a series of case studies illustrating the fundamentals of Agile development and Agile design, and moves quickly from UML models to real C# code. The introductory chapters lay out the basics of the agile movement, while the later chapters show proven techniques in action. The book includes many source code examples that are also available for download from the authors’ Web site.
Readers will come away from this book understanding
Agile principles, and the fourteen practices of Extreme Programming Spiking, splitting, velocity, and planning iterations and releases Test-driven development, test-first design, and acceptance testing Refactoring with unit testing Pair programming Agile design and design smells The five types of UML diagrams and how to use them effectively Object-oriented package design and design patterns How to put all of it together for a real-world projectWhether you are a C# programmer or a Visual Basic or Java programmer learning C#, a software development manager, or a business analyst, Agile Principles, Patterns, and Practices in C# is the first book you should read to understand agile software and how it applies to programming in the .NET Framework.
About the AuthorRobert C. Martin has been a software professional since 1970 and an international software consultant since 1990. He is founder and president of Object Mentor, Inc., a team of experienced consultants who mentor their clients in the fields of C++, Java, OO, Patterns, UML, Agile Methodologies, and Extreme Programming.
Micah Martin works with Object Mentor as a developer, consultant, and mentor on topics ranging from object-oriented principles and patterns to agile software development practices. Micah is the cocreator and lead developer of the open source FitNesse project. He is also a published author and speaks regularly at conferences.
Excerpt. © Reprinted by permission. All rights reserved.Bob’s IntroductionBut Bob, you said you’d be done with the book last year.
—Claudia Frers, UML World, 1999
It’s been seven years since Claudia’s justifiable complaint, but I think I have made up for it. Publishing three books—one book every other year while running a consulting company and doing a lot of coding, training, mentoring, speaking, and writing articles, columns, and blogs—not to mention raising a family and enjoying a grandfamily can be quite a challenge. But I love it.
Agile development is the ability to develop software quickly, in the face of rapidly changing requirements. In order to achieve this agility, we need to use practices that provide the necessary discipline and feedback. We need to employ design principles that keep our software flexible and maintainable, and we need to know the design patterns that have been shown to balance those principles for specific problems. This book is an attempt to knit all three of these concepts together into a functioning whole.
This book describes those principles, patterns, and practices and then demonstrates how they are applied by walking through dozens of different case studies. More important, the case studies are not presented as complete works. Rather, they are designs in progress. You will see the designers make mistakes and observe how they identify them as mistakes and eventually correct them. You will see the designers puzzle over conundrums and worry over ambiguities and trade-offs. You will see the act of design.
Micah’s IntroductionIn early 2005, I was on a small development team that began work on a .NET application to be written in C#. Using agile development practices was mandatory, which is one of the reasons I was involved. Although I had used C# before, most of my programming experience was in Java and C++. I didn’t think that working in .NET would make much difference; in the end it didn’t.
Two months into the project, we made our first release. It was a partial release containing only a fraction of all the intended features, but it was enough to be usable. And use it they did. After only two months, the organization was reaping the benefits of our development. Management was so thrilled that it asked to hire more people so we could start more projects.
Having participated in the agile community for years, I knew a good many agile developers who could help us. I called them all and asked them to join us. Not one of my agile colleagues ended up joining our team. Why not? Perhaps the most overwhelming reason was the fact that we were developing in .NET.
Almost all agile developers have a background in Java, C++, or Smalltalk. But agile .NET programmers are almost unheard of. Perhaps my friends didn’t take me seriously when I said we were doing agile software development with .NET, or maybe they were avoiding association with .NET. This was a significant problem. It was not the first evidence I’d seen of this problem, either.
Teaching week-long courses on various software topics allows me to meet a wide cross-section of developers from around the world. Many of the students I’ve instructed were .NET programmers, and many were Java or C++ programmers. There’s no gentle way to put this: In my experience, .NET programmers are often weaker than Java and C++ programmers. Obviously, this is not always the case. However, after observing it over and over in my classes, I can come to no other conclusion: .NET programmers tend to be weaker in agile software practices, design patterns, design principles, and so on. Often in my classes, the .NET programmers had never heard of these fundamental concepts. This has to change.
The first edition of this book, Agile Software Development: Principles, Patterns, and Practices, by Robert C. Martin, my father, was published in late 2002 and won the 2003 Jolt Award. It is a great book, celebrated by many developers. Unfortunately, it had little impact on the .NET community. Despite the fact that the content of the book is equally relevant to .NET, few .NET programmers have read it.
It is my hope that this .NET edition acts as a bridge between .NET and the rest of the developer community. I hope that programmers will read it and see that there are better ways to build software. I hope that they will begin using better software practices, creating better designs, and raising the bar for quality in .NET applications. I hope that .NET programmers will not be weaker than other programmers. I hope that .NET programmers achieve a new status in the software community such that Java developers are proud to join a .NET team.
Throughout the process of putting this book together, I struggled many times with the concept of my name being on the cover of a .NET book. I questioned whether I wanted my name associated with .NET and all the negative connotations that seemed to come with it. Yet I can no longer deny it. I am a .NET programmer. No! An agile .NET programmer. And I’m proud of it.
About This Book A Little HistoryIn the early 1990s I (Bob) wrote Designing Object-Oriented C++ Applications Using the Booch Method. That book was something of a magnum opus for me, and I was very pleased with the result and the sales.
The book you are reading started out as a second edition to Designing, but that’s not how it turned out. Very little remains of the original book in these pages. Little more than three chapters have been carried through, and those have been massively changed. The intent, spirit, and many of the lessons of the book are the same. In the decade since Designing came out, I’ve learned a tremendous amount about software design and development. This book reflects that learning.
What a decade! Designing came out just before the Internet collided with the planet. Since then, the number of acronyms we have to deal with has doubled. We have EJB, RMI, J2EE, XML, XSLT, HTML, ASP, JSP, ZOPE, SOAP, C#, and .NET, as well as Design Patterns, Java, Servelets, and Application Servers. Let me tell you, it’s been difficult to keep the chapters of this book current.
The Booch connection In 1997, I was approached by Grady Booch to help write the third edition of his amazingly successful Object-Oriented Analysis and Design with Applications. I had worked with Grady before on some projects and had been an avid reader and contributor to his various works, including UML. So I accepted with glee and asked my good friend Jim Newkirk to help out with the project.
Over the next two years, Jim and I wrote a number of chapters for the Booch book. Of course, that effort meant that I could not put as much effort into this book as I would have liked, but I felt that the Booch book was worth contributing to. Besides, at the time, this book was simply a second edition of Designing, and my heart wasn’t in it. If I was going to say something, I wanted to say something new and different.
Unfortunately, the Booch book was not to be. It is difficult to find the time to write a book during normal times. During the heady days of the dot-com bubble, it was nearly impossible. Grady got ever busier with Rational and with new ventures such as Catapulse. So the project stalled. Eventually, I asked Grady and Addison-Wesley whether I could have the chapters that Jim and I wrote to include in this book. They graciously agreed. So several of the case study and UML chapters came from that source.
The impact of Extreme Programming In late 1998, XP reared its head and challenged our cherished beliefs about software development. Should we create lots of UML diagrams prior to writing any code? Or should we eschew any kind of diagrams and simply write lots of code? Should we write lots of narrative documents that describe our design? Or should we try to make the code narrative and expressive so that ancillary documents aren’t necessary? Should we program in pairs? Should we write tests before we write production code? What should we do?
This revolution came at an opportune time. During the middle to late 1990s, Object Mentor was helping quite a few companies with OO design and project management issues. We were helping companies get their projects done. As part of that help, we instilled into the teams our own attitudes and practices. Unfortunately, these attitudes and practices were not written down. Rather, they were an oral tradition that was passed from us to our customers.
By 1998, I realized that we needed to write down our process and practices so that we could better articulate them to our customers. So I wrote many articles about process in the C++ Report.1 These articles missed the mark. They were informative and in some cases entertaining, but instead of codifying the practices and attitudes that we used in our projects, they were an unwitting compromise to values that had been imposed on me for decades. It took Kent Beck to show me that.
The Beck connection In late 1998, at the same time I was fretting over codifying the Object Mentor process, I ran into Kent’s work on Extreme Programming (XP). The work was scattered through Ward Cunningham’s wiki2 and was mixed with the writings of many others. Still, with some work and diligence, I was able to get the gist of what Kent was talking about. I was intrigued but skeptical. Some of the things that XP talked about were exactly on target for my concept of a development process. Other things, however, such as the lack of an articulated design step, left me puzzled.
Kent and I could not have come from more disparate software circumstances. He was a recognized Smalltalk consultant, and I was a recognized C++ consultant. Those two worlds found it difficult to communicate with each other. There was an almost Kuhnian3 paradigm gulf between them.
Under other cir...
September 19, 2019
This is a great book on software development process and design.
The agile development definition and practices are easy to digest and are common practice nowadays. I particularly enjoy the programming episode between the author and his colleague. It illustrates how software designs are not great from the beginning, but are refined through an iterative process.
Next, the author presents the agile design principles. These are great principles for software development in general, and not limited to agile software development.
In the next section, a payroll case study is presented. This is the driest part of the book, but necessary to illustrate and consolidate the principles and practices outlined in the previous chapters.
The author also presents quite a few OOP design pattern in details, often comparing 2 similar patterns together. They're good reminders if you've known the patterns before, or good introduction if you haven't. My only complain is that they seem scattered and unstructured. If you're like me, you'd often wonder there's a OOP design pattern chapter right in the middle of the "case study" section with no explanation.
The next section about packaging the payroll system is surprisingly educative. This part makes me think about how to structure software components so that they are most maintainable. Something you do every time you add a new class or a new component.
I didn't finish the whole book. I lost interest after the author throws more OOP design patterns at me without explanations the second time. Maybe I'll come back at a later day. But I'm satisfied with what I've learnt for now.
The agile development definition and practices are easy to digest and are common practice nowadays. I particularly enjoy the programming episode between the author and his colleague. It illustrates how software designs are not great from the beginning, but are refined through an iterative process.
Next, the author presents the agile design principles. These are great principles for software development in general, and not limited to agile software development.
In the next section, a payroll case study is presented. This is the driest part of the book, but necessary to illustrate and consolidate the principles and practices outlined in the previous chapters.
The author also presents quite a few OOP design pattern in details, often comparing 2 similar patterns together. They're good reminders if you've known the patterns before, or good introduction if you haven't. My only complain is that they seem scattered and unstructured. If you're like me, you'd often wonder there's a OOP design pattern chapter right in the middle of the "case study" section with no explanation.
The next section about packaging the payroll system is surprisingly educative. This part makes me think about how to structure software components so that they are most maintainable. Something you do every time you add a new class or a new component.
I didn't finish the whole book. I lost interest after the author throws more OOP design patterns at me without explanations the second time. Maybe I'll come back at a later day. But I'm satisfied with what I've learnt for now.
August 29, 2017
A great book filled with best practices, not easy to read, as a programmer when I pick a book about programming I expect more technical/coding maybe even small projects from A to Z, this book has more definitions and stories,
I would definitely recommend this book to experienced programmers and specially team leaders as they have the ability to apply those design patterns and force the best practices on the whole team.
This book is not for junior programmers (in my opinion), "Clean Code" by the same author might be a better book to read.
I would definitely recommend this book to experienced programmers and specially team leaders as they have the ability to apply those design patterns and force the best practices on the whole team.
This book is not for junior programmers (in my opinion), "Clean Code" by the same author might be a better book to read.
November 12, 2017
Covers a (too) vast territory. Long to read. Not everything is interesting...
August 31, 2018
Besides design pattern, here you will also learn about package designs, different types of UML diagrams, testing and much more. If you have time give it a read, it is worth it.
December 16, 2020
This book is not good.
I am writing this in 2020. Perhaps this book, published 2007, is a book from another time. The first chapter ends with a conclusion saying, "Yet our projects fail, or fail to deliver value, at a dismaying rate." While I do recall that being the norm many years ago, I don't recall it in the past 10yrs. Maybe I'm living in an echo chamber of success.
The book opens with chapters titled Agile Practices, Overview of Extreme Programming, Planning, and Testing. The first two are fine. The second two are very problematic. The 5 pages on planning are too short to be of any value to anyone but the complete novice. The Testing chapter introduces Mock Objects without any statement of the problem which they solve. The suggestion to the reader is to always do this. This is terrible advice which doesn't fit with principles of simplicity and you ain't gonna need it that are mentioned later in the book.
The fifth chapter on refactoring is something only an object-oriented only programmer could write. More experienced programmers can see through the gaslighting. The hint is that naming things better is a result of refactoring. I assure you it isn't. Yes, naming things is hard. Put all of the names back the way that they were. Now consider the before and after. Did this refactoring improve the code? No. It didn't. Naming things better improved the code. All of the method extraction made it less cohesive, more difficult to reason about, and more complex. Keep it simple.
Chapter 6 ends section one with a story that is supposed to be an example of everything so far. Meh.
Chapter 7 on agile design rolls out the seven design smells, rigidity, fragility, immobility, viscosity, needless complexity, needless repetition, opacity. All excellent things of which to be aware. But then, the example of the Copy program. IMO this example is too simple to really get the points across. Extracting a reader interface is always a good idea, so I guess it is better than nothing.
Chapter 8 is on infamous SRP and does a reasonable job, but is presented without enough caution for balancing this with the above design smells. The rectangle example is particularly bad because in many cases and in many applications there is absolutely nothing wrong with having that rectangle, or your simple type, be responsible for both modeling itself and displaying itself. Then, it gets worse with the Modem example, because while connecting and the data channel does make sense, why stop there? Why not have reader and writer abstracted? Why not use the same reader interface from the previous chapter and show just how powerful it is to think in terms of readers and writers. Opportunity lost.
Chapter 9 is on OCP and I'll refrain from commenting on the chapter because I don't agree with OCP as a good thing most of the time. It is certainly true for library authors shipping a library to be consumed for other programmers, but in today's monorepo development environments with test coverage, there is no reason to think about this. Make the modification to the behavior that "should be closed", run your tests, and move on. Thinking about this too much wastes time and lowers the value of the resulting products as a result. The example
Chapter 10 is on LSP and it is fine and important, and yet, still with the shapes? Was it unknown in 2007 that shapes are very poor OO examples? Was it thought that anything real would be too complex? Well that is kind of the point of a book like this, right? To show how to deal with that complexity. It fails.
Chapter 11 on dependency inversion aka inversion of control, is probably the most important of these chapters on SOLID and this chapter does a poor job of explaining it, a worse job as an example, and no job and why it is so important.
Chapter 12 on interface... no.. ya know what... i'm done. i can't read anymore. I feel dirty reading this. I feel my home is dirty for having this book in it. I can't wait to drop this in the library return box tomorrow.
I am writing this in 2020. Perhaps this book, published 2007, is a book from another time. The first chapter ends with a conclusion saying, "Yet our projects fail, or fail to deliver value, at a dismaying rate." While I do recall that being the norm many years ago, I don't recall it in the past 10yrs. Maybe I'm living in an echo chamber of success.
The book opens with chapters titled Agile Practices, Overview of Extreme Programming, Planning, and Testing. The first two are fine. The second two are very problematic. The 5 pages on planning are too short to be of any value to anyone but the complete novice. The Testing chapter introduces Mock Objects without any statement of the problem which they solve. The suggestion to the reader is to always do this. This is terrible advice which doesn't fit with principles of simplicity and you ain't gonna need it that are mentioned later in the book.
The fifth chapter on refactoring is something only an object-oriented only programmer could write. More experienced programmers can see through the gaslighting. The hint is that naming things better is a result of refactoring. I assure you it isn't. Yes, naming things is hard. Put all of the names back the way that they were. Now consider the before and after. Did this refactoring improve the code? No. It didn't. Naming things better improved the code. All of the method extraction made it less cohesive, more difficult to reason about, and more complex. Keep it simple.
Chapter 6 ends section one with a story that is supposed to be an example of everything so far. Meh.
Chapter 7 on agile design rolls out the seven design smells, rigidity, fragility, immobility, viscosity, needless complexity, needless repetition, opacity. All excellent things of which to be aware. But then, the example of the Copy program. IMO this example is too simple to really get the points across. Extracting a reader interface is always a good idea, so I guess it is better than nothing.
Chapter 8 is on infamous SRP and does a reasonable job, but is presented without enough caution for balancing this with the above design smells. The rectangle example is particularly bad because in many cases and in many applications there is absolutely nothing wrong with having that rectangle, or your simple type, be responsible for both modeling itself and displaying itself. Then, it gets worse with the Modem example, because while connecting and the data channel does make sense, why stop there? Why not have reader and writer abstracted? Why not use the same reader interface from the previous chapter and show just how powerful it is to think in terms of readers and writers. Opportunity lost.
Chapter 9 is on OCP and I'll refrain from commenting on the chapter because I don't agree with OCP as a good thing most of the time. It is certainly true for library authors shipping a library to be consumed for other programmers, but in today's monorepo development environments with test coverage, there is no reason to think about this. Make the modification to the behavior that "should be closed", run your tests, and move on. Thinking about this too much wastes time and lowers the value of the resulting products as a result. The example
Chapter 10 is on LSP and it is fine and important, and yet, still with the shapes? Was it unknown in 2007 that shapes are very poor OO examples? Was it thought that anything real would be too complex? Well that is kind of the point of a book like this, right? To show how to deal with that complexity. It fails.
Chapter 11 on dependency inversion aka inversion of control, is probably the most important of these chapters on SOLID and this chapter does a poor job of explaining it, a worse job as an example, and no job and why it is so important.
Chapter 12 on interface... no.. ya know what... i'm done. i can't read anymore. I feel dirty reading this. I feel my home is dirty for having this book in it. I can't wait to drop this in the library return box tomorrow.
December 31, 2019
One of the biggest disappointments of all the books I read this year. The scope is far too big to cover it in one single book and it therefore lacks the pages to explain the many concepts it introduces. If you know those concepts before, then this is not a problem. But then again, why do you read this book?
The structure is no help either. The section 4 (Packaging the Payroll System) explains what you have to consider for package and component design (as you expect), but then goes on to explain patterns like Visitor, Adapter/Bridge and ends up with the database and Model View Presenter. Such a structure makes it extremely hard to find a specific topic – you more or less need to scan the whole chapter list to find the right place.
The bibliography is for once at the end of every chapter. While I liked that when reading the book for the first time, I hated it as soon as I had to check something. There are 30 places to look up – no problem with an eBook, but unfortunately, I have the print edition…
The book contains an enormous amount of code examples. Unfortunately again, one sees that they are translated from the previous edition of this book that uses Java. This means no C# specific code syntax and therefore not much that justifies the C# in the title. Especially since it ignores the generics, that would made examples like the BubbleSorter much simpler.
I think the topics this book covers are very important. But the way they are covered in this book makes it unnecessary hard to follow along. Instead of this book, you should get a book for each main part and not try to cover all with this one here.
The structure is no help either. The section 4 (Packaging the Payroll System) explains what you have to consider for package and component design (as you expect), but then goes on to explain patterns like Visitor, Adapter/Bridge and ends up with the database and Model View Presenter. Such a structure makes it extremely hard to find a specific topic – you more or less need to scan the whole chapter list to find the right place.
The bibliography is for once at the end of every chapter. While I liked that when reading the book for the first time, I hated it as soon as I had to check something. There are 30 places to look up – no problem with an eBook, but unfortunately, I have the print edition…
The book contains an enormous amount of code examples. Unfortunately again, one sees that they are translated from the previous edition of this book that uses Java. This means no C# specific code syntax and therefore not much that justifies the C# in the title. Especially since it ignores the generics, that would made examples like the BubbleSorter much simpler.
I think the topics this book covers are very important. But the way they are covered in this book makes it unnecessary hard to follow along. Instead of this book, you should get a book for each main part and not try to cover all with this one here.
September 27, 2023
What a great compendium of software development. The authors tell the story of a how a software is developed: from initial discussions, writing tests to aid the the design, and techniques for implementing the design. The agile way is emphasized, with many iterations and little upfront planning. The chapters involving real cases are very valuable.
However, the book's old age affects the reading. The examples in C# are clear enough, but the lack of syntax highlighting makes it very hard to follow. The final appendices are a bit too ironic, which is problematic for a book that's intending to be serious.
I'm a Mechanical Engineer who is working intensily with software development (in Mechanical Engineering); I know how to program and am learning how to do it systematically and in collaboration. This moment is perfect for me to read such a heavy book (not for beginners); if you are also transitioning for a more serious, senior role, take to time to study this book.
However, the book's old age affects the reading. The examples in C# are clear enough, but the lack of syntax highlighting makes it very hard to follow. The final appendices are a bit too ironic, which is problematic for a book that's intending to be serious.
I'm a Mechanical Engineer who is working intensily with software development (in Mechanical Engineering); I know how to program and am learning how to do it systematically and in collaboration. This moment is perfect for me to read such a heavy book (not for beginners); if you are also transitioning for a more serious, senior role, take to time to study this book.
September 27, 2020
The book is good introduction to agile approach in building software.
First part is about agile planning, extreme programming, testing and refactoring. You can treat this part as good starter to be familiar with those issues.
The rest of the book is focused on agile architecture - design patterns, best practices. It's based on a sample problems authors solves together with reader. There is a lot of code. I mean - really a lot. Most of these code could be replaced with much shorter pseudo-code and I think book will be easier to read.
There are better books describing design patterns, extreme programming, unit testing etc., but you can treat this book as a really god starter, allowing you to understand the basics of mentioned topics.
First part is about agile planning, extreme programming, testing and refactoring. You can treat this part as good starter to be familiar with those issues.
The rest of the book is focused on agile architecture - design patterns, best practices. It's based on a sample problems authors solves together with reader. There is a lot of code. I mean - really a lot. Most of these code could be replaced with much shorter pseudo-code and I think book will be easier to read.
There are better books describing design patterns, extreme programming, unit testing etc., but you can treat this book as a really god starter, allowing you to understand the basics of mentioned topics.
June 21, 2018
I think this is a pretty decent book. Had I read it 10 years ago I think I would have been really impressed with it.
This book covers a lot of good patterns in it, sprinkled in amongst Agile stuff. I don't think the "fit" was quite made though.
Mid to senior developers may not get as much out of this, because you're likely already familiar with the patterns that are discussed in the book. However, beginners can get a good introduction to the concepts and it's not a complete waste of time.
Some parts were clumsy and the book contradicts itself in places leaving unanswered questions. But it's not a bad book and it contains good information.
This book covers a lot of good patterns in it, sprinkled in amongst Agile stuff. I don't think the "fit" was quite made though.
Mid to senior developers may not get as much out of this, because you're likely already familiar with the patterns that are discussed in the book. However, beginners can get a good introduction to the concepts and it's not a complete waste of time.
Some parts were clumsy and the book contradicts itself in places leaving unanswered questions. But it's not a bad book and it contains good information.
February 8, 2020
I read few books from uncle bob and I find this very well structured and pleasant to read. It contains knowledge from requirements engineering, planning, solid principles, design patterns and clean architecture. Each of them explained precisely and straight to the point. He also used some simple terms to explain complex concepts precisely.
He oftenly reminds that the advice he given is not absolutely right or wrong. Only use the design where suitable to balance the benefits and complexity.
He oftenly reminds that the advice he given is not absolutely right or wrong. Only use the design where suitable to balance the benefits and complexity.
December 26, 2020
A must read for programers
Well structured, covers important topics with really good examples that can be followed through. Optional challenges to do through out. Don’t skip over the appendixes.
Well structured, covers important topics with really good examples that can be followed through. Optional challenges to do through out. Don’t skip over the appendixes.
December 31, 2022
This was longer than necessary, including a lot of overlap with other Robert Martin books. This is to be expected, since it's an update to one of his classics, but I do wish the authors had at least dropped some of the discussion of UML.
February 23, 2018
Awesome read! Great example of how to go about TDD and examples of design patterns.
April 24, 2019
I wish I read this sooner. This book really solidified my understanding of SOLID (pun not intended). I also wish I had this as my intro to UML as well; just enough to communicate and take notes.
December 17, 2019
Outdated? Found this hard-going, boring
December 28, 2019
This was my gateway book to Agile software development as a developer. It's a reference I still regularly revisit from time to time.
April 25, 2021
Still relevant. A classic.
February 15, 2023
Thicc book, teaches SOLID principles with code examples and case studies.
September 18, 2014
After finishing this book and thinking about how useful its contents would be for me in the workplace right now in the (almost) final quarter of 2014, I have concluded that this book is a valuable addition to my programmer bookshelf, albeit a mixed bag of good and stale bits. The good aspects of this book will remain useful. However, the stale parts are... well... a little too stale and beg for a new edition, which it seems Uncle Bob doesn't plan to undertake.
The good points:
The book has aspects that will keep this book on the shelf, ready to crack open at a moment's notice: justification for denouncement of excessive documentation and diagramming, encouragement of realistic / sustainable work hours, explanations of design patterns in a (loosely) C# context, explanations of agile PPPs from an angle I had not previously considered, demonstrations on how to produce reliable software development estimates, emphasis on test-first design / development as the foundation on which this book is written, the list could go on (but not much further).
The stale points:
To be fair, any language specific examples will become stale pretty quickly, as technology is always advancing at breakneck speeds. The Author(s) do state early on that they're not telling you "how to do C#!"; rather, they're extending a lofty olive branch to the .NET developer community (thanks....?) and wanting to discuss more language agnostic topics (refer to the good points listed above). A lot of reviewers point out that C# is really just a namesake in this book. Therefore, let's just go ahead and say it: the C# is really stale; there are such amazing things C# can do now that have made the language much more expressive, maintainable, dynamic, and capable. Funnily enough, some of these advancements were called for in Jack Reeves' article included in Appendix B of this book when he was referring to C++'s success at its onset.
In a nutshell:
This book is worth having around. I will refer back to this book often for inspiration on various design patterns. However, I would like a more modern C# publication on implementing these patterns in a way that actually leverages the language and avoids (now) known anti-patterns. It would be grand if someone took the content of this book to the next level with more modern insight.
After having finished Agile C#, I experienced enlightenment in some ways, but at the same time, I need a C# palate cleanser.
The good points:
The book has aspects that will keep this book on the shelf, ready to crack open at a moment's notice: justification for denouncement of excessive documentation and diagramming, encouragement of realistic / sustainable work hours, explanations of design patterns in a (loosely) C# context, explanations of agile PPPs from an angle I had not previously considered, demonstrations on how to produce reliable software development estimates, emphasis on test-first design / development as the foundation on which this book is written, the list could go on (but not much further).
The stale points:
To be fair, any language specific examples will become stale pretty quickly, as technology is always advancing at breakneck speeds. The Author(s) do state early on that they're not telling you "how to do C#!"; rather, they're extending a lofty olive branch to the .NET developer community (thanks....?) and wanting to discuss more language agnostic topics (refer to the good points listed above). A lot of reviewers point out that C# is really just a namesake in this book. Therefore, let's just go ahead and say it: the C# is really stale; there are such amazing things C# can do now that have made the language much more expressive, maintainable, dynamic, and capable. Funnily enough, some of these advancements were called for in Jack Reeves' article included in Appendix B of this book when he was referring to C++'s success at its onset.
In a nutshell:
This book is worth having around. I will refer back to this book often for inspiration on various design patterns. However, I would like a more modern C# publication on implementing these patterns in a way that actually leverages the language and avoids (now) known anti-patterns. It would be grand if someone took the content of this book to the next level with more modern insight.
After having finished Agile C#, I experienced enlightenment in some ways, but at the same time, I need a C# palate cleanser.
February 24, 2017
Excelent book, the exercices/examples are nicely contextualized and the reading flows naturally. The concepts that uncle Bob shows are universal and are not questions of C# only.
October 7, 2009
Great, great book. The first section describing agile development is useful for anyone in the software industry, while the remainder of the book is a must-read for all software developers. The descriptions of patterns and principles are thorough yet clearly explained, supplemented by plenty of code and diagrams. Definitely a book that I'll keep nearby when writing code.
Note: Martin's Agile Software Development: Principles, Patterns, and Practices is very similar to this book. I think Agile Principles, Patterns, and Practices in C# is an updated version of the other book, with more chapters on UML diagrams and all of the example code in C#.
Note: Martin's Agile Software Development: Principles, Patterns, and Practices is very similar to this book. I think Agile Principles, Patterns, and Practices in C# is an updated version of the other book, with more chapters on UML diagrams and all of the example code in C#.
March 12, 2016
I hate to say it, but this book was almost too practical. I don't know how he did it. It starts out really well with great and sensible ways to work together to make software. Then a flood of C# code enters. Every design principle and pattern is nuked with examples, which should be great but somehow is not. I did not need the specifics in code when I read and so it was a bit of a nuisance after the first 5 principles. It's a bit harsh, but the lay of the land is I ended up liking the book, but not more. Would probably still recommend it - depending on how Code Complete turns out.
April 10, 2016
This book is simply spectacular. In my opinion, with its simple and didactic dialogue focused on OO programming, provides the necessary security to develop any software project. Including project management, requisites analysis, architecture, code representation (UML), testing and TDD. All concepts with examples and source code, and even if the reader does not know C#, learning a new language.
March 2, 2014
If you can buy only one book on agile development in C#, this is the book you should buy. It is well written and a pleasuer to read. It has many examples in C# illlustrating agile development with patterns.
January 8, 2015
This is THE book that should be read by any developer who claims to be Agile to confront this view with reality. Amazing overview of test driven development, solid principles of object oriented design, rules of package design and practical design patterns.
December 15, 2009
GREAT BOOK!!!! I don't think that I have had more fun reading a programming book.
May 27, 2011
A must read for all software engineers
May 15, 2016
Fascinating book. Useful for OO programmers who want to improve their code quality.
Displaying 1 - 30 of 38 reviews