ARTS - Share

编码坏习惯

工作中主要写业务实现代码，使用SpringMVC 框架，也阅读过很多同事的代码，下面总结几条不好的习惯：

1. 控制类里写业务逻辑而不是在服务类

我们springmvc 分层架构，一般就是Controller 处理业务请求， 注入Service, 具体的逻辑处理调用service, 然后返回给前台结构，但是不少同学违背这一原则， 把大量的业务逻辑写在控制类方法里，service 模块仅当做 dao 层来使用了，这样明显是有问题的，一个最大的问题就是可能导致无法进行事务管理， 因为一般习惯事务是在service 里进行控制。

2. 过多的if/else 嵌套

过多的if /else 嵌套会造成代码可读性很差，当因为请假临时需要别人管理你代码时候，会造成很大的困扰，笔者曾开玩笑引用某段子说，别人阅读你代码时骂脏话的频率和你代码质量成反比。机器语言是让机器可读性好的， 编程语言是让人类可读性好的，所以我们尽量写简洁易读的代码，尽量把大方法拆成几个小方法，对一类功能代码块提出来，做到代码简洁。

3. 格式化太少

对，尽管IDE 已经非常智能，但依然随时可见没有对齐的代码、无用的包引用，这些虽说不是大问题，但是依然影响程序的美观优雅，字如其人，码如其人，请多注意代码形象。

4. 随意发挥，不与其他人统一

虽然程序设计中需要个人发挥，但是也要遵从团队习惯，比如代码命名、组织方式，功能实现的惯用模式，前后端交互的接口设计等。 除非你能找出更简洁有效，且团队通过的方式，不要随意更改、调整团队惯用的实现方式和习惯。

5. 心态开放，乐于沟通，乐于改正不足之处

很多程序员的心态就是，我负责的模块别人不能改动，不然出来问题你来负责。 诚然这样造成了自己模块的方便维护， 但是对项目整体来说是有一些坏处的，我们开发中除了自己的模块，不可避免遇到公用模块， 或者自己的模块开放给别人重用，这或多或少都有需要调整的地方，如果一刀切不许动，那么很可能每个人都对同一个功能开发自己的实现，这回造成重复率增加，不利于维护。我们需要做的是开放沟通，就事论事探讨更好的实现，然后团队配合更好的完成项目。