在福报厂干外包，吐槽一下一些项目开发的乱象

[wangbenjun5]

众所周知，一般一个公司会有很多产品，一个产品背后的服务也不止一个，也就是说有一个产品背后对应着多个项目，在某福报厂，大大小小的项目数不胜数，基本上只要写个东西都要整一个单独的项目出来。

我有时候很好奇，为什么要搞那么多项目出来，但是仔细一想，整个新项目才有新 KPI 啊

这些大大小小的项目，有些可能只是几个接口，几个定时任务。。。所以也算不上很重要的，而且都是内部项目，并不是面向普通用户。所以也没有运维、测试等配套人员，只有你自己，基本上就是想咋搞就咋搞。

1.发布全靠手动。福报内部有一个叫作 aone 的容器化发布平台，但是配置繁杂，很多 p7 大佬也不会，或者懒的搞，直接就是打一个 rpm 包，然后 ssh 到生产服务器上面手动安装发布，写一个 shell 脚本保活就算完事。

2.看日志要到生产服务器上。话说但凡是一个项目少不了业务日志，出点问题的话总要看日志排查，但是呢，我所接触的项目很多都没有对接日志平台，类似 elk 这样的东西福报厂内部也有。但是很多 p7 大佬不知道是不会还是懒。有时候看个日志就 ssh 到服务器上面 tail 。但是外包狗是没有生产服务器权限的，所以你懂的。。。

3.数据库设计很烂。所谓的核心库，里面有几百张表，建表根本没有一个统一规范，或者是有规范但是没有人监督执行。有些表没有 id 主键，有些表是复合主键，表的时间字段有叫 time，有叫 utime，还有叫 gmt_created，还有叫 created_at，一个库里面这样的设计比比皆是。

更不要说什么数据库设计三范式了，我怀疑这些 p7 大佬们压根就不懂 mysql，其实也正常，因为他们大多数并不是主要搞 web 开发，对于他们来说，mysql 就是存个数据，也不用考虑性能问题。可是倒是苦了我们这些写 CRUD 的外包狗。

以上内容纯属虚构，如有雷同，纯属巧合！

[mengjue]

这个其实也就是你是外包的原因了，只愿意吐槽，没有想过为啥这么做，或者我要怎么做的才能更好？举个例子好了，你说的 ELK 系统为啥没有像外部那样搞的原因时 ELK 没发容纳这个平台级别的日志，所以他们搞了一套自己的，通过 hadoop 归集，然后放在一个统一的平台搜索。

[x940727]

@Torpedo 通盘考虑的人不是离职了就是升级了，想找一个能通盘接手的人的难度可是非常大的，尤其是在大厂内部 KPI 还逼得紧的情况下就更难了。

[matrix67]

@dejavuwind #40 特斯拉之前的员工有爆料过的 https://news.ycombinator.com/item?id=17835760

1. 我曾经在 SpaceX 的团队中工作，该团队开发了一款名为“WarpDrive”的软件。它是一个庞大的单体 ASP.NET 应用程序，大量使用 ASP.NET WebForms 完成，而当我在那里工作时，ASP.NET MVC 的缓慢前沿逐渐增长。该应用程序几乎负责运营工厂的所有工作：库存、供应链管理、成本分析等。Elon 是 Windows 的忠实粉丝，并努力推动使用 Microsoft 技术运营整个商店。值得庆幸的是，火箭通过高度定制的 Linux 安装飞行。

2. mode x 和 s 和后端之前通信是挂着 openvpn 的。

3. centos 6 上跑着 ruby on rails

4. 。。。。等等 不翻译了

[x940727]

@mengjue 内部人都不搞，指望外部人搞？服务器怎么申请？而且搞出来谁维护？外包没有责任去帮甲方变的更好，而且也基本上没资格查询线上的日志，你这种结果论的人是真的令人害怕。

[OMan]

人和代码，有一个能跑就行。

[mengjue]

@x940727 今天闲的慌，再回复你一次好了。我讲这个实例的意思是，每个决策都是有背景和 tradeoff 的，仔细研究这些决策背后的根本原因，有利于帮助自己成长，比如说日志这个事情，如果跟多 infrasture 那边的人交流下，就会明白原因了。阿里系虽然名声不堪，但是里面的技术牛人还是外边不能比的，更不要说跟一个外包比。

[wangbenjun5]

@mengjue 兄弟，你这话说的，我要是能搞早就搞了，主要是没权限。

[wipbssldo]

@mengjue 看完你写的，我也不太明白「发布全靠手动。看日志要到生产服务器上。」这些决策背后的根本原因，有哪些利于帮助自己成长

[dejavuwind]

@wangbenjun5 盲猜一下 @mengjue #46 这位怕是利益相关吧？在线答疑？

[dejavuwind]

看了半天才知道 infrasture 其实说的是 infrastructure 基础设施

[zjuster]

阿里的这些数据库设计结构，是现实，但是没人能解决，或者说没必要解决。实际上在这种数据结构下面还能稳健运作，是阿里的技术功底。

这么多年技术迭代、业务变更下来，在人员变动较频繁的情况下，数据库设计规范是不可能实现的，你看到的一个数据表可能是三四个人接手过的，或者有十年历史的。

aone 本身是很强大的工具，上手太难，业绩重要的情况下，很少有人会好好用。

[zjuster]

很多问题 一些毕业生会问你怎么不按照书上写的做呀？

现实就是书里、实验室里的工程项目，和业务线上运作的底层逻辑是不同的，首要目标也不同。

好的代码规范当然有用，有一个这样注重技术规范的领导，对整体部门稳定性有大好处，但这样的领导很快就会有精力牵扯项目。技术高 p，要推广技术，要考虑饭碗抢业务，给手下弟兄争利益，这样的背景下，规范优先级着实不高。

[jakezh]

据掉福报厂 P8 offer 的飘过
早就听朋友说了，不知道 infra 组整天加班在加些什么

[eric96]

@wangyzj 我司挖的别的公司技术总监过来带小团队，也是不懂 git

[Torpedo]

@x940727 互联网第一定律 0 到 1 升职。1 到 2 离职

通盘考虑，显然是 1 到 1，肯定没啥人搞的

[Joker123456789]

都是赶着发布的，使用者也不关心底层，反正又不是他们维护。 他们只想快点用起来。

这是世界通病，作为一个新时代的农民工 没办法的。

[onionKnight888]

就好奇问问，p7 升 p8 难吗

[js8510]

有时候就是没必要啊。等各位工资更高了，不这么卷了，人力成本上去了，自然自动化程度，工程质量就要被迫提上去。p7, p8 也不过是和您一样的打工仔。代码人人都会写，不是你写的多，写得好就能升职加薪的。到了这一步，你要给上头拿出来可以量化的成绩。
如果各位工资再高一点，并且不加班，招不到这么多小弟人海战术。业务需求还是那么多，那肯定有一帮 ledership 站出来我们要 better engineering 。

[js8510]

@OMan 精辟了。就是这个道理，人能跑又便宜，就不用优化代码。

[yl666]

@wangyzj #35 真的见过