如果提供了程序流程图，而没有表数据，我仍然会很迷惑。而给我看表数据，往往不用再看流程图，程序的结构是非常清晰的。
深有感悟，结构的设计，算法的设计都是为了数据服务的，有了数据的设计，所有的问题都会变得明了。同理，设计系统的不好，很大程序上因为数据结构设计的不好。这也说明在设计的时候，对于数据结构的设计需要给予**充分的时间以及配对的文档描述**，这对于后期的维护和开发都是大有裨益的
实际上，数据的表现形式是编程的根本。（好吧，直接上升到本质的层次了）
程序维护的一个基本问题：缺陷修复总是会以固定（20%=50%）的几率引入新的bug。所以，整个过程是前进两步然后后退一步。
为什么缺陷不能更彻底的修复？首先，看上去很小的错误，似乎是局部操作的失败，实际上却是系统级别的问题。何况后期开发的人员不是最初编写代码的开发人员，而是一些列初级的程序或者新手，他们在设计的时候往往是没有考虑全之前的设计的，导致的问题是：看似简单的任务却导致很多的bug。
结合我自己的经验，在我们的项目后期，因为时间紧张，我将部分模块的开发工作给了新的的同学，本来以为是一件简单的事情，但是后期却出现了很多的问题，甚至是非常严重的问题。这点给我的反思就是即使非常简单的东西，也需要考虑好结构，然后指导新手去完成，而不是直接告诉他们功能去实现，需要你去设计好结构，然后让他再去实现。毕竟后期加入的同学不可能也不会有时间去掌握你之前的设计，何况设计也许也是糟糕的或者是有很多坑的，再其中增加东西，不是只是简单的功能堆积，很可能会产生连锁的反应。
我们的大脑具有的多样性，自我保护和自我更新的能力，其中的秘密就是逐步发育成长，而不是一次性搭建。开发模式也是如此，迭代增量的开发，这种模式迫切的需要自上而下的开发形态。
但是软件最重要的部分一定是：人。卓越的设计者和一般设计者的产品差异差了一个数量级。卓越设计者生产的成果更快，更小，更简单，更干净，实现的代价更少。
我们理解也好，不理解也好，描述都应该简短清晰。
关于进度安排，我的经验是：1/3 计划 1/6 编码 1/4 构件测试 以及 1/4系统测试。
每个人看到每件事的目标是错误的！各个部分应该被封装，从而没有人需要或者被允许看到其他部分的内部结构，只需要了解接口。
能消除，至少是能指明有副作用的程序设计方案，对维护成本有很大的影响。
不要依赖于有副作用的方式，或者tricky的技巧，这些都可能是后期evil的根源。
人就是一切（或者说，几乎是一切）。我们行业的主要问题实质上更侧重于社会学而不是科学技术。
学习变成最困难的部分是将做事的方式向追求完美的方向调整。
不要低估产品的难度，难度估计的高点总是没有错的。
在确定任务进度的时候要争取更多的时间，这点我容易犯下的错误，不要低估了时间，按时按量的完成任务才是关键，何况很多东西就应该有固有的时间，时间紧张了，临时的方案，后面都是需要花更多的时间和精力去弥补的，为何不在开始的时候就多留一些时间，设计出一个更加有效，灵活的方案呢。
程序员都是自信的，对于进度估算上尤其如此，所以自己以后需要更加合理的估算进度，时间估算的多点总是没有坏处的。套用书中的一份法式餐厅菜单上的句子：「做好菜是需要时间的。如果人家让您多等会儿，那是为了让您最后吃得高兴。」