代码改变世界

小型外包公司实习两月有余的一点感悟

2017-10-09 09:09  Fururur  阅读(10619)  评论(45编辑  收藏

读研一年,现在在导师下面的公司实习(一开始美其名曰项目紧帮帮忙,继而抽不了身……)。本科也没出去实习过,并不知道大公司里面具体的人员安排和分工,在现在的公司也有两个多月了,记下一些小小的感悟和吐槽。

目前公司的运行状况,总共十多个人,2个管理,2个UI,4个前端,3个后台。本人是写后台的。基本上接了很多的项目,每个配1个后台1个前端,UI共用。后台用的快速开发框架,app用的mui。

我们的leader在哪里

目前,公司的CTO名不副实,基本只负责任务的分发,而没有技术的统筹。这样带来的最大的问题,就是产品质量差,效率低。

在我来之前,公司开发人员是不使用任何项目管理软件的,由于公司没有强制使用公司台式机,因此代码几乎都是随身带着,一旦出现故障,所有代码都没了。目前在公司服务器搭了一个svn,但是由于网络的问题(经常断),使用的人数并不多,也就是国庆放假的时候才强制所有人同步一次代码。

后台又搭建了项目管理软件,但是依然没有做出严格的使用要求,所以员工的积极性并不高,很多时候还是通过口头交流来协商接口等,无疑降低了开发的效率。

还有一点想讲的就是开发的规范,之前在知乎看到一篇文章程序员你为什么这么累?,作者是华为的,里面有一个专栏就讲到了一系列的开发规范,例如接口的定义,日志的输出以及异常处理等。再和自己现在写的项目一对比,简直不忍直视。由于项目是后来接手的的,所以势必和前面的那个程序员在规范上有所不同,显得很乱。非常不利于项目的交接和维护。

技术上没有一个令人信服的leader,很多事情就缺乏执行力。

论培训的重要性

后台采用的是快速开发框架,属于那种权限管理+代码生成器这种形式的。在我看来,既然选择使用这类的框架,那么公司至少有一个人是对框架是非常熟悉的吧?框架本身的性能,功能,集成的一些框架等都会清楚。那么在,新的后台开发加入时是否应该进行简单的培训工作呢?显然公司是没有的,我是自己大致看了下项目的结构和文档,虽然能够很快的投入开发,可是对框架的特性并不了解啊,以致于不能将框架的功能最大化,物尽其用。一段时间开发下来,恐怕早已破坏了框架原有的设计。

公司缺少技术特别强的人。初来乍到,管事的人总会说,有问题,自己再半小时内解决不了的,直接去问。可是现在的情况是,我去问,结果人家帮我一起百度,或者只言片语打发了(订单并发下单问题怎么处理?队列和加锁啊)。可是,我来咨询你,有的时候并不代表我没有能力解决这个问题,而是我觉得你经验丰富,我需要1小时解决的问题你可以10分钟解决对不对?

读过人月神话么

需求不明确和没有开发文档,估计是很多公司的通病吧。我现在在做的项目还有一份丑陋的业务文档可以看看,我同学就完全没有文档了,需求全靠自己想+UI的设计稿。等到项目结尾才写数据字典和接口定义文档。且不说交接的不便,开发上那效率是真的低!同学总是在跟我诟病说,后台接口写的慢,还不断修改接口的字段,导致他痛不欲生(前端我同学用来vue,双向绑定的~)。不用说,这都是开始不写文档的锅。要知道,在需求不变的情况下,一开始协商好接口参数和返回值后,其实前后端完全是可以分来开发的。前端可以使用mock.js或者easy mock来模拟接口值,到时只要url一换就成事儿。

细节上,谈谈java项目分包的问题。
由于使用代码生成器,所有生成的代码都入左图所示,直接根据三层架构,将项目分成表现层、业务逻辑层等。这是一种默认的分包形式,把所有业务逻辑拆分到各个分层去。首先代码生成器是按照表来生成controller的,这里我就已经不太认可了,虽然说不同的表代表这不同的业务,但是毕竟controller应按职责来分的,因此是否需要在代码生成之后再根据业务来手动分controller呢?其次,在实际开发过程中,会遇到有些类,好像既不属于工具类,也不属于三层中的任意一层,不知道该放哪里。

那么我就推荐最近学到的第二种分包方式——根据业务来分包,如下图右边所示。每一个业务都包含了一个微型的三层,有自己的controller、model、services等。这种看起来业务条理就更清晰。

随便拉过来的测试人员合格吗?在公司,每次项目收尾,都会拉UI来进行测试,这点我也诟病不少次了。UI很多都不是科班的,也没有学过软件测试,对于他们来说,产品开发出来,大体上跟他们的UI设计一样,点击下正常就OK了,根本就不会考虑复杂的测试用例,边界条件,路径覆盖等等。总之,测试不能随便。

总结

我我觉得,既然在公司,我们开发的不再是一个课程设计,而是一个稳定可用的产品,该有的条条框框还是需要的,而不是由开发人员自己想到哪就写到哪了。

理想很丰满,实现很骨感。