读研一年，现在在导师下面的公司实习（一开始美其名曰项目紧帮帮忙，继而抽不了身……）。本科也没出去实习过，并不知道大公司里面具体的人员安排和分工，在现在的公司也有两个多月了，记下一些小小的感悟和吐槽。
目前公司的运行状况，总共十多个人，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了，根本就不会考虑复杂的测试用例，边界条件，路径覆盖等等。总之，测试不能随便。
总结
我我觉得，既然在公司，我们开发的不再是一个课程设计，而是一个稳定可用的产品，该有的条条框框还是需要的，而不是由开发人员自己想到哪就写到哪了。
理想很丰满，实现很骨感。
来源：https://www.cnblogs.com/Sinte-Beuve/p/7634748.html