在文章中这样说到：
最好的团队组成应该是类似外科手术队伍结构——领头羊只能有一个，其他人辅助它来完成任务。
没有高低贵贱，只是分工不同。这样我们能够获得减少沟通，提交生产效率等等诸多好处，而且
最重要的是我们将获得概念的完整性。
人们总是希望一切的事情都尽在掌握之中，所以总是试图在制定完美计划之后一路顺风顺水地执行下去。
但是软件维护是一个提高混乱度（增加熵）的过程，所以出现前进两步，后退一步；甚至前进一步，后退
一步都是很正常的。而且随着维护的深入，会发现用在修复原有设计上瑕疵的工作量越来越少，而早期
维护活动本身所引起的漏洞的修复工作越来越多。正如大思想家斯宾塞·约翰逊曾经说过“唯一不变的是
变化本身”，我们要为变更设计系统，为变更计划组织架构。
个人感受：
在开发项目前的工作中，我之前经常没有构思，计划的很详细，直接有了一点想法就去编写代码，想着走一步
看一步，于是在后期的工作中，经常去大段大段的修改之前的项目构造，牵一发而动全身。在别人都已经开发完成
时我的系统结构还有问题，不完善，分崩离析。在编着编着就发现自己系统的不足之处，就立马修改，然后越改越多
工程量非常大，不如从头编写。
解决办法：编写开发文档，将自己的思路整理，系统模型建立好之后，分版块编写，做到高类聚，低耦合。各个功能模块
分割，独立性强，如果再发现有不足之处时，修改的代码量就会几何下降，提高效率。