浅谈代码质量与开发模式

Posted 2021-05-02 潮Ser部落

来中奥也有段日子了，在这段时间里，做了许多项目，也填了很多坑。自己也有一些心得，今天做个小总结。关于代码规范，项目质量，bug繁多，前后端分离，有一些个人的看法，那么今天浅谈一下。

 

就目前来看，我们项目上有很多的问题，页面风格有差异，代码质量差，bug繁多，我们一直在改一直在调试，可是却发现有改不完的bug。那么为什么会出现这种情况，按理来说，我们实行了996模式，工作时间增加了很多，进度应该会快很多啊？可是，并没有达到我们预期的效率。而这个根本原因，我认为是我们前期开发项目的时候，代码质量上就没有把好关，页面结构和组件上也没有统一，为了完成任务而完成任务，前后端人员没有实现最大的价值。据我了解，公司以前是没有前端的，或者是公司前端开发人员稀缺，几乎所有的页面，都是后端的兄弟们写的。术业有专攻，后端人员没有办法规范标准写前端的代码，等项目成型了，需要更新迭代的时候，就会出现很多难以调试的bug，和难以维护的现象，等我们前端来的时候，也只能见招拆招。

 

现在，我们有前端人员了，前端页面开发进度是很快的，但是，整合项目的时候，又出现了许多不该出现的问题。问题一个一个的说，比如，jsp页面结构的框架，目前我们大多数用的都是iframe框架，从长远的角度上来讲，我是非常不赞成用的，因为iframe的弊端有很多，网上一搜一大堆。比如，跨域问题，比如，父文档修改 iframe的子文档，或iframe的子文档修改 父文档中的内容。很容易就会使用到多个window对象，document 对象，还有很多……这里就不一一列举了。我的方案是采用div或其他自定义标签，通过load方法，便可以很好的取而代之。比如，有大量页面开发整合到项目中后，很有可能出现页面样式部分被覆盖掉，调整了这个页面的样式其他页面的样式又出现问题，这就是css高耦合度的问题，所以，我建议用less或scss, 简单的说明下，Less 是一门 CSS 预处理语言，它扩充了 CSS 语言，增加了诸如变量、混合（mixin）、函数等功能，让 CSS 更易维护、方便制作主题、扩充， 同时还有高度解耦的作用，并且学习成本不高，很容易就可以上手。再比如，前端做好的页面给到后端的时候，页面在项目整合后，部分出现了怪异的状态，js、css失效或冲突的问题。我们先分析下这个出现问题的原因，前端人员写的是静态的页面，后台人员在整合页面的过程中，很有可能忽略了某些标签，或者多粘贴某些标签，或者少引货多引了某些css和js。当然，这也不能让后端的兄弟们来被这个锅，因为这个工作本来应该是前端人员来做的，如果是前端人员来做这件事，我想我们开发的效率和页面质量会有明显的提升，页面bug数量也会减少很多，所以我们应该以前后端分离的模式来开发我们的项目。

 

说到前后端分离，大家应该已经早就是意识到了。孙云年前的时候开会就提过，说是在今年的时候会过度。但是，这个过度期，要从什么时候开始，要怎样的去做这件事，这可是是个很人头疼的问题。我希望早些变革我们的技术框架，和开发模式，并采取了相应的措施。对包头数据情报项目jsp打包的js做了分层处理，鄙弃iframe框架采用load方式加载，统一弹出框组件。但是在这过程中，与圆圆争辩了N多次，最终妥协于项目交付时间。项目已交付时间节点为准，这无可厚非。但是如果有些人心里不愿意主动去做这件事，或者抵触新的技术和方案，这给我们技术变革造成了的阻碍。我觉得应该有人去推动这件事情，说要过度，那么总得有个开始，从什么时候开始？我希望从现在就开始。其实，想一想，磨刀不误砍柴工，我们或许开始的时候进度会缓慢，但是等我们适应了，变革过来了，项目质量一定会有明显的提高，我们也不会出现大量的难以调试的bug。这样看来，是不是减少的很多的工作量，提高了我们的开发效率。

 

上面简述了View层面的组织架构，那么下面我们谈一谈Ctrl层面的。在业务逻辑复杂的系统里，我们最怕维护前后端混杂在一起的代码，因为没有约束，M-V-C每一层都可能出现别的层的代码，日积月累，完全没有维护性可言。所以我们要实现前后端分离。那么分离后相关人员又负责哪些层面呢?经过了一番调查和结合自己的经验做了个小总结，前端主要负责View和Controller层；后端只负责Model层，业务处理/数据。优秀的前端框架也有很多，如：AngularJS、reactJS、VueJS。下面我只谈我用过的AngularJS ，AngularJS 最近几年也是比较火的，我们可以通过他的指令把应用程序数据绑定到 html 视图上，也就是说前端人员可是通过调用接口，把获取的数据渲染到页面上，这在很大程度上提高了开发效率和页面质量，模块化管理我们可以用requirejs来整合，通过requirejs动态加载的方式来实现，从而真正意义上的实现前后端分离。当下，我们这方面的人才还是比较欠缺的，所以我提议前端人员现在就去了解学习一下AngularJS  和requirejs，为以后我们技术框架打下基础。但是，建议归建议，问题又来了，如果大家拿项目进度当幌子，说没时间没有办法啊，又该怎么办呢？难道我们赶项目就一定没有时间学习新的知识和技术吗？答案肯定不是。我觉得要有人去推动这件事，把它实际的贯彻起来。比如，定个具体的时间去学习和分享，带动探索新技术的气氛，多做日常技术交流，这样我们才能不断的提高技术，拓展视野，团队才会日益壮大起来，在开发项目中所向披靡。

 

       在我们开发的项目中，经常会有这种问题，前端人员根据UI给的设计图实现完页面，整合到项目中后，经常会有人说这个风格没统一，这里布局不行，那里样式不对，然后进行一系列的返工工作。在这里，我想问下，设计图出来的时候，项目负责人有没有对设计图认真进行审核过， 有没有思考过当前页面与项目主体风格是否统一。按理来说，这些工作都应该归UI设计来统筹，但是，我们有了这么一个审核机制，就不应该让它形同虚设。所以，我们应该去制定一个规范的流程，所有人各尽其职，把控好每一个环节。如果我们把这些流程规范化，规则都制定好，按照一个标准来执行的话，那么我们不会苦陷于频繁的返工操作，减少了工作量，进一步提高了工作效率。

团队的强大在于团队中个人的强大和团队的协作。就这个问题谈谈我个人的看法。目前，大多数人以前都是‘单打独斗’的工作方式，或许在小规模的的项目中可以撑起一片天，但是，在一定规模的项目中这种方式就显得有点乏力。可能有些人认为自己的水平可以，大多都不主动认可对方好的方案，甚至说以前项目就是这样子做的，或去绕一些弯路，去补这个坑，然后告诉你这样也做也可以。这在项目协作上就显得颇为的尴尬，明明很简单的就解决了的问题，偏偏要绕弯找一些方法来出来。技术上较真我认同，但是钻牛角尖就另当别论了。团队协作不是要一味地妥协和配合，而是要在客观上辩证的来看待方案的好与坏。好的方案都是碰撞出来的，所以我们讨论结果也要以一个最优，最好的方案为准。方式好的团队协做，会营造一个的积极向上的氛围，大家互相帮助，互励共勉，同时，也会反作用我们每个人的身上，使团对中的个人获得更好的成长，我们技术上的到提高，团队合作默契，从而形成一个良性的循环。

       

         透过现象看本质，实话实说。以上是个人的观点，但希望能引起共鸣，这次就先谈到这里，如果有不同观点的，愿意和大家一起交流探讨。 

——2017.03.21