你的位置:首页 > ASP.net教程

[ASP.net教程]之后要接触更多代码管理的知识——2015踩坑有感


前言

学习是没有止境的,管理代码的能力也永远需要提高。

前几个月还觉得R语言,业务上要用的都学得七七八八了呢,这几个月在自家部门吭哧吭哧搞报表自动化时,各个坑一踩一个准,才明白写代码,懂得一点语言特性固然重要,弄一套科学地管理代码的方法,却是势在必行。

因此在这里总结一下这几个月来我踩过的种种坑,以及之后在查阅种种大神的经验,以及学软件工程这门课时看到的一些比较妥当的方法,算是这几个月的一个总结。2016年的时候,真的要多学学如何科学地管理代码,科学开发

请注意,因为我属于跨专业半路出家写代码,刚刚入门刚刚入门,软件工程的课也才上到一半,肯定有很多概念没有厘清,下面讲的要么太小白要么有错漏,欢迎各位指点方向,多多交流多多交流

 吐槽一下踩过的坑

不在博客园上阅读时才会看到的,这篇博文归博客园@尾巴AR http://www.cnblogs.com/weibaar所有

仅保证在博客园博客上的排版干净利索还有代码块与图片正确显示,他站转载请保留作者信息尊重版权啊


我自7月左右开始,逐个把部门的报表需求用R语言自动化以来,代码越积越多,需求也逐渐累积,就开始不断踩坑,

(跟这段业务需求有些关系的博文见 1 2 3 )

这些坑总结一下大概有以下几种:

1、报表需求越来越复杂,逻辑本身就很复杂了,然后要做各种处理,导致代码越写越长,还很难定位说写到哪里,丢三落四

2、好不容易写好代码测试好运行,报表自动化正确了,结果业务跳出来说,要加这个图那个图,加这个数据那个数据,回去改的时候,发现代码处处牵连,往往改一个地方,就要跟着改N个地方,还容易出错漏改,维护困难

3、发现有些报表用的代码是重复的,譬如同样读取同一个数据,做同样的处理,但是因为代码常常维护,同样的步骤出现了N个版本遍布在N个程序里,容易出错

4、随着对编程语言的理解,渐渐有了更高效的方法,回首过去,觉得有些地方逻辑很混乱,效率低,但是牵连过深,不敢改

总之就是,发现过去埋头写代码行不通了,代码行数上了一定的量,修改量也上去了,在维护方面产生了更多问题。

然后就纠结啊想想想,先自己想了很多土方法,后来按着学习进度接触了一下软件工程,才发现这些问题早已经被人碰过了,然后还有了系统的解决方法,所以在这里列一下目前我觉得比较有用,值得进一步研究和实践的理念:

要用工程管理的思维去管理软件开发,在前期尽可能划分清楚需求,中间开发按模块划分,并设置好统一的接口,区分好易变与不易变的业务,做好基础分析的轮子工程,保证重复利用。

 接下来细讲一下:

1、要用工程管理的思维去管理软件开发

 在学堂在线-软件工程课上有提及道,软件开发复杂的而又多变。因为这个复杂性,才会有人引进工程的概念来管理软件开发,所以如果编程时有这个工程的底,严格掌控一下进度,学一些方法的话,可以获得事半功倍的效果。

2、要在前期研究需求,并拆分好清晰的功能块,以便逐个击破。

研究好需求的话,需求确认,返工的几率就不大,而且方向明确,不容易在分析分析过程中迷失一切。

然后需求确认,就可以把程序的大体架构给设计出来,划分好功能块了。然后一来,在组织代码时,可以按功能块分区,易于定位长代码(譬如分不同的脚本,或者用{}等括起来,用notepad++打开时,可以直接把这一部分的代码块按层次折叠)

其次呢,功能块拆分清楚了,就可以罗列一下它开发的难度啊关联度啊,排个进度表,有空时就专门盯着里面一块模块做,一次就解决一个问题,直接,方便,轻巧。

3、划分功能块后,通过流程图结构图的方式,把大的功能块连接起来,统一接口

在研究需求,划分大的功能块之后,整个程序的大体流程图与结构图也基本可以画出来了。

举 例来说,用R做一个有4-5个源数据的自动化报表时,可以把源数据1、2、3、4等都罗列在读取源数据这个功能下,再把他们之间的关系、筛选条件、处理方 法等,都画在流程图上。把源数据、中间步骤、最终结果在编程前都罗列上去,这样这个自动化报表的流程是可以复制的,而且开发和优化时,就可以快速定位代码 位置,可以做小范围的迭代开发,一步一步把复杂系统完善掉,避免写着写着代码就迷失了方向。

不在博客园上阅读时才会看到的,这篇博文归博客园@尾巴AR http://www.cnblogs.com/weibaar所有

仅保证在博客园博客上的排版干净利索还有代码块与图片正确显示,他站转载请保留作者信息尊重版权啊


而 这个还有一个好处,就是流程图可以清晰看到功能块之间的关系。那我们就可以在写各模块或函数之前,先厘清它们之间共同的一个接口。以避免说,修改某部分代 码,然后在不知情的时候,影响了后续所有代码的开发。保证每一块之间都是相互独立,关系明朗的,这个可以减轻很多后续的编程工作。

请看下图为一个简单的示例:

4、注意区分易变与不易变的需求,在处理业务时,提炼业务,积累代码库。

有听说一个观点,一个好的程序员,往往能应用自如很多通用的功能模块。在做系统开发时,他们往往不是从零开始编程,而是把一些通用的模块堆积木一样堆到系统上,再厘清各方面的关系与兼容性,实现一个快速开发的过程。

而事实上,在业务中,有些需求是常常出现的。

譬 如说我去做R语言的自动化报表,一个部门里常用的源数据,往往也就那么几类。我完全可以专门写一个小的模块去处理一类的源数据,然后每次做分析时,就把相 应的读取数据模块取出来,直接引用到新的分析里。并对读取数据的模块做统一的管理和调度,保证版本统一。如此日后如果要做什么分析,就不用从另一个程序脚 本里把代码复制过来,而是修改这个读取数据的流程,保证其有相应的分类,这样,修改一处,或者哪个出BUG ,我们只要处理一个流程、一个脚本文件就可以了,修改的是轮子,最后积累下来的不是一个又一个独立的程序,而是可以反复使用的轮子

这样做的话,随着在业务上代码写得越多,遇到重复的需求越多,我们的开发效率也就越快,这可以使我们更专注于新功能的实现,整体系统的设置,以及程序之间的差错等等。最终达到所谓“越老越吃香”的知识积累。

而做到以上这些,需要我们对开发时易变与不易变的需求进行一个精炼与提取,要及时意识到,什么是反复要做的,什么是偶尔要做的。把复杂的业务拆分,精简,提炼,看透事务本质。

资料参考

 

回首上文,感觉有些地方我写的还不是特别清楚。毕竟软件工程等还是新学,而且目前的代码量还没有大到需要协同合作的时候。

而随着软件,编程规模越大,其管理的复杂性也就越高,像我只是自己给自己写些几千行的代码,就已经陷入管理这些代码的困境良久。有时真的很难想象,在企业级的软件开发过程中,由几百号人一起维护一个代码库,还不能让它崩溃且时时有更新。

相信随着资历的增加,以及对世面见识的扩大,管理整个过程的复杂性,会成为我们必须要迈过的一道槛。

感谢迷茫时期参考的各种资料,并不完全罗列,想起来就追加:

学堂在线-软件工程

知乎问答

有哪些老鸟程序员知道而新手不知道的小技巧

维护一个五六百行的程序就已经力不从心了怎么办?

业务代码相关

程序员新人怎样在复杂代码中找 bug?

在最后,附上自己的blog 博客总目录,博客园@尾巴AR:http://www.cnblogs.com/weibaar/p/4507801.html

以及最近也在按2016年计划  尝试运营一下微信公众号,微信搜“尾巴说数”即可,暂时刚起步还没什么内容,计划博客里放一些更有技术含量的博文,公众号里杂文多一点,有兴趣多交流。

啊哈哈2016也要坚持每月至少一博。。。