大道至简——书摘与思考

第一章编程的精义##

书摘

• 编程的第一要务是先把事情分析清楚，事件先后的逻辑关系和依赖关系搞清楚，然后再去代码实现。一接到任务就开始Coding的程序员，通常就是加班最多的程序员。
• 记住：积极工作和勤于思考都要占时间。
• 程序 = 算法 + 结构 算法是对一个程序的逻辑实现的描述，而结构是逻辑实现所依附的数据实体；在这个公式里，代码是不存在的，存在的只是思想

思考

• 所谓代码只是你思考逻辑的体现，所谓编程只是把你的逻辑换算成机器认识的语言的过程是个体力活；
• 古人讲谋而后动，与今天的编程也是同理的，回想自己独自加班的日子是否也有几天是因为自己没有搞清楚逻辑或者业务没有理清造成的了？

第二章 是懒人造就了方法##

书摘

• 愚公可以多吃点饭，多加点班，但突破不了人的精力的极限。
• 程序=算法+结构+方法 这里的方法是指在大型程序中如何组织和构造工程，如何分配工作，是编程从一个人的事推广到一个团队；

思考

• 在面对以传统方法做事是不可能完成的任务时，我们是否选择个当个懒人，从新的角度思考业务，思考过工作；
• 面向对象编程与面向过程编程，两者间有很多联系，例如：我们的对象在实现具体的方法时还是过程的，是顺序执行的，面向对象是站在一个宏观的层面让我们来我们的程序进行思考，让我们以系统的方式对我们所面对的业务进行思考，如果在庞大的工程中仍旧以面向过程的方法来思考我们的业务，我们虽然仍旧能完成但是工作效率和时间也许会让我们望而却步。

第三章 团队缺乏的不只是管理##

书摘

• 有了确定的团队模式，才能寻求相应的管理制度，并且才能把这样的制度实施在团队之上。
• 开发经理在任何时候，明确自己是在进行“团队内协作”、还是“团队管理(和组织)”、还是在与“团队外交流”。
• 实际上，开发团队并不需管理。或者说，在你还没有弄清楚状况之前，不要去管它
• 确定被“弹性分工”的员工需要可以快速地转换到新的角色，但首要考察的并不是他是否“有能力”胜任这个角色。能力可以通过学习来增强，而角色的转换，则首先是思想的转换。

思考

• 我们公司的团队模式： 业务人员拿下项目 ——> 领导决定项目是否可以做 ——>美工组出界面——> 开发组开发 这里我们公司的整个团队缺乏了很多要素：
  • 1. 项目谁来跟进，谁来决定产品的问题，谁来负责和用户沟通需求，谁来组织需求 目前：由业务人员牵头获取需求，项目开发主要负责人来组织需求，组织美工，组织设计，组织开发，组织测试 对项目负责人的要求很高，而且更多时候一个项目只由一个人负责。
  • 2. 项目谁来测试审核，是用户，是业务人员，是程序员自己？ 目前：由程序员自己来测试，公司内测，三方公司协助测试

第四章 流于形式的沟通

书摘

• 最简沟通
  • 客户在公司层面的外在表现、内部机制和运营管理手段。
  • 客户在项目中既已明确的需求和可能发生的需求，以及客户围绕其公司行为(和方向)所提出的需求

思考

• 与客户沟通，流于形式的使用各种建模语言或者其他规定的来做需求分析无异于问道于忙，其难度和要求客户会编程序一样，而当前最直接和用户沟通需求的方式，建议使用：
  • 初期使用 流程图+文的方式进行沟通，流程图方便我们描述业务的运行，文字方便描述我们运行过程中的细节
  • 中期使用 静态页面或者PS效果图+标注说明 这静态页面会让用户有很直观的感受，标注能说明细节问题
  • 后期使用 如果可以不停的发布你的工程代码，让用户持续使用而不是一定要等到交付的时候才能使用【建议能找到每个模块的负责人来进行测试、使用、反馈】