浅析非软件行业人员自主开发的不良习惯及改进建议

吴浪

摘要：介绍非软件行业人员自主开发本行业内软件的优势和在软件开发的需求采集、系统设计、编码、测试等方面容易出现的一些不良习惯，以及如何扬长避短的几点改进意见。

关键词：业余程序员；软件开发；不良习惯；行业标准；改进建议

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2016）04-0102-02

Simple Analysis of Bad Hadit and Improvement Measure when a Junior Software Developer Developing Software

WU Lang

（501 Station of the GAPPRFT，Kunming 650302，China）

Abstract： Analysis of some bad hadit and improvement measure of equirements Analysis， system design，software coding and software testing when a Junior software developer developing software.

Key words： junior software developer； software development； bad hadit； industrial standards； improvement measure

近年来随着计算机技术的普及，各行各业内都有自行开发的各种软件，广电系统由自己的职工进行了不少的优秀的自主开发。各种类型的自动化控制系统、节目播出监测系统、办公自动化系统等。这些系统的投入使用和稳定运行，提高了各机关、台站干部职工的工作效率，提升了设备运行的稳定度，在一定程度上把广大干部职工从手动操作的繁琐工作中解放了出来。

由各单位的职工自主开发系统有很多优点：首先是节省成本，更重要的是我们更了解自己的设备和工作细节，更容易清楚地知道我们想要的东西是什么样的。在开发中可以轻松达到无障碍沟通和协作，能更好地做好开发的需求分析、系统设计，后期维护也更为方便。

缺点在于我们是业余开发人员，开发过程中容易有很多不良习惯：这些不良开发习惯可能造成资源浪费，加大软件维护的成本，有些甚至制约整个系统的生命力。在软件开发过程中，大多数的问题都是由这些需求分析、软件设计和编码的不良习惯造成的，改变这些习惯，你会获得更高的效率。

1 业余程序员容易出现的不良习惯及改进建议

软件开发流程一般包括以下几个步骤：需求分析、系统设计、编码、测试、投入使用、后期维护。下面我们从一步步来探讨业余程序员容易出现的不良习惯及改进建议。

1.1 业余开发人员容易不够重视需求分析和总体设计

我们虽然更了解我们的设备和工作细节，更容易进行需求分析和软件设计。但是业余开发人员也容易不太重视需求分析和总体设计，比如需求分析和总体设计花的时间和精力不足，很多内容停留在大概、差不多的层面，没有具体化、细化、完整化、文档化，随后就开始匆匆编码。认为我们可以一步一步来，先编写一些程序出来，有什么没想到的地方再慢慢改。编码过程中突然想起来还有什么需求或者使用者提出之前没想到的需要，又来改编码。就这样不断进行很多次的修改。这样最终也可能能把系统开发出来，但是这样的系统执行效率低下。开发软件的最忌讳不停的因改需求而改代码，尤其是在软件开发后期该需求极容易导致程序修改遗漏内容、变量错误等等问题，导致系统执行过程中出现异常报错、软件跑死等现象。如果急于动手编码，而忽略需求分析，很可能南辕北辙，使开发变得毫无意义。需求分析才是整个开发过程中的核心部分，正所谓“磨刀不误砍柴工”。只有真正理解了需求，才能顺利开发出我们真正需要的软件。

采集需求时，有必要时可以对客户进行一定的培训，让他们知道怎么提需求，怎么把需求提的更加具体、准确、完整，在这个阶段多和客户沟通，尽量避免或减少开始编码后改需求，以及因此导致软件编码错误和运行效率低下等问题。

需求分析中的需求不只是使用者的需求，还要按照行业内的软件开发规范来进行，同时也要考虑软件长远运行的硬件、软件环境等因素。例如，目前Windows XP已经停止升级了，你还在XP平台下开发软件，当你千辛万苦地开发完成提交系统时发现大家都在用WIN7甚至是WIN10。你的软件可能无法运行。

软件设计正如你要造一幢房子，在开始砌第一块砖之前，你必须事先画好建筑图与蓝图，在你开始浇铸水泥之前，你必须让人评审的蓝图并获得通过，你要先做好比较完整详细的设计再进行后面的工作。另外要学习行业内制定的相关规范和标准，并严格按标准检查你设计的系统，只有这样你最后开发出来的系统才能与业内其他软件系统完美整合为一个整体，流畅交互数据，同时还保证了系统的通用性。

1.2没有良好的文档习惯

我们在谈编码前不得不提的是要养成良好的文档习惯。良好的文档是正规开发流程中非常重要的环节，一个好的程序是先写好设计文档再进行编程的。如果你不写文档，一开始就写程序，这样你就不会按已设计好的路线走，而是想到哪写到哪。尤其是部分刚开始编程的人容易有如下的代码习惯，如：学会一招，就用一招，不管方法是不是适合系统，硬塞进去。小功能还好说，要是大功能，就容易混乱甚至失控。写文档时只要能将你的设计思想及实现算法或步骤描述清楚就好，另外要善于利用图表来说明你的思想。

1.3编写代码时容易有不进行格式化、规范化、加备注、模块化等习惯

对代码进行缩进或统一格式，可以让人更容易阅读，也容易对错误进行定位，不易出现混乱与bug，另外也方便代码审查等等。代码备注也很重要，很多业余程序员不喜欢在代码里加备注，觉得麻烦，觉得自己完成了自己的模块就行。事实是躺在代码行里的备注永远躺在代码行里，而躺在脑海中的备注却会在日复一日的工作中去留无踪。无备注，无规范无疑是害人害己的代码习惯。对代码格式化，可以考虑使用代码美化器，它能根据你的设置对代码进行格式化。

面对没有模块化的代码就像是一个乱搭起来棚子，没有一处敢轻易地修改，系统脆弱，而且随着时间的推移，其维护越来越困难，埋下大的隐患。让每个函数实现且只实现一个功能，这样会让函数更短，相应的就好理解和维护。比较长的函数里面通常有很多路径，这对测试来说也比较难。

1.4代码没有清晰地表达意图

编写代码时，应该更注重可读性，而不是只图自己方便。代码被阅读的次数要远远超过被编写的次数，所以在编写的时候值得花点功夫让它读起来更加简单。

1.5不把警告当错误看

代码编译时产生了警告，我们还是可以运行程序。那么如果我们忽略警告信息继续开发代码，会怎么样呢？这样做等于是坐在了一个嗒嗒作响的定时炸弹上，而且它很有可能在最糟糕的时刻爆炸。代码的行为会变得无法预测，其质量会直线下降。

解决方法是设法让编译器将警告作为错误提示出来。如果编译器允许调整警告的报告级别，那就把级别调到最高，让任何警告不能被忽略。这个小小的设置，可以大大提升团队签入到源码，控制系统中的代码质量。

1.6提供有用的错误信息

当应用发布并且得到使用之后，仍然会发生各种问题。比如计算模块出错，与数据库服务器之间的连接丢失。这些情况要尽量以优雅的方式进行提示或处理。如果你注意的话，在开发阶段就能发现这个问题的早期警告。当出现错误时一方面要提供给用户清晰、易于理解的问题描述和解释，使他们有可能寻求变通之法，而不是让系统自己报一些让使用者完全看不懂的错误信息。

1.7不够注重软件测试

部分业余程序要容易忽略软件测试的重要性，软件编码完成后简单试运行，基本功能正常就上机了。这样可能导致的问题不言而喻。软件测试方面应该投入的足够的精力和工作量，通过测试和修改把软件的一些错误提前排除掉，力争正式使用后稳定、可靠、准确的运行。系统测试的对象不仅仅包括需要测试的系统的软件，还要包含它所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。有很多错误要在真实运行环境下才能得到比较全面的暴露。必要时要邀请软件使用者参与测试。

有些行业内的大部分软件规模都不大，但是同样需要严格的软件测试，以保证它的可靠性。对于一些要求比较严谨的工作环境，稍有失误可能不但不能提升我们的工作效率和质量，反而导致设备运行事故也是有可能的。

1.8不注重系统内统一制定的标准和规范的学习和执行

不严格遵循系统内的规范进行开发，所开发的软件没有标准化，导致和系统内其他软件整合后经常出一些异常错误，甚至无法与系统内的其他软件整合，成为孤岛。

2 结束语

我们业余开发人员应当充分发挥我们作为自己人开发的各种优势，充分做好需求采集和系统设计，避免常见的业余程序员容易出现的编码问题。这样我们就能开发出比专业软件公司开发的更适合我们工作的软件，为我们行业的工作添砖加瓦、做出自己的贡献。

参考文献：

[1] Jim McCarthy.软件研发之道[M]. 北京： 人民邮电出版社， 2011.

[2] Brechner E. 代码之殇[M]. 林锋， 译.北京： 机械工业出版社， 2013.

[3] 史亮. 软件测试实战[M]. 北京： 人民邮电出版社， 2014.

[4] Claes Wohlin，佩尔. 经验软件工程[M]. 北京： 机械工业出版社， 2015.

[5] Venkat Subramaniam， Andy Hunt. 高效程序员的45个习惯[M]. 北京： 人民邮电出版社， 2014.