回头为自己的代码减负

闲话：

      或许很多初级的程序员在问，为什么在一个系统开发的前期需要画E-R图（分析E-R图），甚至还需要用UML画各类相关的图来表示你开发意图，比如：用例图，类图，时序图，角色图.....等等，其实没有其他意思，这好比造房子一样，需要前期建筑工程师通过图纸设计出一栋大厦的“原型”，只有原型定义好了，他们才能进行成本预算和工期预算，其实工程类的思想是相通的，所以为了避免你开发过程中，不成为“修补”裁缝，个人认为需求分析，系统架构和设计是决定一个项目成败的关键。

 

      回头看自己写的东东，确实总有不满意的地方被找出来，或许离现在的时间越久的项目，再哪出来分析，越让自己看不上眼，这其实是一个很简单的回答，因为我每天在进步，每天在学到新的东西。这敲代码的确如同练功夫一样，讲究“内力”，程序员的内力来自哪里？他的功力怎么修炼深厚？我总结出了一句话“多看别人的东西，对自己的东西举一反三”，这两天在修改前2个月开发的项目，修复一些测试出来的Bug,结果让我苦笑不得，虽然我的注释非常详细，但数据库某些字段，咋一看还在发呆，不记得做啥用的啦，很多处代码十分臃肿，结果修改，以前慢的不慢了，所以让我深刻理会，开发完一个项目为自己的代码减负非常必要。好，废话不多讲，代码的优美程度决定了程序的健壮性和执行效率，所以在我们每完成一个功能模块的时候，或是完成一个项目测试的时候，要学习微软的技术，他们那种对待代码的精神，不仅需要测试它是否满足当初的功能需求，还要考虑性能，这个性能需要你重复测试看执行时间复杂度的分布，或许有人问：“2个技术同时开发一段代码，一个人1小时完成了，另一个人花了1天完成的，谁的最优呢？”，其实没有绝对说法，开发项目并不是你越快越好，当然在中国市场，那么一大把人都是急功近利，不考虑后果的，如果仔细想想，我们不能说花1小时完成的那人非常棒，也不能说花1天写完的那人非常差，看要看本质的代码质量是否最优，随便让我想起了，最近热议的“程序员绩效考评”这个话题，在中国，这个考评绝对无法用规则衡量，只能相结合考虑。