开发心得

Posted 2020-10-10

## 软件开发小结
1. 对代码的任何改动，都需要和测试说一声。有些改动是现有的重构优化，有些是测试未发现的Bug修改，有些是测试发现的Bug修改，对于这些修改，提交到代码库后需要通知测试同事知晓(本次修改是界面上面的改变，还是操作业务上面的改变)，让他们在下一轮测试时，多加注意下。通知方式最好用邮件说明，注意留痕追溯
2.  自己负责的模块，不管是新写的，还是接手别人的，在着手修改之前，要画清楚类关系图，以及数据流向图，想清楚后再动手修改。
3. 在进行修改代码时，在本模块内发现有一些不再使用的代码，要标注下，准备删除。提交代码时，涉及到功能改进的修改，做一次提交，清理本模块内一些遗留代码或者不再使用的代码，再单独做一次提交，不要把功能修改和代码重构优化混在一起提交，那样，自己在写提交说明或者别人在审阅你的代码时，就不好区分功能完善和重构，尽量保持一次提交的代码改动范围的独立性和唯一目的性
4. 当一个文件中有涉及到多个功能点的改动时，按照上面的提交原则，可以手动把这个文件复制一份副本，把涉及到当前提交点的改动保留，其他改动恢复原样，待本次改动提交之后，再恢复内容，进行下一个问题点的提交 
5. 对于一些暂时还不使用的代码，可能以后会用的上的工具类代码，要果断删除，并且提交到SVN库。相信版本管理工具，等到以后需要时，说不定会写一个更好的。
6. 对于自己在现有工程中找到了其他模块的Bug或者是不合适的编程风格，不要擅自去修改，要通过QQ截图或者邮件的方式通知对应模块的负责人，由他们去决定是否修改。**自己不要擅自改动他人的代码或者一些基础类代码**，如果确实需要有改动，需要告知其他人员。把自己改动的影响控制在自己知晓的范围内，不要给自己平白无故的加戏，做好了，没人夸你，出了问题，就算不是因为自己的修改造成的，也算到你头上。 
## 软件工程小结 
1. 除非到了非常紧急的情况，否则，一定不能直接改动生产环境上面的代码，如果非要改动，把改动需要的地方，涉及到的影响以及不改动可能的后果，通过邮件抄送给相关人员
2. 越是快要到发布时间节点时，对代码的修改要越来越慎重，每次修改，自己都要考虑到此次修改的影响范围，如果影响范围太大，要和产品和开发讨论，根据问题的紧急程度决定是否来修改。
3. 来了一个复杂的需求时，其中涉及到各种状态流程的处理，先在Visio里面画一个大体的流程图，画好后，和产品、需求人员讲解一些这里面涉及到的众多处理流程，尝试着简化、合并一些处理流程，**对于一些较为复杂的操作，要学会适当的拒绝，产品人员不能一味着想着加功能，加状态**
4. 商业软件作为一个产品，为了协调稳定性和开发进度，在开发时至少需要两个分支，一个主线分支，一个发布分支。平时的开发都在主线分支上面，等到需要发布版本了，就从主线分支上拉出来一个发布分支，在此分支上面，尽量不增加新功能，而是修改已有功能的Bug，等修复的差不多了，在发布分支上面发布代码，将发布分支上的修改合并会主线分支，然后继续开发。
5. 提到开发人员这边的需求，对于一些异常情况，没有更加详细的说明，在正常使用下，有不同的处理逻辑，A操作可以，B操作也可以，这个时候，需要将此问题反馈给产品、测试人员，确认在这个场景下，怎么样的操作是测试认为可以接收的。**需求针对的是功能，测试针对的是用例，一个功能在不同场景下会有多个测试用例，需求在提出的时候，不可能考虑的如此全面，在后期开发时，要注意反馈，并且讨论一致的结果记录到JIRA上面的需求单中去，以备后续查验**
6. 在Debug版本下验证的修复好的问题，记得在Release版本下再次验证一把，有些问题在Debug版本下不会出现，而在Release版本下会出现，测试人员一般都是测试Release，而开发都是在Debug版本下开发。
## 软件开发好习惯
1. 每天早上，过一把SVN的提交记录，涉及到自己负责模块的代码的修改，大致过一片，对其他人提交的感兴趣的代码，也过一片，看看别人在修改时，是如何解决的
2. 提交开发日志时，将Bug管理系统上面的Bug编号整合到SVN的提交记录里面去
     大致的样式如下
    > 问题编号：
    > 
    > 问题原因：
    > 
    > 重现方式[可选]：
    > 
    > 修改方法：
    > 
    > 修改涉及到的测试点：
3. 作为开发人员，无论产品或者测试在QQ群里面讨论的改进方案多么的热烈，如果最后没有得出一个结论，以改进的需求单或者修改的建议单的形式给开发人员提要求，那么QQ群里面的所有讨论都和开发人员无关，我们也可以提建议，但最后怎么改，由产品人员来决定。
4. 来了一个问题，自己就要对这个问题负责到底，负责到底的意思是，在尝试过许多次，自己仍然无法解决的情况下，需要把目前能够收集到的信息以及自己验证过的尝试手段以及对应的结果分析梳理成文档，表明自己在这个问题上已经尽最大努力尝试去解决了，仍然处理不了，只能求助于其他同事或者上司请求帮助。
5.  自己在开发过程中发现的Bug，不要偷偷修改，然后提交。规范的做法是自己发现的Bug，在JIRA任务单上面给自己提一个单，修改好并填写好提交备注后，将此单转给测试人员,让测试人员知道如何重现以及验证此问题的修改
6. 任何Bug的出现都是有原因的，不管是必然出现的还是偶然出现的，深入跟下次，思考每一个过程可能出现的问题，通过画出系统流程图来帮助自己分析