109

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

 6 years ago
source link: http://www.cnblogs.com/Sinte-Beuve/p/7634748.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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

目前公司的运行状况,总共十多个人,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等。这种看起来业务条理就更清晰。

697102-20171007161859411-781779913.jpg

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

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

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


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK