编写系统模块的经验总结

        前段时间在写一个系统模块,由于是第一次独立的写一个系统模块,经验欠缺,出了很多问题。事后对这次工作做了下总结,大概是以下几点:

        1) 做设计时过于乐观,轻视了设计的作用,只看到宏观上的功能,没想到琐碎的细节实现(有可能因为某些小点会影响整体上设计)。

解决办法:设计功能时,先把测试案例想好,测试驱动开发,不一定要真的去写测试代码,但测试用例提前写好可以避免很多问题(临界问题,异常处理问题,理顺思路)

 

        2) 编码过程中,急于看到实际效果,希望做出一个快速原型,为此导致了编码质量下降以及临时代码。

解决办法:如果是底层的函数,尽量避免临时代码,尽可能编写单元测试文件测试效果。

 

        3) 编码过程中发现当初设计的不合理的地方,再回过头改,浪费极大工作量。

解决办法:编写大型系统模块时,坚持自上而下设计理念,先将所有函数接口全部事先定义好,实现不考虑,之后再配合单元测试文件测试实现函数,这样编码质量会高很多,同时减少不必要的返工。

 

        4) 在编码过程中,遇到了需求变更,由于变更需要改动多处代码,但是由于没有做充分的评估就开始改动,导致改动过程中出现了一种“迷茫”的感觉。

解决办法:出现这种问题时,应当先停下来,将整个系统思路理清一下,然后确定下修改点(最好脱离电脑,用纸和笔去想!),再开始编码,思路清晰非常重要!

 

        5) 在与其他同事沟通交流时出现问题,表现为分工不明确,接口定义不明确。

解决办法:涉及到与其他人的协作,系统通过接口来进行,一定要在做之前就明确所有的接口及定义,要细到每一个参数。

编写系统模块的经验总结》上有3条评论

  1. 说实话, 如果是一年多前, 我会觉得很赞, 现在俺还是觉得很赞, 但是我觉得下次可能还是会再次得出这种结论~~~~~因为这里面很多基本都是一些无解的问题, 有的问题就是这样, 除非你解决了它, 不然你就不会明白它, 等你真的明白它的时候, 它又已经被你解决了…… 所以我现在越来越相信一句话: 做出好的设计, 除非你是天才, 或者你见过别人完成了的”解决后”的方案

    • 部分解决办法其实是已经实行了并切实有效的办法,不过确实,有些东西只听别人说的是没用的,必须自己实际的碰了次壁才能体会,所谓的人总是在不断犯错中成长就是这个意思吧

  2. 说实话, 如果是一年多前, 我会觉得很赞, 现在俺还是觉得很赞, 但是我觉得下次可能还是会再次得出这种结论~~~~~因为这里面很多基本都是一些无解的问题, 有的问题就是这样, 除非你解决了它, 不然你就不会明白它, 等你真的明白它的时候, 它又已经被你解决了…… 所以我现在越来越相信一句话: 做出好的设计, 除非你是天才, 或者你见过完美的方案

发表评论

电子邮件地址不会被公开。