在本书的后面，作者谈到了竞争。他们在做着相同的事，又都有各自的算盘。他们一面打压对手的优势，一面又借助对手和同盟的力量来削弱自己的劣势或者补充实力。这就是纵横吧。不过，这里我可能还很遥远。
还有一句话，我颇有感触。作者会把客户的数量以及耐心当做(客户)成本来计算。其实别人的需求和感受很多人都会忽略，即使这些被认为刻意的放大和忽略。比如你打电话给别人，有多少次考虑过对方在干什么？就好像在开发的过程中，大家都没有想过客户的心思。
自上而下和自下而上的思考方法。其实，我现在还是属于自下而上的，我会先考虑小的功能，它如果需要什么消息，产生什么消息，再编写与其相关的函数。这并不难和麻烦，因为过程再繁琐，都是我一个人的，我不需要和别人沟通和解释。但我估计涉及到工程的话。就需要自上而下了，首先的需要分析，设计，预算什么的。统统想好和客户好解释，队友也好理解。
随着UML的学习深入，我对其的理解也在加深。我的感觉就是，这真不是一个好完成的视图和word文档。而且就算是阅读理解起来也是十分的麻烦。为什么非得用UML啊，没有别的更好的方法了吗？我知道没有。。。
目标和质量的矛盾，开发人员经常不归咎于自己。不谈工程来说，人们可能就不喜欢承认自己错误。目标可能在平衡中确立，但质量却要在过程中控制。客户要求质量数为100%的话，开发人员需要120%的时间和100%的资源实现。但因为某种原因，开发人员只拿出了80%时间和资源做到了自己以为的100%的质量，但在客户眼里可能也就70%。是谁的错？开发人员不负责吗——他们十分想留住你的注意力？是交流上的障碍，信息的流失吗——我们有很多占更多精力的建模。所以作者说目标大，不好实施，无法平衡，客户也不愿意降低协议目标和要求。我要求100分，你再不济也能来个80分，我要只要求80分，你没准就只能到达70了。要是我会这么想。
作者在解释枝节这个名词，这还是我第一次见到它。枝节是技术和方法的支部，与细节不一样。听作者的意思，很多人都会弄不懂这两个词的意思吧。
作者在本书的最后一章最后一段告诉我，只分一二三四声不叫伦平仄。颠覆了我的世界观。说到这些，是想告诉大家不要拘泥于古今，这个那个的区别。要灵活运用技术，技巧方法原理，灵活变通，回避错误。
后面有很多外国朋友发表了自己的感悟，大多都在说要注重思考，领悟什么的。有一个人叫Aimingoo,他说：
我们做事，总是做到后来才发现道理与专家们说的是一样的。我读书的时候，以及在Coder的一个很长的阶段，也是很排斥“专家”和“理论”的。但现在我却在思考理论的东西。
这可能与我之前的读后感所说的一样。现在看专家说的话讳莫如深，摸不到头脑，没有意思。但可能多少年后我会理解这些话，肯定这些话，说出这些话吧。
