好的软件（软件工程）

越来越觉得工程师不仅仅是写代码实现需求这么简单，真正写代码的时间应该在30%～50%左右的时间。其余的需要进行需求分析、需求check、逻辑设计、代码设计、Design Review、Coding、单元测试、Code Review、代码测试用例自测、代码上线CI,CD、线上监控报警、日志处理、线上问题修复。这些流程每个都有它的价值和意义，这些不是加加班就可以做到的，需要不断的思考、验证，程序员这个行业是一个知识密集型的行业和工作，而不是一个劳动密集型的工作。很多公司可能做不到完整的流程，但是我们可以尽可能的向这方面靠拢，实践，在我们的日常工作中逐渐尝试和优化。

• 需求分析： 将产品经理的文档和psd文件进行理解，不理解的地方提出来确认一下，这一步需要多问一下问题？这个需求到底解决了什么问题？我们真的需要这样做么？有没有更好的方式和方法？ 问几个问题的目的是了解这个需求真正的价值点，以及了解产品经理想要的是什么，同时也可以知道他是不是拍着脑袋就提了这个需求，没有经过思考和调研。

• 需求check：和产品经理对一下我们理解的和他想要的是不是一致的，这一步是一个沟通确认的过程，防止我们理解的是A，而他想要的是B，最后不要快到上线时间才发现不是我们想要的效果，这个可以在之前需求check的时候就去做这方面的东西，防止后面出现延长上线时间或者其他不确定的问题。预防出现X、Y问题，真正的问题是X，我们却一直关注于Y上面。

• 逻辑设计：将需求的逻辑理解清楚，使用用例图、流程图或者时序图将流程画出来，这个过程也是梳理我们对项目理解的一个过程。

• 代码设计： 这个阶段我们可以将代码的组织结构、那些模块可以复用、那些地方可以使用设计模式，类名，函数名这些可以定义好，然后自顶向下的进行设计。

• Design Review： 我们设计好以后，可以将我们的设计让同事或者负责这个项目的leader看一下，这个过程主要是防止我们漏掉一些没有注意到的细节，然后这个过程和同事讨论或者聊的时候如果可以及时发现，可以提前解决，提前把问题暴露出来。也防止我们觉得很好了，但是遗漏了重要的问题，不要自嗨，自嗨有毒。

• Coding: 在上面这些做完以后，我们就开始我们的写代码的工作了，我们可以使用自顶向下的方式进行代码的编写，先写主方法，然后主方法里面写好你调用的子方法，这个时候不要去关注子方法中实现的细节，只关注于顶层的代码和设计，等这些做完以后，然后去思考这个流程有没有遗漏的地方，如果有的话进行补充，没有的话我们再去写我们子方法中的内容和逻辑。

• 单元测试： 这一块呢，还没有真正实践过，待完善。

• Code Review： 这一部分呢，可以让我们的同事或者上级看一下我们的代码，设计是否合理，然后哪里有可以进行继续完善的地方。不要害怕修改代码也不要害怕别人提出意见，别人提出意见如果你觉得ok，可以接受，如果有疑问可以提出来讨论，因为这个讨论的过程就是交流和学习的过程，一定不要害怕冲突，因为有冲突才有交流，才有成长的可能性，如果你一直沉浸在自己的世界里，觉得自己写的代码多么多么好，这样是不可能进步和成长的。

• 代码测试用例和自测： 这一部分也是非常重要的，因为在测试的过程中，我们可以更深入的理解我们的代码的实现过程和原理，为什么这样写？然后我怎么设计测试用例才是合理的，有没有遗漏的情况等等，这些都是值得我们思考和验证的，当然做好这一部分需要一部分时间，这一部分时间是不能省的，不然线上出了问题就不知道如何下手处理和解决了。以前自己会漏掉这部分，结果是血的教训，线上出问题了，然后本地调试，然后上线，然后继续本地调试…….，所以这一部分的时间是少不了的。

• 代码上线CI\CD: 待完善

• 线上监控报警：只要线上跑的程序都是可能出现问题的，所以我们需要做好线上软件的监控和测试，不能等出问题了，等用户来给我们反馈，这个时候就晚了，尽可能地做到出了问题我们是第一个知道的，然后去进行解决和处理。

• 日志处理：一定要有良好的日志处理，不然线上出了问题，调试和定位问题需要花很多时间，如果我们日志做的比较完善的话，根据我们的日志可以快速的定位到问题，然后去进行修复和解决。没有日志，真的是一件很难受的事情。。。。。。

• 线上问题修复：对待线上问题一定要有敬畏感，上线还是修复线上问题，一定要仔细、仔细、再仔细。再三确保我们的逻辑不会对线上问题造成二次伤害，然后才能上线。这一部分一定要有敬畏感，也是对自己负责和工作负责。