眼界决定世界 奋斗成就梦想

长期的设计不足,会使软件开发节奏变成"快，慢，更慢"，可能造成这样的后果：1）系统的1.0版很快交付了，但是代码质量很差2）系统的2.0版也交付了，但是质量低劣的代码使我们慢了下来3）在企图交付未来版本的时候，随着拙劣代码的倍增，开发速度越来越慢，最后人们对系统、程序员乃至使大家陷于这种境地的整个过程都失去了信心4）到了4.0版时，或者之后，我们意识到这样肯定不行，开始考虑推倒重来

搭个架子，慢慢完善人无我有、人有我优。一、行业目前的需求状况二、常见的收集或挖掘需求的方法三、如何最大限度的挖掘用户需求 

        今年公司元旦搞了个活动 ，主要是趣味游戏，其实说是趣味游戏，主要的意思还是关于团队建设的，目的是体现大家团结一致、齐心协力的完成某项任务。主题是“（忘了）”。很多项目源自拓展训练的项目，当然其他的经理人培训上也有涉及。领导的创意不错，可以用寓教于乐来形容颇为贴切。        从某种意义上说，当今社会更强调的是团队的力量，毕竟个人英雄主义的时代已经过去了。想当年求伯君、王江民

以前也看过人件，但是基本都忘了，今天看到硬盘的角落里有个电子版的《人件》打开浏览了一下，结合我自己的想法记录下来。看好看到记录员这里，我们项目组开会时也做一些记录，基本上就是一个流水帐，XX上周做了什么，工作进展如何等等内容。确实软件开发中的记录不仅仅是会议记录。例如我们常常写完一个功能几个月后没有看了，就不知道这个功能怎么实现的了，或者说具体的一些细节已经忘的光光了。因为经常会遇到QM人员问

最近刚看完《设计模式解析》一书，总结一下书中阐述的软件设计原则： 开闭原则(open-closed principle)：模块、方法和类应该对扩展开放，对修改封闭。也就是说，好的软件设计应该是不对已有代码进行修改就能扩展功能的。开闭原则本质上意味着将软件设计成为新功能能够作为单独模块加入系统，这样就尽可能的降低了集成的成本。 依赖倒置原则(dependency invers

今天例会提了个建议：就是将单个小模块分配到每个人，当然不是像涉及的面比较宽的那种功能或者涉及到系统架构的东西，其实我提这样的想法是有原因的。但是老大们反对这么做。我的理由很简单：1、可能对于大的公司或者一个比较成熟的项目这么做是不合适，但是对于小的团队或者是处在十分尴尬位置的项目来说，我觉得是可行的。2、影响开发进度或者失败的原因通常可以总结为：（1）需求变更，（2）计划不具体管理较混乱，（3）开