为什么有些大公司技术弱爆了?

本文整理自知乎上的同名讨论帖:《为什么有些大公司技术弱爆了?》,有网友提问:

今年年初,到一家互联网公司实习,该公司是国内行业龙头。
不过技术和管理方面,却弱爆了。

那里的程序员,每天都在看邮件,查问题工单。
这些问题,多半是他们设计不当,造成的。
代码写的一团糟,全是复制粘贴,连作者都没改,大家普遍不写注释,也不格式化,代码歪歪扭扭。

一个项目里,httpclient竟然出现了四种。
一种是该公司研发部写的,
一种是老版本的开源项目,
一种是新版本的开源项目,
还有一种是开发人员造的轮子。

打接口请求响应日志,竟然不知道用拦截器。
打错误日志竟然不打上下文信息,每个人一种日志风格,千奇百怪。
许多重要的中间流程,居然不打日志。

idea、eclipse、myeclipse的配置文件竟然全部传到项目里去了。
该公司混了两年的程序员,跟快递公司做查询接口,竟然不知道加密运单号。
所有服务间通讯,都没有设requestId,导致跟踪会话很困难。

一个没什么qps的边缘接口,居然做消费者生产者+阻塞队列的异步模式。
显得你技术少是不是。
不知道异步会增加维护成本,提高测试难度吗?
而且,任务队里没有考虑持久化,赶上发布,丢了好多任务。

读取一个小小的xml和exc配置文件,居然用流式解析,没见过这么二逼的,真是醉了。
做优化全靠拍脑门拍大腿,难道不会用excel分析日志,用jprofile扫项目?
一个100以内的常数集合遍历,他也要写个优化算法进去,算法跟业务还搅在一起,一团乱麻。
每个人都在嚷嚷性能、算法、分布式计算……

几乎没有文档,全靠从代码反推逻辑。
有枚举他不用,非要在每个页面上,把枚举值挨个儿写死,知道后面改代码多么费劲吗?

欺骗性的变量名,里面存储的是AES加密的,变量名后缀却写成了DES;里面存的是小写字母,却写成upperStr。
一个方法十几个参数,有三分之一是极其简略的缩写,注释肯定也没有的。
一个类写到三四千行是常事。

开发自测,居然要把代码全丢到公共机器上,而且都是走svn,他们把svn当ftp用。
svn里面大量的无意义提交,一多半的提交连都编译不过去。
我看到有个应届生,改了两句话,马上提交,说是怕代码丢失。

一个运行了两年的项目,spring的包扫描明显配错了,有些bean根本扫不进来,居然没有人发现。
一半的bean在spring管理下,另一半的bean他们自己写单例模式来实例化。

他们用mysql来做审计系统,出报表,有个报表要跑8分钟。
原来是有人用字符串来存多值(逗号分隔),sql里写了like,导致没有利用到索引。
为什么不用pg,pg在sql编程方面,功能更丰富,更适合做统计,它本身就支持数组。

程序员们都是得过且过的态度,怎么把代码灌进去,跑的通测试,就算交差了。

为什么大型互联网公司,技术和管理这么差劲,是怎么形成的?
(这家公司是卖机票的,没有明确说出公司名字,是怕给自己惹麻烦)


(小编转载配图)

下面是萧井陌的回答,伯乐在线已征得转载许可。

楼主你好,我试着给你解释一下,希望你能满意。

新手经常会有这样的想法——「这代码怎么这么烂?写的人干什么吃的?怎么能这样?为什么不按照书上说的做?」,这很正常,大家都年轻过,经历过这种阶段,我懂你心里的想法,所以也愿意详细地向你解释,这一切发生的原因是什么。

你说

不过技术和管理方面,却弱爆了。
那里的程序员,每天都在看邮件,查问题工单。
这些问题,多半是他们设计不当,造成的。

你真的觉得『国内行业老大的互联网公司』会是技术和管理弱爆了的样子吗?

你以为团队应该像永动机,但现实永远有各种摩擦、辐射、损耗。

内燃机的能量转化率,通常只有 30% – 50%,但是它却是驱动全世界运转的核心引擎,顺丰京东的快递小车、联通全国的高铁动车绿皮、瞬时直达的飞机……

机器尚不能 100% 效率运转,何况是人呢?

你说我们的程序员每天都在查看邮件、问题工单,你说这些问题多半是我们设计不当造成的,请问你有试过统计数据吗?你大概只是『感觉』如此吧?

事实上,经过十几年的发展,我们内部的『效率改进团队』已经非常高效成熟,每月、每周、甚至每天都会有新的改进,现在的业务处理方式,不说全世界,我可以自豪地说在全国我们是领先的,甚至是遥遥领先,不然凭啥坐到了全国龙头老大的位置呢?

所以啊,你只看到了程序员花在业务上的时间,没看到我们内部的『效率改进团队』为程序员们省掉的时间,我觉得我有必要站出来为默默付出的『效率改进团队』说几句。

当然,楼主作为实习生,不知道这些事情进而产生了这些疑问,也暴露了我们的不足。我已经在『团队建设委员会』里提出了这个问题,大家一致通过了决议,以后我们会对新员工——包括实习生加强企业文化、历史培训,确保我们的新伙伴们不仅知道要去哪儿,也要清楚我们从哪里来,长路漫漫,我们一同前行。

你觉得

代码写的一团糟,全是复制粘贴,连作者都没改,大家普遍不写注释,也不格式化,代码歪歪扭扭。

当初公司起步的时候,整个项目都是几个初创程序员加班加点熬出来的,我知道你看过《代码大全》、《程序员修炼之道》、《Unix 编程艺术》,你对上面的准则信手拈来,你可否翻开床头柜上的这几本书,看看它们的出版时间呢?

是的,公司起步的时候,这几本书根本还没有出版,彼时中国互联网方兴未艾,大家都是摸着石头过河。现在你遇到问题,你可以问朋友、问导师、用谷歌、用栈溢出、用知乎,我们写程序那个年代,看的是谭浩强、严蔚敏,用的是 52k 拨号上网,语言只有 C,编辑器是没有语法高亮和实时编译的,编译器是没有智能准确的报错的,没有现在这么多知识、也没有这么多规范和好资源、好工具。不过我们还是把项目做出来了,把公司一步步推到了现在的位置。

不过这个问题是客观存在的问题,谁也不否认,但是你知道为什么你被分配到了一个『代码看上去一团糟也不够规范』的项目吗?我们需要新鲜血液来重构一些老代码,所以你会被分配到艰苦的岗位上。我们希望你是勇于战斗的战士,我们更希望你能成长为经验丰富的老兵,而把你放到这种岗位,是对你来说成长最快的方式。

你认为

一个项目里,httpclient竟然出现了四种。
一种是该公司研发部写的,
一种是老版本的开源项目,
一种是新版本的开源项目,
还有一种是开发人员造的轮子。

你不知道的是,我们最初用了开源软件(也就是你所说的『老版本』),它构成了我们早期项目的基石,随着业务复杂性增加,我们改进并最终切换到新版本。

这个软件跑老业务非常成熟,但是在一些新业务上有不可调和的矛盾,所以在痛苦的适配后,研发部的同事们自告奋勇用 20% 的时间写了新业务的组件——是的你没看错我们也有 20% 时间,我们鼓励工程师的创新。

至于你说的开发人员造的轮子——这说起来可真有趣,它其实是前年来的一个清华大学实习生写的。

当时他来了之后,针对他接手业务的需求,向我抱怨说现有的 3 种都不好,要写一个新的来『统一天下』,这话是他的原话,我记得非常清楚,因为以我多年经验来看这样的做法是不可取的,但是本着锻炼年轻人的心态(加上他的确是不可多得的天才),我同意了他的请求,于是我用自己的业余时间接管了他的大部分工作,全力支持他写一个新的组件,帮他挡住了所有上面的压力,后来的故事就是你看到的这样。

是的,他后来越深入、就越来越感到业务的复杂,不断推翻重构、拆东墙补西墙,但始终发现和自己想的根本完全不一样,受不了了就走了,留下来这个。

我们明年的规划中,就包括剔除这个组件的 codebase,因为它实在是太糟糕了。

你又说

打接口请求响应日志,竟然不知道用拦截器。
打错误日志竟然不打上下文信息,每个人一种日志风格,千奇百怪。
许多重要的中间流程,居然不打日志。
idea、eclipse、myeclipse的配置文件竟然全部传到项目里去了。
该公司混了两年的程序员,跟快递公司做查询接口,竟然不知道加密运单号。
所有服务间通讯,都没有设requestId,导致跟踪会话很困难。

拦截器并不如你所想的那班美好,也许你在自己的电脑上写过一些玩具代码,觉得这样很方便、酷炫,但是真正到了战场,你会发现没什么才是必须的、好的,只有适合的才是对的。

至于配置文件,这么说吧,IDE 的配置文件传到代码仓库是我定下的规矩,『怎么会有人定这样的规矩?』,是的你可能从软件工程的教科书上或者某些『知名博客』上读到了不能这样做,但实际上这样做在很多情况下是必须的。

原因何在?

这样可以确保代码克隆即可用,而不是让每个人都去设置一大堆无聊的东西,这样不仅节省时间,也确保了每个人的环境一致性,你想想这几年火热的 docker,应该明白了这样做的正确性和必要性了吧?

你可能会说即便如此、插件也不用上传到服务器保存,我告诉你这样是不行的,你要考虑到我们这个项目前后十余年,你觉得几个插件能坚挺十余年?很可能我们早期用的软件,现在你已经完全不可能找到了,所以保存一份备份是非常有必要的,决不能错误地认为是冗余。

教科书只会教你基本通用的原则,树立你基本正确的观念,但是如果只是死守教条,如何能拥抱日益复杂的变化呢?

你看的教科书,且不说时间上已经是二十多年前的了,在适用性上,也不说就是真理,IT 行业发展日新月异,几个月就是沧海桑田,为了适应这样的变化,认真地思考、总结、判断才是最重要的。

你觉得

一个没什么qps的边缘接口,居然做消费者生产者+阻塞队列的异步模式。
显得你技术少是不是。
不知道异步会增加维护成本,提高测试难度吗?
而且,任务队里没有考虑持久化,赶上发布,丢了好多任务。
读取一个小小的xml和exc配置文件,居然用流式解析,没见过这么二逼的,真是醉了。

你大概不知道,当初跑在你口中的「一个没什么qps的边缘接口」上面的业务带来了公司曾经 90% 的收入,所以我们用了复杂的设计以应对当时的需求,当然现在业务转变,老系统不再需要处理那么多业务了,但是更没有理由为一个『works perfectly well』并且不再重要的业务重构代码吧?

所以,不是我们秀技术,而是业务需求 + 业务变更使然,年轻人还需要多学习一个。

你抱怨

做优化全靠拍脑门拍大腿,难道不会用excel分析日志,用jprofile扫项目?
一个100以内的常数集合遍历,他也要写个优化算法进去,算法跟业务还搅在一起,一团乱麻。
每个人都在嚷嚷性能、算法、分布式计算……
几乎没有文档,全靠从代码反推逻辑。
有枚举他不用,非要在每个页面上,把枚举值挨个儿写死,知道后面改代码多么费劲吗?
欺骗性的变量名,里面存储的是AES加密的,变量名后缀却写成了DES;里面存的是小写字母,却写成upperStr。
一个方法十几个参数,有三分之一是极其简略的缩写,注释肯定也没有的。
一个类写到三四千行是常事。

我再强调一次——我们是全中国同类公司中技术能力第一的,你所说的问题,当然是不存在的。

我们有专门的 Hadoop 集群来分析日志,当然也就用不着 Excel 了。

对于我们这种体量的公司来说,不存在什么『常数集合』,代码必须用合适的数据结构——这是常识吧?

特殊的算法和业务掺杂以增加内聚性,这是我们多年的经验,的确,它和教科书上说的不一样,但是我前面说了,死守教条是不行的——想必你一定知道 OSI 7 层网络模型吧?

公司的技术氛围浓厚,是和公司的基因分不开的,我们公司最重要的原则就是——『拥抱变化』,从十几年前的机房托管单机到现在的庞大自建集群,技术跃迁了何止千万里,所以每个人都在学习新知识、每个人都沉浸在新知识的喜悦中。

你的问题,大多都是因为没有考虑到公司的庞大体量和十几年的技术跃迁才有的疑问,这点不再赘述,自行体会吧。

你想的是

开发自测,居然要把代码全丢到公共机器上,而且都是走svn,他们把svn当ftp用。
svn里面大量的无意义提交,一多半的提交连都编译不过去。
我看到有个应届生,改了两句话,马上提交,说是怕代码丢失。
一个运行了两年的项目,spring的包扫描明显配错了,有些bean根本扫不进来,居然没有人发现。
一半的bean在spring管理下,另一半的bean他们自己写单例模式来实例化。

其实那不是 SVN,那是我们公司自主研发的适应我们内部需求的 源代码管理系统 和 文件管理系统,你可以往里面放任何东西。

你所说的「无意义提交、一多半的提交连都编译不过去」其实只是表象,这套系统代号 TITAN,它自带 CIDD(持续继承、交付、部署),所以这些无法编译的提交都是不会有机会走到下一步流程的的。

如果你工作了一年,你就会发现这个需求是很重要的,改动、尤其是大型改动,中间会有很多非可用但有需要存档的步骤,现有的源代码管理系统都不能很好地支持这些需求,因此你也被教育了一套适应落后工具的思想。人啊,最重要的能力是改进工具,所以用 TITAN 的时候要拥抱全新思维,不要被落后思维捆绑。

如果你工作了几年,你可能还会问为什么我们没用 Jenkins、Travis 等工具,其实呀,就在 TITAN 之中呀,它凝结了公司最优秀的人才的十几年宝贵经验和心血。

By the way,我们最近正计划开源它,为中国开源社区做贡献,也希望提高业界的综合素质。欢迎你提交 PR 哦。

你最后说

他们用mysql来做审计系统,出报表,有个报表要跑8分钟。
原来是有人用字符串来存多值(逗号分隔),sql里写了like,导致没有利用到索引。
为什么不用pg,pg在sql编程方面,功能更丰富,更适合做统计,它本身就支持数组。
程序员们都是得过且过的态度,怎么把代码灌进去,跑的通测试,就算交差了。
为什么大型互联网公司,技术和管理这么差劲,是怎么形成的?

为什么不用 pg?如果你抱着这种想法,那用了 pg 也要被喷的,到时候就就会说 —— 「为什么不用 sqlite,轻量简单,搞这么复杂真的有必要吗?」,真的有必要。。。

这只是一个很简单的系统,做的事情也很简单,当初做这个系统的同事更熟悉 MySQL,当然 MySQL 是不二之选了,对于简单的东西,追求的是开发速度、使用便利性。

你觉得一个月跑一次的审计代码,8 分钟有什么问题吗?就算是一周跑一次,当然也是没问题的。

程序员的单位时间是如此宝贵,为了优化一段一个月跑一次的 8 分钟代码,值得花费数天的时间来做这件事吗?

重复一遍,你的问题,大多都是因为『没有考虑到公司的庞大体量和十几年的技术跃迁才有的疑问』,这点不再赘述,还请自行体会。

当然,年轻人乐于思考,这是好事,是希望,新鲜血液替换老旧部件系统才能健康发展成长,人如此、公司如此、国家也是如此。

希望你勤于思考,努力学习,有问题的话,我们公司是鼓励同事们向 CEO、CTO 写信的,不然也不会有 CEO、CTO 信箱了你说对吗?

当然,这样的技术性问题、你写给我就好,CEO 是船长,不需要关心底层锅炉房的细节。

另外我想补充一下我的想法,希望对你有所帮助。

 

你看你都没说加班问题,我们公司没加班啊,这多好,怎么做到激烈竞争下还能不加班的?都亏了公司老领导和元老们的一手决策

所以我想补充的不是技术问题,技术问题都不是问题,年轻人可以学习、交流,技术都会很快成长,毕竟年轻人的冲劲大、头脑灵活。

我想说的是整体观、大局观、大棋战略。

 

黄金的导电性最好,为什么电脑主板还要用铜?

清华大学最好,为什么有人要去普通学校?

飞机最快,为什么还有人坐火车?

因为资源都是有限的,我们在现实生活中——而不是教科书上——必须兼顾成本和产出的平衡。

 

你问我每行代码都多人多层人工 review 好不好?问我支不支持?我说好,review 我怎么能不支持呢?我今天在知乎这个公众平台我明确说了我支持。

但是你也应该多学习一个,这个现实毕竟是现实,我们要兼顾各种考量。

你今天在这里渲染「大公司技术和管理这么差劲」,是不对的、是失实的、是欠妥的、是缺乏认真思考的、是未加深入考量的。

将来舆论出了偏差,你虽然不用负责任,但是你认识到自己的错误的时候,会后悔、会内疚、会难过的吧?

何处乌托邦?或许……等下一代?

总结就是,生产效率才是最重要的,世间万物最重要的是平衡。

怎样取舍、如何妥协,这不仅是大自然的规律,也是我们前进、发展的准绳和仰仗的原则。

 

下面是陈萌萌的回答

(2015-12-22 16:00 补充更新,伯乐在线已征得转载许可。)

题主你看到了很多槽点,但我认为你不能只看到槽点和大概怎么解决。有没有想过怎么改进,如果是你的话你怎么做,这些项目里面临的主要挑战是什么,次要的挑战又是什么?

不要只告诉我技术A弱爆了,用B就可以完爆这个项目了。你知道用B的优劣,B的适用场景以及适用B的成本吗?对于一间公司来说,成本是很重要的。我这里说的成本不是金钱。而是,假如你看不爽一份代码,你打算重构它,你觉得你需要投入多少时间,多少人力?重构之后,又要花费多少时间和人力去升级依赖这份代码的其他项目?不要以为开会无用,老板就只是在天天发邮件。如果你重构了一份代码,不能通过沟通说服其他组去升级他们的组件,又或者你只是重构了一份虽然很丑陋,但其实并没有多少程序依赖它的代码,又又或者你重构了代码只是让代码技术含量更高了,更好看了,却没给公司带来多少收入甚至KPI,那你的工作和成果就很尴尬了。

其实上述也解释了为什么你身边的同事都眼睁睁地看着这些丑陋的shit存在而无动于衷。因为他们也是需要投入成本的。先不论他们个人技术水平高低,试问谁愿意挑一个又艰难,又不能产生多少效益的任务去做?当然,你会说,写好代码是程序员的节操。抱歉,节操多少钱一斤,北京三环商品房多少钱一平?

编程高手都有真爱,但现实就是编程高手凤毛麟角。我们身边的大部分同事可能只是希望养家糊口,他们头上还挂着十几个bug等着修。我们数落他们没追求,但追求从来都不是嘴上说说,吐吐槽就能实现的。

人心如此,公司也如是。

矛盾分主次,公司的目标都是一样的:用最少的成本投入到最能产生效益的项目中去,或者投入大成本去解决公司最需要解决的问题,这间公司才能继续运作。

所以题主你想想,在你吐槽的个案中,有多少是公司真正关心的?有哪些是你的老板认为可以创造最大效益的?有哪些才是主要矛盾或者挑战需要最牛逼的人挺身而出第一时间解决?去辨别,解决这些关键的问题吧,骚年。必要时带上(忽悠)一队人马(同事)跟你一起干,苟富贵,勿相忘。不要像祥林嫂一样,天天抱怨着生活,日日思考着辞职。得罪点说一句:“沦落”到要跟这样的人共事工作,难道自己身上就没有原因?

这个世界有更好的公司,有更牛逼的人。如果你认为解决这间公司的这堆问题不值得,又或者同事实在太不给力,就远走高飞吧。

我以前也跟题主一样,看我第一份正式工作的很多技术环节都相当不爽。这份代码写得丑,那个设计像大学生作品,重要的项目居然连单元测试都没有……但是我后来反观我自己,并没有发现比起那些丑陋代码和糟糕实现强悍多少。我跟我的同事没有质的区别。我笑话他们代码混乱bug不尽,我何尝不是少处理了一个field,倒腾错了一个片段的数据搞到要翻工重跑?在我心底里艹了隔壁组那个“我的程序好像不能跑,你帮我debug下”的同事一千次之后,带我做ML让我倒腾数据并且被我的程序搞坏了几份数据(当然后来搞好了)的T9君在会议上说:“她已经很努力了,我承认我有时候也逼得她太紧,她应该有多些时间的。”

我不是长者,不能share多少人生经验,就留下最后一句话跟诸君共勉(好像有点怪)吧:
我观别人大傻逼,料别人观我亦如是!

 

下面是李运华的回复

(小编刚才在本文评论区看到@李运华留言:「我想如果转载我的回答,这篇文章会更加完整和有趣 :)」。于是小编就补上了。更新时间:2015-12-23 17:25:17 )

不是技术问题,是文化问题,说为了赚钱就不能把代码写好、就一定要设计一个烂系统的人,你们真的是程序员么?

我观察了一下身边导致此类现象的原因:

1)3个臭皮匠
有这样的产品人员,想到一个点子就觉得自己是天才,功能一上就能改变世界,晚3天上线就失去了成为下一个马云或者马化腾的机会。无论什么需求,研发说要十五上线,产品认为一定要初一上线,初一不上线世界就毁灭了,还动不动拿业务来压研发,遇到这样的产品人员,如果再配上一个听话的项目经理和一个任务分配器的研发leader,计划就这样定了!
怎么完成? 不管,我只要初一上线;
质量如何? 不管,我只要初一上线;
设计要扩展么? 不管,我只要初一上线,设计优秀能带来用户? 能增加收入? 能提高KPI ? 都不能你要设计做得好有屌用啊?
代码要优美么?不管,我只要初一上线,代码优美管我鸟事,我是产品我也看不懂!

2)做事不如无事,求变不如求稳
系统很烂,代码很差,但不关我事,都是历史原因,我改也改不动,改好了业务上也看不到,改出问题了还要被批,何苦呢? 不改,有问题还可以找个背锅的,反正别人也不会去看代码。

新需求来了怎么办? 很简单,if – else上吧,老的一行不动,新的我来重写,多简单,后面的人看不看得懂? 不关我事,我到时候在不在还不一定呢

3)编程就是敲键盘
你们技术部门又不创收,又不节流,工资还要那么高,随便招几个人做完就行了,不就是敲代码么? 我做产品的还写过两年代码呢,不就是if -else / 类 / 函数这些么!找个月薪15K的干嘛,10K也能做啊,10K的能做,8K的也能完成啊,或者一个15K的,我招两个8K的,多好,你们不是总是嚷嚷没人吧,我给你人还不行嘛? 你看你们要3个,我都给你6个了,你还说啥啊

归根结底:就是一个公司对技术的价值没有认识,只能看到业务的价值

技术的价值体现:一个是质量、一个是效率,但偏偏这两个东东都不像业务那么有明显的指标衡量,也偏偏不像业务那样立竿见影,技术的价值需要投入、需要时间积累,投入是很容易看出来,而价值不容易看出来,也不容易很快看出来,所以,就悲剧了……

========================2015.12.11补充=====================
通俗的讲,技术就像一个人的身体,你不锻炼当然不会立刻就死,你把锻炼的时间用来做个兼职,还能赚点外快;但身体素质不行的话,就今天来个感冒,明天来个头疼,后天咳嗽,综合下来,你去医院的时间和花费的金钱,除了抵掉你赚的外快,还会让你倒贴更多;反过来说,你开始锻炼了,老板也不会给你加工资,客户也不会立刻就给你订单,但我相信没有几个人会因此认为锻炼没用,锻炼是浪费时间吧?

然并卵,就像大家都知道锻炼的好处,还是没有几个人会坚持锻炼一样,人类总是会在长远利益和短期利益之间选择后者!

18 30 收藏 51 评论

相关文章

可能感兴趣的话题



直接登录
最新评论
  • 悟空 java服务器开发 2015/12/21

    需求导向,这个毕业之前软件工程的老师就跟我们讲过,但是要真正理解,不是一味追求技术,还是要自己多走几遍弯路后,学到了,才能理解。

  • 我呀 看书吃饭等下班 2015/12/22

    piapiapia的打脸哦。

  • 黯然_ 无业游民 2015/12/22

    太年轻了,被反驳的无话可说了。

  • 奔跑的ksun 软件工程师 2015/12/22

    嗯,和我之前看公司代码一个想法,然后因为工作实在太忙,活都干不完就别想优化什么的了。代码当然是美美的最好,但代价很大啊,我如果能想到,我的老大不可能想不到

  • 无为战士 游戏研发程序猿 2015/12/22

    你现在写的牛逼代码在后人看来都是渣。。。

  • Too Young Too Simple

  • 不愿熄灭的火焰 业余pythoner 2015/12/22

    我竟无言以对

  • leaf   2015/12/22

    这是在喷一些照本宣科的人的么 不过喷得挺好

  • pqiao 程序猿 2015/12/22

    你们真的都认为,事实有后者说的那么好?

    为啥我感觉就是内部撕逼,有很多解释都是避重就轻?

  • 高端人士说话确实让人无言以对!

  • 何昇邦 无业游民 2015/12/22 精华评论

    我在公司实习过,做产品的,有一些感触,写下来就当随个笔吧。

    公司的技术不算弱,在同行业内绝对算是技术领头羊,当然了如果和BAT相比的话那肯定是有点弱的。公司的研发同事到公司的时候都不是多么牛逼的人,都是进公司后经过针对性系统培训再上岗的,所以公司的技术肯定呈现出一种一派流的感觉,用同一种技术,用同一种编码逻辑去做许多事,这些事虽然有所不同,但是还是可以做。作为一家技术人员占大多数的公司,公司最底层的底层的同事缺乏一种创新探索的精神,这多少会让人感觉有点外包公司的感觉(虽然并不是)。技术细节上面我接触不多,但是大概的,公司用的邮件系统和SVN都是研发的同事用开源项目订制修改过的,不存在所谓的源码泄露的情况,何况公司有一整套的权限管理机制,没有权限的人根本不可能接触到那些东西。

    作为一家正式+实习员工将近八百人的公司,公司管理也不算混乱,顶多是大公司特有的臃肿感,公司的邮件系统和内部电话对工作效率有很高的提升,如果特别紧急去工位上面找同事更快,除非你懒到不想动。公司听说上新三板了,说明发展不错,里面的一些不太好的地方肯定要随着时间的推移去改变,公司的CEO是一个很有智慧的人(虽然见得不多),相信能有一整套改变的机制会出来(我临走之前公司的架构就在进行调整了,不知近况如何)。作为一家日流水几个亿的公司,处在这种特殊的行业,一切肯定以业务为最优先,有时候想象很美好,但是现实还得向利益低头,毕竟公司不是慈善机构。我在公司学得最多的一点就是,别拿想象和现实比较,现实就是现实,做产品做技术,都得已实际需求为准,别异想天开,能完美契合业务方的需求才是最关键的。外部系统要好看好用,内部系统好用就行了,没必要做那么好看,公司有更多的资源需要集中到给客户最有体验的地方。

    当然了,公司的数据处理方面效率确实偏低,我接触过,CEO要求五分钟出一次的数据,到数据库那边就变成半个小时,呈现到业务方那边就要四十五分钟,这种延迟很难给业务方任何业务上面的帮助。其他的倒是没什么了,同样作为实习生,我劝题主进公司后多和导师或者老员工交流,别把自己架子端太高,毕竟寒冬将至,大家伙得抱紧才能取暖。by the way,我进公司前后一个月,感觉很好,是因为个人原因离开的。

  • 住在可乐瓶里   2015/12/22

    在不考虑实际业务的情况下,所有组件,技术都可以被应用到任何代码中,一旦加上复杂业务后,最有效的办法未必来源于最好的技术。学院派和实战派的区别也就在这了。

  • xlovis   2015/12/22

    问题轻重真假在这或许是个罗生门。
    但起码,年轻人的陈述里没看到解决问题的积极性在。说句像放屁的大话,这种情形就只有 IT 有吗?
    我觉得事情永远是这样,你觉得能帮忙做到,就做;不能,就随流或者换件事情或者地方。
    电影里死于话多的,经常是反派就是了。

  • 确实如此,刚毕业就职的时候也是如此感觉,旧代码太烂,管理流程太烂。但是工作一段时间后感觉不是这样的,以前的看法太片面,都有问题的。公司的业务的不断迭代,人员不断流动,也有不同层次的人。旧代码即使再烂,也是都进过测试的,进过在市场中运行几年了,也是经过时间检验的。只能对特别影响的进行重构,很多东西牵扯很多的,修改一处后就有很多的问题的。再说公司的业务发展,个人的时间也都限制的。退一步来说,经理也是知道的,为什么没有做。代价太大了。楼主回复的观点很好的,现实中重要的是两个字“平衡”,平衡好各方面的东西才是现实所做的。学习了,谢谢楼主的分析和分享。

  • 无始无终 Java 工程师 2015/12/22

    拿着年轻说事,年轻就一定技术不行或者说评价不准吗,我也是呵呵了。我之前也遇到过同样的公司,烂就是烂,别拿着不是当理说。

  • 枫林魂 程序员 2015/12/22

    学校学的东西,在公司中真正使用出来是要有一定的变通适应的。不可能你进了一个公司,里面的代码氛围什么都是你理想中的样子,一个公司多年经营中会逐渐形成自己的特点。

  • 骷髅   2015/12/22

    只有两个字:惰性。

    首先,一个公司成功地成为大公司,不一定是因为技术优势。大部分成功的公司,只是在适当的时机做了适当的选择,做了能带来最大化利益的事。

    公司有点成就了,人就懒了,混混儿也就多了,还满口道理,是因为裁员也裁不到他了。
    公司大了,要想做点改变就更加困难了,因为涉及到利益的人太多了。

    但技术这东西,一直都在前进,大公司不见得就能代表技术水平。因为有了资本,做起来事来就会比初创公司更容易些,有了资本后,依靠的就不见得是技术上的优势了。

    一个团队搞不定,就加人手,也不用管是不是十个女人一个月就能生出孩子,反正有的是时间和钱。失败了推责任,砍团队,铁打的营盘流水的兵,大公司不缺人。

    所以,两个字就是,惰性。
    一个字就是,懒。

    大部分大公司都是如此。

  • 好文!看哭了!

  • 新兵目空一切,老兵自以为老练。

  • 问路书童 Web开发 2015/12/22

    是不是少了代码审查呢,我个人觉得代码审查真的太重要了,例如重复造轮子这样的事太容易犯了;还有大公司不是都有自己的一套代码规范的吗?不写注释,代码没有良好的缩进,真是抓狂的!

    • 骷髅   2015/12/23

      能够执行诸如代码审查,scrum,测试驱动之类方法的团队,其实是有个潜在的需求:团队成员的业务水平大致差不多。但能形成这样团队的确实不多,实行起来会有诸多问题,遭到各种质疑,短期内生产力反而会下降。关键是团队顶得住这种压力吗?负责人顶得住这种压力吗?惰性存在,就是因为延续惰性是最省力的。

    • clarkhillm 软件开发 2015/12/24

      做代码审查其实是很难的,首先这种权威不好找,其次,其权威性如何认定也很难。其次,这也是要成本的,如果确立为制度的话,需要更大的成本。最后,在大多数领导的眼里,技术算个屁呀。成功哪有靠技术的。

  • 为了评论特意注册用户。
    总的来说,我支持原文。
    后面两个程序员,首先,态度有问题。谦虚是程序员必需的。别人指出你的问题,你都承认有了,干嘛找那么多借口。明显是借口。历史问题,见识问题,不管什么原因,没做好就是没做好。
    至于拿公司或业务的“成功”反证自己系统由多优秀?只能说明你“合格”“堪用”。
    就像朝鲜战争,你不能说中国和美国是平局,于是中国和美国的军事“技术”是平局。暂时的“成功”、“未败”是人堆出来的,费效比非常低。如果抱着这种态度,那么中国就不用发展军事科技,不断大力整军了?
    整的太严肃了,戏谑几句,看上面公司是一家用Java的。我觉得一家用Java的公司,只要满足一条,就足以说弱爆了:
    用 MyEclipse
    以上。

    • invlong   2016/01/29

      为了回复你特意注册了用户,程序员大多是大学毕业,读过大学都念过高中,高中就是一所奴化的工厂,乍一听底下评论的很有道理,仔细一想,全是各种借口。有多少被奴化了的程序员喜欢这种高大上的回复呢?

  • sender_is_sender 高级打杂 2015/12/22

    关键是现实。现实决定了很多东西,而首要一点就是妥协,各种妥协。所有理想化的举动都必然死掉,毫无例外。

  • 梧桐   2015/12/22

    所有的问题归根结底就是两个问题:态度问题,能力问题。楼主的提问显然提到态度问题,而答主一直在找客观原因。现在早已不是十几年前了,那么多优秀的出版物,那么多开源项目可以学习。代码没有最完美,但不断追求完美应该是一个程序员最朴素的理想。而我们好多人态度和能力都有问题,当然收入低加班多也是原因之一。

    • 骷髅   2015/12/23

      一个程序员有态度有能力时,说出来的话不一定有分量。等他说出来的话有分量的时候,态度和能力大部分都已经不行了。

  • 其风   2015/12/23

    面对很多新来实习的同事的指点江山,我也大概会有相同的感慨。如果想对别人的做法进行一个公正的评价,可能也要将别人处理这些事情的背景也考虑进去。

  • nullA   2015/12/23

    所谓大公司借口真不少..

  • Moongrass   2015/12/23

    呵,烂就是烂,还不让说了?

  • iamybj   2015/12/23

    当我看到了这里:
    一个项目里,httpclient竟然出现了四种。
    一种是该公司研发部写的,
    一种是老版本的开源项目,
    一种是新版本的开源项目,
    还有一种是开发人员造的轮子。

    打接口请求响应日志,竟然不知道用拦截器。
    打错误日志竟然不打上下文信息,每个人一种日志风格,千奇百怪。
    许多重要的中间流程,居然不打日志。
    ----------------------
    的时候,我就停止了阅读,在原文上回复如下:
    不是人家弱爆了,而是你弱爆了。
    因为你还仅仅停留在如何使用斧子,把使用斧子的奇技淫巧当炫耀,而忘了砍树这样的真正目的的阶段。

    回复完之后,我又扫了一下后面,发现“下面是萧井陌的回答,伯乐在线已征得转载许可。”等人的回复,发现竟然和哥的观点基本一致。

    傻逼菜鸟,甚至某些自以为自己是高手的实际上狗屁不懂的人,总以为在代码优美、工整、拦截器、反射、设计模式方面弄好了才是有本事。而实际上,代码写得简单、健壮、性能高才是最重要的。

    这就和杜甫和李白的诗,李白的诗,拗口难懂,只是堆砌华丽辞藻,抒发的仅仅是个人不得志,个人困难等狭隘的个人主义思想。
    而杜甫的诗,不仅仅通俗易懂,流畅平实,更是抒发了对社会、国家的思考。
    由此可见,杜甫无论在思想、文学功力、见识水平等各个方面,都是超越几百个李白。

    写代码也一样,代码是后台的东西,外表看不见,所以写代码唯一的一个目的就是:简单、健壮、可靠、性能高。

    至于此人的菜鸟装逼作者胡说的什么拦截器这种奇技淫巧,我就说一句,就算不考虑性能,拦截器也需要修改代码,直接写到原来的代码里也需要修改代码,都是需要修改代码,我为什么还要用你的拦截器?

  • 李运华   2015/12/23

    我想如果转载我的回答,这篇文章会更加完整和有趣 :)

  • 良少   2015/12/23

    就不要否认自己技术烂了吧?
    用户密码泄露那次,忘记了?

  • 但丁 程序猿 2015/12/28

    看了文章里的反驳两段就看不下去了,仿佛他们的代码90年代写完后就再也没有动过了似的。。

  • 嘀咕 java,python,前端 2016/01/01

    这,都有道理

  • dreamway   2016/01/15

    我们公司最重要的原则就是——『拥抱变化』

    我仿佛知道了什么。

  • itjoyee   2016/01/18

    引用一下墨格尔的名言:存在即合理...
    不要抱怨太多,拥抱变化,改变自己能够改变的...

  • 哈哈哈哈哈哈,看得跌宕起伏的剧情

  • PunCha 程序员 2016/01/26

    新人有热情、有要求、有棱有角是好事,但是过了几年,你会发现,当初的热情已经不在,要求被需求打败,棱角因为绩效差而渐渐被磨平。这才是最遗憾的。
    看了后面的看似“正确的”回复,我觉得反而是在狡辩。比如:
    1)“我记得非常清楚,因为以我多年经验来看这样的做法是不可取的,但是本着锻炼年轻人的心态” -- 锻炼年轻人不能以牺牲项目质量为代价,你把项目当儿戏吗?
    2)“IDE 的配置文件传到代码仓库是我定下的规矩”,不要倚老卖老,这就是不好的!
    3)“插件也不用上传到服务器保存,我告诉你这样是不行的,你要考虑到我们这个项目前后十余年,你觉得几个插件能坚挺十余年?”:插件是可能挺不住几年,但是解决的方法不是上传服务器,还有很多成熟的,更加优雅的方案。为什么就草率的、简单的上传了呢?
    。。。。

  • 这个问题不能这么片面的评判,你也是做这个的,应该懂得有些不是你能左右的,万事没有绝对的!(引用楼上的评论:你现在写的牛逼代码在后人看来都是渣。。。)

  • 老旧技术肯定落后,这个话题之所以引来旧团队的反驳,其实是既得利益团体保护奶酪的条件反射,这是一种自我保护行为

  • 这个有意思,不过,别人聘你来就是解决问题的,要是没问题了还找你干吗

  • 反正就是十几年过来的,总会有点问题。我们公司牛逼,怎么可能会这么烂。要不开源下代码,大家一起看看呗,到底是真牛还是真忽悠

  • easonlv 互联网技术研发工程师 2016/05/21

    你还是太年轻了……

  • 问题是有些领导会说,你当初看到这些代码有问题,这么长时间了,为什么都不去修改?等着我来让你修改吗?没有一点自觉性吗?

    呵呵

  • Mike 程序员 2017/10/11

    卖机票的,明显是某携?某程

跳到底部
返回顶部