在书上看到”什么逻辑？“几个铅笔字……

从图书馆借的书，里面被”前辈“们用铅笔画的条条杠杠的，在107页的右侧几个非醒目的大字”什么逻辑？“
看样前辈与我也有相同的看法，里面的例子很多都比较牵强……例子有点生搬硬套，有时候就是甚至是在说解文字。。

不否认作者的论点，也肯定作者有很多年的经验，对很多东西有深刻的理解，但作为读者的我，却没能很好的吸收作者的思想及经验。。

读书的过程中，对soul比较感兴趣，不知道他写过书没？想读一读。。。

经常在群里面听到一些人说”牛人都是用记事本来写代码的“…… 我经常在心里自惭形秽一翻。。。。
作者也说到自己书中的例子90%是用记事本写出来的，额，这真是装B青年必备利器呀，我以后也可以在群里大喊，人家牛人写代码都用记事本的，谁还用IDE咧！
唉，说这例子感觉没必要吧，你写例子，人家是做大项目，如果还用记事本……唉！ 我还是无法想象。这有点误人子弟呀……

还有一些其它其它……

不过里面还是有些观点不错的：

/////////////////////////////////////////////

项目经理需要时间来成熟的。他需要机会来承受错误，而不是一开始就享受成功。

流于形式的沟通。
沟通的第一层障碍，并不在于你要表达的内容，而在于你如何表达。
最好在见客户之前，就已经设计了所有问题和提问方式，避免造成沟通不畅或流于形式的沟通。（即有目的性的沟通，而不是与客户交流感情）
留下历史记录，记录下自己的决策过程等，方便后来者。
如果你不懂甲骨文，那么也不要指望你的用户懂UML。

实现才是目的。实现是软件开发的本质需求。

成功的经验往往最不可信，反而是失败的经验更有价值。

经验，是源于对过去的思考，而不是对过去的复制。

团队要有远期的目标，有共同的愿景。对短期的目标也要清晰，即里程碑。

“教官”的任务：协调、督促、激励、监督和凝聚。

工作上，先人后已，即先为团队服务，然后自己再完成一些细节的事。奖励，同样也要“先人后已”。

要关注整体目标。从全局上把握，某一局部出现问题之后，要能尽快发现，并迅速调整。

不要压抑你团队成员的激情，他们提出自己的想法之后，要鼓励与引导，即使你认为不合理，或有错误，也要以引导的形式，或者干脆让他去犯这个“小错误”，从而让他在这个上面有更深刻的认识与印象。

软件工程层状模型(EHM)

工具，是为了更好的实现结果。