大道至简

一、编程的精义
所谓编程实际上就是把一件事情交给计算机去做，你认为这件事该如何做，就用“程序语言”的形式描述给计算机。程序=算法+结构，在这个公式里，代码是不存在的，存在的只是思想。

 

二、懒人造就了方法
人的精力终归是有极限的，提出新的“方法”，解决的将是影响做事成效的根本问题。

 

三、团队缺乏的不只是管理
1、从管理的角度来看，项目失败与否与项目经理的经验直接相关。
  项目的成功主要由两个方面来评估的：项目完成质量和项目完成时间。

2、体制的内涵是分两个方面的，其一是“体”，即“体系”，其二是“制”，即“制度”。“ISO质量体系”所产生的那份手册只是“制度”，在这份制度的背后，所要求的是对旧有“体系”的改变，而不是搬来一本“管理制度”给每个员工读一遍就可以了。

3、组织模式确定的同时，相应的制度也应随之建立。制定制度既要做到人性化，又要做到公平性。
通常情况下动摇制度的人往往不是犯错的员工，而是管理者自己。

4、跟随蚂蚁，但不要栽进蚂蚁洞里，尽管你也是团队中的角色，但千万记得离蚂蚁洞远点。你在洞外张望，可以发现问题，你在洞内，就只有做“循规蹈矩”的蚂蚁。管理者是那个可以在洞外放木棍的人。

5、确定被“弹性分工”的员工需要可以快速地转换到新的角色。但首先要考察的并不是他是否“有能力”胜任
这个角色，能力可以通过学习来增强，而角色的转换，则首先是思想的转换。

 

四、流于形式的沟通
1、“问道于盲”是没有错误的，真正的错误是你睁着眼睛问。

2、你要确认你的沟通方式是否有效，而不是去追求这种方式是不是UML，以及你用UML表达得是否正确。
  客户是因为他认为你理解了他的需求，而在“需求确认书”上签字，而不是因为你的UML图画得是否精准。

3、沟通的三层障碍：沟通的第一层障碍并不在于你要表达的内容，而在于你如何表达，换个说法就是不知所云。
沟通的第二层障碍出现在跟聪明人的讨论中，让人觉得“不知所为”。这种情况下应当预设前提，并尽早阐述结论。沟通的第三层障碍主要表现是：不知缓急。解决之道是不要把沟通目标设定为让对方认同。

4、沟通不过是手段，是工具的一种，而管理者的目标是项目本身。用尽可能少的人、在尽可能短的时间内做出决策，这是降低沟通成本的关键。有的“异”观点无关宏旨，无碍大局，可以存而不论。

5、应保障每一次沟通的有效性，得到的每一次沟通机会，都是向客户了解更深层次需求的机会，
因此最好在见到客户之前，就已经设计了所有的问题和提问方式。

6、应该为项目做好历史记录，历史记录为项目的后续开发、维护提供了可能，为不存在的角色留下了沟通的渠道。历史记录包括需求阶段、设计阶段、开发阶段、测试阶段等各个阶段的文档和报告。

7、在每一次回顾项目时都应该注意：流于形式的沟通，极有可能是你的项目被不断推翻和不断延迟的最直接原因。

 

五、失败的过程也是过程

1、实现才是目的，很多人把问题的本质给忘掉了。从最开始，从我们编程开始，我们的目的就是实现一个东西。
无论这个东西是小到称手的一个工具，还是大到千万的一个工程，我们的目标，都是要“实现”它。

2、越是简单的东西，往往越是接近于本质。

3、工程不是做的，是组织的。我们当然不能“做”工程，而是要“组织”工程。项目经理的工作，
  就是要去组织这个工程中的各个角色，使得分工明确，步调一致，共同地完成这个项目。

六、谁是解结的人
1、企业文化是一种群体现象。群体现象本身除了长期的自我演进之外，另一种就是由管理者所引导的团队文化
 所扩散出来并进而产生影响的现象。

2、经验，是源于对过去的思考，而不是对过去的复制。面对那些在你面前说“我们曾经这样成功地做过”的空降者，不妨先把他们想象成一条条肺鱼。只有提得出质疑，才能换个角度去看到那些成功经验所依赖的背景，
也才能看到某些成功背后的偶然的或者关联的因素。

3、应该记住管理者的责任也包括“监督，发现问题并防止扩散“。因而要主动给自己留下时间和空间来发现问题，在问题出现之前定位它、分析它，并组织人力去解决它，而不是等到问题出现之后再去冲到前面，
然后在还没有清楚地意识到问题的根源时就试图解决之。

4、先人后已，管理者一定不要忘记在开始“忙”之前做一件事：驱动你的团队。
问问自己：“如果这件事不做，会如何？那件事不做，又会如何？”找出影响面最大的一件，
交给别的人（或者大家）去做，而自己做“不是太重要”的那件事就可以了。

5、如何看待一个问题是不是问题取决于你对问题的观察角度。普通球员关注于眼前的得失，
所以看到了失球的“问题”，乔丹关注于比赛的得失，所以看到了得分的希望。

七、从编程到工程
1、语言只是工具，程序=算法+结构。这是编程的本源定义，也是原始的状态。

2、《三十六计》更多的时候是被当成方法论来读的。其根源在于“计谋”本身只是方法，而不是战略。

3、BOSS（经营者）决定了一个方向，组织者保证决策与这个方向是同步的，而工程是在这样的一个方向、
决策的构架下的一个具体行为。

4、实现是软件开发的本质需求。因而实现方法总是最先出现的，而后才有分析和设计方法。

八、你看得到工具的本质吗
1、使用工具的方法，比工具本身更关键。所以“欲善其事，先利其器”这样的言率，未见得是全对的。

2、工具的本质，如同工程与编程，单以编程而论，讲究技法之精妙，追求细节与枝节是可以的；但对于工程来说，能让团队理解、统一执行、迅速有效的实战技法，才是真实所需的。就像战争一样，团队化的工程中，
技术的优劣并不是关键。关键在于某种技法是否能为团队带来整体的成效，而不在于某个人是否喜欢，或者深谙于此。

3、沉浸于技法越深，便越容易忘记使用这种技法的最初目标和应用场合—就如同陈尧咨仅仅把射箭看成技艺，
而看不到它作为战场武器的本质;亦如同卖油翁一味演练技法之高妙，而不考虑卖油才是目的，而技法只是表面。

4、工具之用，到了融通地步，也就无所谓“选择哪个工具”了。但是所谓融通，是基于对工具背后思想的了解。

5、了解Interface之后，才真正地有了“软件设计”的观念。而一旦有了软件设计的观念，“实现”的过程，
就变得越来越不重要。

九、现实中的软件工程
1、愚公如果停下来，思考的问题可能是碎石的“方法”。而项目经理从细节中跳出来，思考的问题就应当是
完成工程的“方法”。评价这个方法的好坏的标准只有一个：节约成本。

 

2、不计成本的项目计划不会得到经营者的支持；毫无目的地消耗成本是项目中的慢性毒药；
最致命的风险是成本的枯竭。

十、具体工程
1、广义工程的定义：面向“软件活动的根本任务”；程序实现的过程无助于求解根本任务。

2、狭义工程的定义：面向“具体工程活动的需求”：实现；求解“根本任务”只是将“实现”作为一个过程或
结果的探索活动或附加价值。

3、在所有实践活动中最重要但也是最难保障的就是：控制规模。规模分成规、模两个方面，前者是边界，
后者是形态。做更多的事情，以及把事情做到“更好”，等等，这些都是项目边界的失控。

4、从思维法的角度来看，广义工程考虑的是对工程问题的“统治”，而具体工程则考虑的是“分治”。
分治关键在于隔离问题域，找到造成混乱的问题之间的关系，以及分类出无关的问题。

十一、是思考还是思想
1、知律而变，死读一本《软件工程》的人不会做真正的软件工程。