内容简介：每日早8点半，精品技术文章准时送上
点击上方 石杉的架构笔记 ，右上选择“ 设为星标 ”
每日早8点半，精品技术文章准时送上
往期文章
来源：大数据肌肉猿
一、写作背景
二、各类型公司的环境氛围
三、各类型公司的开发流程规范
四、如何提高在公司的核心竞争力
五、一些中肯建议
一、写作背景
本人在大学期间有过三段实习，大二在一家外包公司，大三去了技术型公司，现在待在一个业务驱动型公司。
认识我比较久的读者应该知道，我经历了一次优秀实习生，两次提前转正，最近这份工作原本半年的试用实习期，只实习了一个月就提前转正。
写这篇文章有三个目的：
-
纯粹地分享这三家的工作经历。
-
分享的同时，给在校生和未在这些公司中从事工作的同学一些参考。毕竟在自己没有真正经历过之前，都只是别人口中所说，也是所谓的「围城」。
-
由于本人有阶段性复盘的习惯，对这三段工作的表现自认为还可以，这边也会针对不同类型的公司分享一些提高核心竞争力的经验。
二、各类型公司的环境氛围
①外包
我们当时团队有10个人，入驻到一家国企里面进行开发，分配给我们的只有一个小房间，而且这个房间之前还是仓库，在公司的最角落。
房间里面的氛围「很符合」开发气氛，只有到饭点了有人喊吃饭了才有声音，其他时候一片寂静。
这家国企有自己的食堂，他们的员工都是包餐的，人手一张卡。但是这家企业给到我们团队的只有一张卡，也就是我们团队共用一张卡，所以到食堂之后我们得排在一起轮流刷。
吃完饭之后，团队的每个人需要给CTO转12元作为中午的饭钱，CTO收完之后统一转给该企业财务，也就是我们不包餐。
轮流刷卡，不包餐这些都还好，毕竟外包团队嘛，也能理解。但是食堂有时在节假日特意煮了汤或者其他什么的，一看到我们团队来了，就直接说我们没有。
有一次中秋节，人事部在食堂门口发礼盒，团队的老员工要去领，人事部的人由于对我们比较陌生，于是问了一下基本信息，一听到我们是技术部的，赶紧挥了挥手说没有。
虽然这家外包996，一个月只发我800工资，而且还用支付宝转账，但我还是挺感激给予我这样的机会让我学习，没有「 归属感 」和「 认同感 」也告诉我仅仅只能实习，这两种感觉相信在外包的朋友都深有体会。
②技术导向型
这家公司是真正意义上的技术型公司，公司产品的核心竞争力就是技术，解决市场上其他竞品解决不了的。
该公司的创始人及管理层全都是技术人员出身，企业内部还设了一个大学，上面有必修课和选修课，上完课之后要参加考试，考试成绩作为年终绩效指标之一。
公司里上到HR，下到底层研发人员都得接受大数据知识的洗礼，随口就是各种Hadoop、Spark。除此之外，公司还会经常外界技术人士来公司分享，企业内部也会经常性做分享。
这种技术氛围也是每个技术人所向往的，遇到什么难题，内部员工头脑风暴一下就能解决。
这种企业里的技术人员是具备核心地位的，核心部门也必须是开发部，并且针对不同的技术，内部分工会分的比较细，具体到哪个模块，哪个功能。
③业务驱动型
在这种公司，开发部门正常都不是核心部门，但同时又是不可缺少的。拿我现在的电商公司来说，数据部门主要是为了给运营部提供一些数据让他们更好地去定价，定制活动等。
公司的核心竞争力应该是产品，其次是模式，而模式包含着运营、销售等。技术只是作为辅助这种模式建立的一份子，搭建一个平台，或者出一些指标数据，都是为了更好服务业务。
市面上大部分互联网公司都是业务驱动型公司，这类公司会把部分边缘业务外包出去，重点做核心业务，对于核心业务的技术又没像技术型公司一样苛刻，谋求最佳性价比。
三、各类型公司的开发流程规范
①外包
「 不管是烂代码还是冗余代码，只要能实现功能的就是好代码 」。大部分的外包公司或者说基本所有的外包公司都不会做code review，只要能把功能实现交给客户就行。
大二的时候，我们团队虽然驻扎在一家国企里面，但真正做该企业项目的只有我一个人，其他人都在做不同的项目。
我那时既自豪又感概，自豪地跟同学说我自己一个人搞一个国企项目，感慨公司心真大，把一个国企项目交给我的一个实习生来做。
那时也不懂什么叫好代码，都是冲着功能实现去的，各种调包，copy & paster，if else while for常常写出「 死亡三角 」，没人批评我说代码写的丑，没人让我封装，都是夸我功能实现的快，就是bug多了点
产品经理时不时地走到我身边，跟我说要加哪些功能，哪些不要，业务逻辑都是freestyle，现场画逻辑图。
刚开始不懂，认真地听产品经理说，然后拿小本本记。后来我的leader跟我说：「 别听产品经理的，有不懂的问我就行 」，到后来国企的运营部也来找我提需求，真的是人人都是产品经理啊！
团队里没有专门的测试同事，都是上线那天一起加班，国企运营部的人帮忙测试，我们开发就在旁边实时解决测出来的问题，顺利的话当天发布，要是有遇到解决不了的bug就结束加班，明天继续。
这个项目经过我手之后写的是又大又烂，现在的我也看不下去那些代码了，这个项目在我走之后也下线了。
在这家公司，我 从跟甲方博弈，到跟产品经理撕逼，再到前端后台数据库服务器，全搞了一遍 。不得不说这也是一个难得的学习机会，但是我在下一家公司尝了这家公司带给我的苦。
②技术型公司
一年后来到了这家公司，这家公司是数仓行业的标杆，产品是To B的，客户都是各领域的KOL，又是中国第一个Apache顶级开源项目，无论是技术还是开发流程规范说领先的应该不过分。
先看看我们的开发流程和规范：
1.PRD/issue
如果是新功能，而且相对比较大的，需要产品经理画出原型图以及详细说明清楚
如果是bug或者比较小的功能，需要在github的issue上说清楚。口头说的永远无效，如果产品经理口头对我们说什么，我们都会要求他给文档、发邮件或者在issue上说明清楚，也是保留证据，防止互相甩锅。
2.本地Reproduce
本地重现bug。也就是出现bug的时候，我们开发要进行本地重现，只有重现出来才能从根本上解决问题。
这一步是最难的，也是耗时最长的。如果连bug本地重现也重现不出来，后续工作基本难以进行。
3. 定位Root cause
对于Bug，我们要先找到引起的根本原因，这块最考验综合能力。mentor给我的箴言就是：「 大胆假设，小心求证 」。
你需要把所有可能性列出来，然后一个个去证实。只有定位了Root cause，你才能开始去写代码。
4.Design review
这是代码架构设计上的一个review，是跟mentor或者leader对接确认的，在编写代码之前完成，避免设计不行，被全部推翻。
这块也要写在github的issue，一方面为后人留下痕迹，便于后面维护或者迭代复盘。而且高层也经常翻阅issue，design review做的不好，也会被指出来，及时发现问题。
5.代码编写(阿里巴巴手册，UT，IT)
写好代码是新手的基本要求，不写低质量代码。这边要求按照effect java以及阿里巴巴代码手册进行约束，以及每写完代码都要通过UT或者IT进行覆盖。
6.Test plan
当你写完代码之后，你需要制定一个测试计划，也就是测试用例，去解决之前相同操作下会出现的bug或者验证你的新功能。
7.Test evidence
也就是Test plan制定完之后进行实施，将验证成功的截图进行保留，贴到issue，作为你完成功能的证据。
8.CI
Continuous Integration-持续集成服务，它会自己运行构建和测试，反馈过程中是否存在Bug或者其他问题，看是否与我们预期的结果一致。
我们是在Jenkins上完成的，当你的代码有点改动你就需要去跑CI，避免影响到系统的其他模块。
9.Code review
当你写完代码并且通过测试之后，通过pr的方式先给导师review，导师review完之后提交给leader。 对于一些比较重要的模块，在leader看完代码之后还要进一步提交给CTO。
看完这个你还敢提交烂代码？别说烂代码了，一个变量名定义的不好都得被打回来。
刚开始入职的时候觉得这些操作很烦，改一行代码就得去issue上面写一堆，而且也要跑个几小时的CI。当后来吃了几次亏，真香。别看除了代码编写还有很多其他操作，其他操作也是为了让你更好地去编写代码，帮你梳理整个开发流程，也不自觉地提升你工作的严谨性。
所以到现在，我来公司解决的第一个bug，我都还知道Root cause，以及其他细节。其他人也知道，因为我都贴在issue上面。
由于我在第一段工作中养成很多不好的习惯，比如说代码写的又快又烂，debug各种log乱打，为了实现功能破坏了 设计模式 等等。
所以在第二段工作经历中被骂的狗血淋头， 国庆7天看了4本关于代码设计的书籍并做了总结，对项目源码进行深入阅读，学习一些设计模式等等 。
在第二家公司，虽然被怼了很多，但是收获非常大，可以看我在第三家的表现。
③业务驱动型
业务驱动型的公司处于外包和技术型之间，也是以实现功能为主，又要注重后期维护，对规范处于中立状态，不挖坑，不矫情。
由于我从第二家公司出来后，对代码有一定的洁癖，所以到了第三家公司一有空就重构项目代码，leader也赞同我的行为，经常找我聊代码设计和规范。
我也主动申请要补充部门的开发流程规范，数据库的字段规范，并补全项目代码的UT、IT等等。这也是我能提前转正的原因之一。
四、如何在不同类型的公司提高核心竞争力
在外包公司， 不能局限于一个点进行开发 ，外包公司需要的是全能型人才，哪里缺哪里补上。
在外包公司不需要你技术多厉害，但需要你会利用现成的资源以最快的速度完成项目开发。你会的方面越多，公司需要你的地方也就越多，你得到的也更多。
在技术型公司，不需要你会的有多广，你只需要针对公司产品的一个点进行深入了解，不断地进行优化，这个点就是你的核心竞争力。再由这个点切入到相关模块， 技术深度才是王道 。
在业务驱动型公司，不能光会技术，当其他开发人员只会跟老板讲技术，而你能将 具体技术落实到业务，并且能从业务层面反推到技术实现 ，老板能不喜欢吗？但也要记住， 技术是生存之道，别顾此失彼，耍小聪明 。
技术人员的核心竞争力终究是技术，但技术也分广度、深度、与业务结合的能力，在不同的环境下，应该学会取舍。
五、一些中肯建议
1.外包公司能不能去？
在没有更好的选择下，能去，有总比没有好。并不是所以的外包公司都是一个模样，说不定你的leader好，服务的又是又好又有钱的甲方，好吃好喝好款待。但大部分的外包还是不咋地，这边调查好背景就行。
2.技术型公司哪里找
所有开源项目背后的公司都是技术型公司。比如开源Kylin的Kyligence，开源Dubbo、RocketMQ的阿里、开源Flutter的谷歌等等。
而像阿里、腾讯这种大公司，每个BU就是一个类型的小公司，有些负责技术，有些负责业务，有些外包。
3.对于应届生的选择
建议去技术型公司或者核心技术部门。从我的案例就可以看到，技术型公司对我一个整体的塑造帮助最大，可能贯彻职业生涯。
当你习惯了低标准的东西久了，就很难对高标准产生兴趣。
4.我对于这三种公司的看法
对于外包公司来说，我觉得会缺失「归属感」和「认同感」，毕竟做的不是自家的产品，还得去客户现场驻扎，而且对于外包的技术也是不太看好。
对于技术型公司来说，对于个人成长帮助绝对很大，但在这种公司由于周围都是level比你高的人，解决的问题也都是比较难的，所以无形中会有压力并且会产生焦虑。
对于业务型公司来说，最好是选择你比较擅长的并且有相关工作经验的业务。我第一段实习做的是电商项目，所以我现在的工作也是找的电商，毕竟业务逻辑都是相通的，就算之后跳槽，也会选择电商行业，毕竟除了技术，行业知识也是竞争力之一。
最后，选什么类型公司，仁者见仁，智者见智，以后只是我自己综合待过三种类型公司的一些体会，大家可以参考，并根据自己的兴趣以及擅长的地方做选择。
END
如有收获，请划至底部，点击“ 在看 ”，谢谢！
推荐阅读：
-
从团队自研的百万并发中间件系统的内核设计看 Java 并发性能优化！
更多文章：
欢迎长按下图关注公众号 石杉的架构笔记
BAT架构经验倾囊相授
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
- 读懂智能对话系统（1）任务导向型对话系统
- 外包程序员被HR嘲讽：只有找不到工作的才去外包
- 外包程序员的幸福生活
- 2019.6阿里外包电面经历
- 研究表明全球外包服务继续加速增长
- 你也看不起做外包的程序员？
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
未来世界的幸存者
阮一峰 / 人民邮电出版社 / 2018-6-1 / 39.00 元
本书为阮一峰博客文集，主要收录的是作者对技术变革的影响的一些思考，希望能够藉此书让读者意识到世界正在剧烈变化，洪水就在不远处，从而早早准备出路。本书适合所有乐于思考的读者。一起来看看 《未来世界的幸存者》 这本书的介绍吧!
