711总结

在最近的软件开发中发现几个比较影响工作效率和质量的问题，写下来做个总结。

1  缺乏沟通的软件开发

   在开发后台系统CMS的时候 ，课程管理中有一个关于权限管理的功能模块。当时李工提出这个需求后，我们进行了讨论，内容是权限的划分和权限的控制。哪些权限应该分配给产品主管，哪些权限应该分配给产品经理，哪些权限分配给产品编辑等等。在讨论中有一个问题是当课程发布或者上线的时候，主管可以对课程进行修改，然后我就在脑海里记下了：主管可以修改发布或者上线后的课程。 当时我的理解是权限由三部分组成：操作对象（课程）、角色（主管、经理、编辑等）、操作对象的状态（草稿、发布、审核上线、上线等）。 后来李工整理出来了一张权限表，里面清楚的划分出了每一个角色对应的权限。我拿到表之后，看了一会儿，然后就在脑海里面想出了实现思路，权限的控制放到权限层来进行，这个我比较清楚，而不是业务层来实现。 一般权限的判断都是由两部分组成 一个是操作对象，一个是角色或者用户。归纳起来就是 哪个角色可以操作什么。现在以我的理解变成了这样：哪个角色可以在什么状态下操作什么，貌似权限是由3部分组成的，当时隐约的感觉到这块怪怪的。在实现的过程中，果然出了问题，实现的结果是权限层里面出现了业务层的内容，根据我当时的理解权限层里面除了判断操作对象和角色，那么还要加上对课程的状态判断，这样才能准确的判断出这个用户是否有权限。结果就在权限层里面加入了课程状态的获取和判断等业务代码。所以就出现了权限层里面出现了业务代码。当时我总觉的这里有点代码入侵的感觉，由于当时时间紧迫（很大原因是自己思维定式了），我也没仔细想这个问题。再过了2天后，陈爽也要给精彩视频加权限，权限的控制类似课程，那么就要使用我写的这种模式。结果在加入的时候，我当时也想知道我的这种做法是否正确，所以就叫王工给把把关，我给他说了我的实现方式，他看了之后，第一反应就是：权限层里面加入了业务层的东西，不好。然后我就给他讲了课程管理中权限控制的细节和实现的思路。他听了之后说:”当课程需要修改时不应该在发布或者上线状态时修改，应该退回到草稿状态进行修改。然后再发布和上线，这样业务流程比较合理，对上线的课程进行修改你把它看做一个动作，但是这里是2个动作：1 修改课程状态为草稿状态；2 修改课程。这里应该进行拆分”。我也想了一下，发现这个流程比较合理，自己之前想的那个流程忽略了软件设计里面单一职责的规则了。后来对这块进行了重新设计和开发，结果花费了一些额外的时间，本来如果在前期的设计和讨论中如果进行深入沟通，
或者在实现完一小部分后找王工沟通下，那么就不需要这次的修改了，真的是又一次浪费了时间。
      在去年做软件的时候，我才对沟通重视起来，而且发现面对面的沟通真的是最有效的沟通方式（以前半信半疑）。沟通确实能让我们少走一些弯路，而且能开阔你的思维和思路，最主要的是能把问题说清楚，如果你仔细想想以前做过的事情，发现好多问题就是没沟通好才造成不必要的重复或者不必要的误会、错误。

2 功能实现之后缺乏不够仔细的测试

       在最近的开发中，发现开发完一个功能后只是进行了简单的测试 ，而没有进行全面、仔细的测试。没有对该功能的所有异常和正常情况进行测试，结果在测试环境上测试的时候频频出现简单的问题。而且有的问题在这个版本中修复好了，在下一个版本中可能又复现了。改动的时候没有全面的注意到影响的地方，改好之后测试用例想的少。
       所以我想在修改的时候，写下要进行测试的测试用例。比如修改重点地方时，哪些页面会涉及到这部分的修改，
那么就需要记下了这些页面的哪些地方需要重新测试。测试用例可以写简单一点，但是一定要全面。

3 思维定式的无奈

       在开发中不知不觉发现自己思维定式， 也不知道为什么就这么形成了，对一些功能的实现习惯用自己熟悉的方法实现，而没有更多的方法可以参考或者借鉴。实现某一个功能都是凭借当前的思维和经验来实现，或者会出现前几天实现了，感觉还行，也觉得非常合理。但是过了几天再次看这块儿就发现有问题，而且有时候会突然觉得当时是怎么想的，为什么会这么想，并发现当时的想法明显不对。这个可能是短期的思维定式。
在对功能的测试过程中 ，发现也形成了思维定式，在测试中测试的出发的局限在功能的实现和正确流程的测试，而没有更多的异常测试和用户体验方面的思考。也许这就是人们常说的：当局者迷，旁观者清。
       后来想想造成思维定式的原因可能是：缺乏沟通，缺乏那种对软件功能模块从设计到实现，测试，到最后使用的沟通；经验不够是不是也是一方面原因呢，也许是看技术方面的东西少了；每天精力不够可能对短期的思维定式有影响。
       对目前自己的思维定式只是发现阶段，没有具体的解决方法。

       上面这几个问题是自己在工作比较突出的问题，在这里写下来看看今后会不会有所改善，如果改善了说明确实总结了，如果未改善说明问题更严重
 ，最起码说明上一级出了问题，即总结本身就有问题。
       时间浪费不起，既来之，则安之。