之后要接触更多代码管理的知识——2015踩坑有感
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了之后要接触更多代码管理的知识——2015踩坑有感相关的知识，希望对你有一定的参考价值。
前言
学习是没有止境的，管理代码的能力也永远需要提高。
前几个月还觉得R语言，业务上要用的都学得七七八八了呢，这几个月在自家部门吭哧吭哧搞报表自动化时，各个坑一踩一个准，才明白写代码，懂得一点语言特性固然重要，弄一套科学地管理代码的方法，却是势在必行。
因此在这里总结一下这几个月来我踩过的种种坑，以及之后在查阅种种大神的经验，以及学软件工程这门课时看到的一些比较妥当的方法，算是这几个月的一个总结。2016年的时候，真的要多学学如何科学地管理代码，科学开发
请注意，因为我属于跨专业半路出家写代码，刚刚入门刚刚入门，软件工程的课也才上到一半，肯定有很多概念没有厘清，下面讲的要么太小白要么有错漏，欢迎各位指点方向，多多交流多多交流
吐槽一下踩过的坑
不在博客园上阅读时才会看到的，这篇博文归博客园@尾巴AR http://www.cnblogs.com/weibaar所有
仅保证在博客园博客上的排版干净利索还有代码块与图片正确显示，他站转载请保留作者信息尊重版权啊
我自7月左右开始，逐个把部门的报表需求用R语言自动化以来，代码越积越多，需求也逐渐累积，就开始不断踩坑，
这些坑总结一下大概有以下几种：
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 ，我们只要处理一个流程、一个脚本文件就可以了，修改的是轮子，最后积累下来的不是一个又一个独立的程序，而是可以反复使用的轮子
这样做的话，随着在业务上代码写得越多，遇到重复的需求越多，我们的开发效率也就越快，这可以使我们更专注于新功能的实现，整体系统的设置，以及程序之间的差错等等。最终达到所谓“越老越吃香”的知识积累。
而做到以上这些，需要我们对开发时易变与不易变的需求进行一个精炼与提取，要及时意识到，什么是反复要做的，什么是偶尔要做的。把复杂的业务拆分，精简，提炼，看透事务本质。
资料参考
回首上文，感觉有些地方我写的还不是特别清楚。毕竟软件工程等还是新学，而且目前的代码量还没有大到需要协同合作的时候。
而随着软件，编程规模越大，其管理的复杂性也就越高，像我只是自己给自己写些几千行的代码，就已经陷入管理这些代码的困境良久。有时真的很难想象，在企业级的软件开发过程中，由几百号人一起维护一个代码库，还不能让它崩溃且时时有更新。
相信随着资历的增加，以及对世面见识的扩大，管理整个过程的复杂性，会成为我们必须要迈过的一道槛。
感谢迷茫时期参考的各种资料，并不完全罗列，想起来就追加：
知乎问答
在最后，附上自己的blog 博客总目录，博客园@尾巴AR：http://www.cnblogs.com/weibaar/p/4507801.html
以及最近也在按2016年计划 尝试运营一下微信公众号，微信搜“尾巴说数”即可，暂时刚起步还没什么内容，计划博客里放一些更有技术含量的博文，公众号里杂文多一点，有兴趣多交流。
啊哈哈2016也要坚持每月至少一博。。。
以上是关于之后要接触更多代码管理的知识——2015踩坑有感的主要内容，如果未能解决你的问题，请参考以下文章