1.系统流程梳理

举一个非常简单的例子来说明流程梳理对于软件开发的意义。例如，如果你想发表演讲，但这次演讲是即兴演讲，你不是专业的即兴演讲者，所以你必须毫无准备地面对它。观众席上的人们正在发表演讲。这时候，当你踏上舞台时，脑海中的事物还没有形成结构化的演讲内容。讲座结束后，后台的人不知道您在说什么。也许你不知道你刚刚说了什么。怎么了，这是一个失败的演讲，没有充分准备。软件开发也是如此。每个开发者不仅应该拿到一些文档，还应该坐在一起，由经理或其他熟悉软件业务的人进行严格的描述。并进行讨论、改进，使参与编码的开发人员不仅可以熟悉他们将要执行的功能的细节，还可以对系统有一个大致的了解和熟悉。只有这样，在开发中才能避免不必要的问题。例如，编码和业务之间存在冲突。之前也遇到过，代码无法完成。随着业务的发展，业务在满足正常场景时也会根据编码风格进行适当的调整。最终达到整体和谐的美感。在早期的编码阶段，参与项目的每个人都应该能够清楚地知道我想要做什么，最终目标是什么，有一些我想要关注的点，以及我需要讨论或解决的疑问。准备工作完成后，每个团队成员的项目进度都非常清晰。

2. 技术框架的选择

一般来说，选择技术架构有几个衡量点：

第一点：效率。

在开源领域有多种框架可以完成相同的技术目标。例如，在Web开发中，开发的最终产品必须通过性能测试。如果选错了，整个软件可以说是失败了，因为它无法使用。您需要重新选择技术框架，让每个开发人员再次在新框架上进行开发。这是开发一个新的软件。

第二点：成本。

一是学习成本，二是经济成本。我只讨论学习成本，因为我非常反对使用商业软件。用这笔钱来激励和培训员工的商业软件会更好，所以我不会在这里讨论。 非商业的东西是安全的，开源的东西也是安全的，只想说：大多数情况下都是浪费！关于学习成本，要考虑团队实力和团队人才培养方式。如果项目团队没有任何培训和学习的氛围，那么团队选择框架的原则很简单。在这种情况下，选择您熟悉并有信心的那个；另一种情况是团队中有很强的开发者或者学习能力很强的开发者，那么你可以选择一个相对最适合整体架构的新技术框架并给予绝对关注，因为这是一个新事物，风险也很高，只要注意，技术上可行，结果是完美的；这个是以团队的实际情况为参考的，勇气也是很重要的。

第三点：稳定性。

选择合适的软件版本，个人更喜欢在最新的平台和框架上进行开发，因为有新的特性，并且可能在想要的版本中进行一些优化。

出于稳定性的考虑，例如根据实际情况选择了一个A框架。假设A框架有两个版本，V1和V2。 V1是稳定版，V2是测试版，V2还加入了一些新的版本。 ,而且这些功能刚好满足你的项目需求，稳定版会在你编码完成之前发布，那么在第一个选项前面有两个选项，选择V1版本，选择一个新的B框架来满足项目需要，此方法风险最低；第二种选择是选择V2测试版，最后等发布后替换稳定版。这种方法也是可选的，但风险比第一种方法高。一个优点是这个框架可以完全满足你的项目需求，而且成本比较低。这两种情况我都练习过。

3. 编码

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

第一点：代码风格。

一个年轻的团队很容易遇到这个问题。一个软件开发出来后，回头看里面的代码，编码风格很不一致。 5 位开发人员有 5 种编码风格！如何避免这种情况，只能在编码前宣讲和讨论编码风格，制定规则。每个人都以这种风格编写代码。要做的另一件事是检查代码。不要因为你很忙而忽略这一点。 , 每周花一个下午看别人的代码。不仅可以看到一些问题，还可以看到自己的一些问题。经过一段时间的开发，代码不断调整，最终的源代码似乎是一个人完成的。相同！所以在开工前，把这方面的工作做好，事半功倍。还有很长的软件维护工作要做。如果整体代码乱了，我想没人愿意维护这么糟糕的代码。我遇到过这样一个项目，对它有很深的了解。

第二点：注释。

比风格统一的更难的可能就是注释了，我想你不会这么认为，我也想自己这种认识是错的，因为写注释这种活总比编码要容易得多吧，不是这样的，很多人应该都看过国内一些开源的程序员写的开源软件吧，很膜拜吧？呵呵，我也有看过，说下我的感受吧，首先代码很少有注释，一个类文件看下来只有代码，注释非常稀少，不知道他是怎么想的，再简单的代码也要有方法和类注释吧；其次，代码里面有稀疏的注释，好不容易啊，结果是英文的，还有文档里面都是英文的，一个说中文的家伙为什么搞成英文版的呢。另外，打印日志不加级别判断，还有一些编码问题在里面。很想骂几句，但是人家毕竟是开源的，不容易啊！ 精神可以鼓励，但是态度值得怀疑。如果你现在刚编完代码或者要开始编码了，请把代码写好的同时把注释写好吧！如果一个刚入门的程序员能直接通过注释就能读懂你的程序代码，那么你写的注释已经非常成功了。

第三点：代码目录结构。

这与编码风格有关，也可以是编码风格的一部分，但单独取出时必须具有独特的含义。有没有想过或者遇到过代码目录结构，能够大致了解项目要做什么，有什么功能。看到这样的项目，是不是有种想进去看看的冲动？我参与了这样一个项目的编码。那个时候，我们是相当成功的。一开始，我们对编码风格有点不舒服。我们单独讨论了代码目录结构，是根据我们自己的技术架构制定的。做的好，开发者写的代码更清晰，效率也提高。就算是新人维护，只要多说几句就容易接受，一切都变得简单了。

第四点：命名。

这也可以属于相同的代码风格。坦白说，单独拿出来没有多大意义，因为在代码风格上会强调，但是你不觉得很容易忽略这么重要的东西，比如大小写，我是否写ID 或 ID 作为 ID？没有多少人会。小心，只有当出现问题，代码冗余量增加时，你才会发现命名也很重要。类文件也有一些不尽如人意的命名词。我要提醒您的是，既然它如此重要，请在命名您的代码时小心！

第五点：有利于必要的重建。

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

第六点：使用一些工具来改进代码。

这里简单列举了几种类型的工具，网上有很多资料，需要根据自己的语言来选择。

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

    第二类：代码统计工具

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

    第四类：代码覆盖工具

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

修改代码应该放在一个时间段内，而不是随意修改。当前流行的敏捷开发的一个现象是版本发布比较频繁，修改代码的风险很大。修改后的代码很可能是公开的。代码在很多地方被调用，很容易在其他地方引起问题，小问题解决了，大问题就来了。当您需要修改其他开发人员的代码时，您必须相互沟通，以避免不必要的误解和潜在问题。

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

这些是编码技巧。我自己的感觉是要不断地回顾自己的代码。有很多点值得你反思和关注。

平时有时间静下心来，多读点经典书籍。不明白或不记得都没关系，我会再读一遍。

4. 测试

作为开发人员，接触测试的第一件事就是编写单元测试用例，尽量覆盖每一个场景。这在软件质量中起着关键作用。为了避免与测试人员的重复沟通，增加不必要的成本，开发能做的就是写单元测试，发现一些潜在的问题，提前发现大部分的bug。从管理的角度来看，测试会容易得多。开发一个比较完美的软件，绝对是一个优秀程序员的追求。也是程序员路上的收获。