软件开发需要注意的细节！

1.梳理系统流程

用一个很简单的例子来说明流程梳理对软件开发的意义。比如你要演讲，但是这个演讲是即兴的。如果你不是一个专业的即兴演讲者，你必须在没有准备的情况下给台下的人演讲。这时候你走在舞台上，脑子里就没有组织好的演讲内容了。演讲结束后，后台的人不知道你在说什么。也许你不知道你刚才说了什么。这就是失败。软件开发也是如此。而不是仅仅得到一些文档，每个开发人员都要坐在一起，由经理或者其他熟悉软件业务的人进行严谨的描述和讨论，让参与编码的开发人员不仅能够熟悉自己想要做的功能的细节，还能够对系统有一个大概的了解和熟悉。只有这样，在开发过程中，才会避免一些不必要的问题，发现一些隐藏的问题。修改问题需要花费大量的时间和精力。比如编码和业务有冲突，我遇到过，代码不能完全跟业务走。业务在符合正常情况下，也会根据编码风格进行适当调整。最终达到一种整体和谐的美感。在编码前期，参与项目的每个人都要清楚的知道我想做什么，最终的目标是什么，我想关注什么，我需要讨论或者解决什么顾虑。准备工作完成后，每个团队成员的项目进度都非常清晰。

2.技术框架的选择

通常，在选择技术架构时，有几个要点需要衡量：

第一点：效率。

开源领域有很多框架可以达到同样的技术目标。比如web开发，最后开发出来的产品都要通过性能级别。如果选择错了，整个软件可以说是失败的，因为不能用。你需要重新选择技术框架，让每个开发者在新的框架上重新开发，这就是开发一个新的软件。

第二点：成本。首先是学习成本，其次是经济成本。我只讨论学习成本，因为我非常反对使用商业软件。用这些钱去购买商业软件，会更好的激励和培训员工。如果这里什么都不讨论，不商业化就安全，开源就安全。就说一句：大部分情况都浪费了！关于学习成本，要考虑团队实力和团队人才的培养方式。如果项目团队没有任何培训和学习氛围，那么为团队选择框架的原则很简单。这种情况下，要选择自己熟悉的、能确定的；还有一种情况是团队中有实力比较强或者学习能力比较强的开发人员，你可以选择一个最适合整体架构的新的技术框架，绝对重视，因为这是一个新事物，风险也很高。只要你重视，技术上可行，结果就是完美的；这是基于团队实际情况的参考，勇气也很重要。

第三点：稳定。

在选择合适的软件版本时，个人倾向于在最新的平台和框架上开发，因为新的特性，有可能新版本已经优化了。

考虑到稳定性，比如根据实际情况，我们选择使用A框架。假设A框架有两个版本，V1和V2。V1是稳定版，V2是测试版，V2增加了一些新功能，正好满足你的项目需求，稳定版会在你完成编码之前发布。所以目前有两个选择。第一种是选择V1版，选择新的B框架，满足项目需求。第二种选择是选择V2测试版，最后等到稳定版发布了再来替代。但是，风险高于第一种选择。一个好处是这个框架完全可以满足你的项目需求，而且成本比较低。两个案例我都练过。

3.编码

软件产品编码中需要注意的一些宏观问题；

第一点：代码风格。

一个年轻的团队很容易遇到这个问题。开发一个软件，回头看里面的代码，编码风格是不统一的。五个开发者有五种代码风格！如何避免这种情况，只能在编码前宣讲讨论代码编码风格，制定规则下来，大家按照这种风格写代码。另外要做的就是查代码，不要因为忙而忽略这个，每周花一个下午看别人的代码，不仅能看到一些问题，还能看到自己的一些问题。经过一段时间的开发，代码不断调整，最终的源代码好像是一个人完成的！所以在开始工作之前要做好这方面的工作，软件的维护时间还是比较长的。如果整个代码一塌糊涂，我想没有人愿意维护这么糟糕的代码。我遇到过这样的项目，有很深的体会。

第二点：评论。

注释可能比风格的统一更难。我想你不会这么想。我也觉得我理解错了，因为写批注比编码容易多了。不，很多人应该看过国内一些开源程序员写的开源软件。他们崇拜吗？哦，我也看到了。说说我的感受吧。首先，代码中的注释很少。一个类文件只有代码，注释很少。不知道他怎么想的。即使简单的代码也必须有方法和类注释。其次，代码中有稀疏的注释，很难得到。成绩是英文的，文档都是英文的。为什么一个会说中文的家伙会做英文版？另外，打印日志没有添加级别判断，里面有一些编码问题。很想骂几句，但是人家毕竟是开源的，不容易啊！精神可以鼓励，但态度值得怀疑。如果你现在刚刚完成编码，

第三点：代码目录结构。

这点和编码风格是挂钩的，也可以属于代码风格里面的一部分，但是单独拿出来肯定有独特的含义。你有没有想过或者遇到过通过代码目录结构就能够大致看懂该项目是要做什么，有哪些功能，如果看到这样的工程是不是有一种很想再往里面看的冲动？本人有参与这样的项目编码，当时我们做的还比较成功，刚开始做有点不习惯和编码风格不同，关于代码目录结构我们进行了单独的讨论，根据本身的技术架构来制定的，把这点做好，开发者编写代码更加清晰了，效率也有所提高了，后期维护哪怕是新人来维护，只要稍微讲讲，也会很容易的接受，一切都变得更加简单了。

第四点：命名。

这点也可以同属于代码风格。坦白讲单独拎出来说也没有多大意思，因为代码风格里面就会强调，但是你不觉得这么重要的东西很容易忽略吗，比如大小写，id我是写Id还是写成ID呢，没有多少人会在意，只有出现问题了，代码冗余量增加了，才会发现，命名也是非常重要。还有一些，类文件的命名词不达意的，我想提醒你的是，既然这么重要那么请谨慎对你的代码进行命名！

第五点：赞成有必要的重构。

重构需要注意时机，有两个点是最好进行重构了，第一点是在自己编写完代码以后进行优化和重构，转测试之前；第二点就是当项目初期大家没有意识到要去重构，也就是第一点没有做充分，导致代码重复率比较高等一些整体问题，在这种前提下找一个时间段，对整体代码进行一次重构计划，这是有必要的。

第六点：一些提高代码的工具使用。

在这里简单列出几类工具，网上有很多资料，需要根据自己的语言进行选择。

第一类：代码自动检视bug工具

第二类：代码统计工具

第三类：代码重复率和复杂度工具

第四类：代码覆盖率工具

第七点：不要随意修改代码，特别是别人的代码。

修改代码应该是放在一个时间段，而不是随意进行修改，目前比较流行的敏捷开发中有一个现象就是版本发布比较频繁，修改代码是有很大的风险的，修改的代码很有可能是公共代码，多处地方有调用，很有可能造成其他地方出问题，小问题解决，大问题来了。当需要修改其他开发人员的代码时一定要和对方沟通下，避免造成不必要的误会和引发潜在的问题。

*编码中需要注意的一些微观问题

这些就是编码功底了，我自身的感受就是，要不断的回头看看自己的代码，很多地方值得你重新思考和关注。

平时有时间可以静下心来阅读比较经典的书籍，看不懂或者不太记得没有关系，重新再看。

4.测试

作为一个开发人员所接触的测试首当其冲的就是编写单元测试用例，尽量覆盖每一个场景，这对软件质量起到一个很关键的作用，为了避免与测试人员反复沟通增加无谓的成本，开发能做的就是写单元测试发现一些潜在的问题，把大部分的bug提前发现。从管理角度来讲，测试也会轻松很多。开发一款相对完美的软件绝对是一个优秀程序员的追求。也是在程序员这条道路上的一笔收获