野生程序员在大厂三个月的体验

原来野生这么“野生”啊 = =

有点理解为什么有些关于程序员基础技术素养的书总建议要做 code review，要搭建自动化构建流程，要将代码规范自动化起来之类的话。从我的理解，这不都是常识吗？

@wenlele 他的意思是相对于小厂吧

Java 转前端？

@peapods 嗯，你指正的对。

阿里的相当混乱，写测试，做自动化测试的项目估计没几个，看看阿里开源的项目就知道样子了。大部分人和一般公司一样，出了问题还是靠人的嘴扯皮，还是人肉测试，人肉运维，反正 996 可以加班赚加班费的嘛 。

@wenlele 这些本来就是常识啊，我开始工作的时候，工作主要是 70，80 后，对这些东西代码质量等都有公司的要求，那时候 CI 可能没有今天这么丰富，用 Apache ANT 时代的只知道有经典的 AntHill 。

现在 CI 都云化了，这些东西给以前简单多了。只是在国内的新一代的程序员中，这些都成了装逼，不符合国情，拖延进度等等借口。

那么难用的蚂蚁开发者工具原来就是楼主搞的

@hantsy wow 。突然想到一年前看到抖音里某阿里研发部门的视频，一个程序员问另一个程序员写不写单元测试，对方说当然不写然后不屑地呵呵一笑，然后问的程序员也表示露出了表示认同的邪笑。当时我还觉得应该是开玩笑的段子，看来有可能是真的。

在微软，自动化测试还是相当重要的。没法自动化测试，改代码的代价太大了。我们没有单独的测试和运维，全是工程师干；也许这样自己就不想给自己挖坑了。

每天几点下班

@hantsy @wenlele 阿里内部虽然没有一致的要求，写不写单测和自动化测试完全取决于是否核心应用、基础设施、程序员素养。
1.核心应用和基础设施：单元测试、CR 要求是必须的，自动化测试会有独立的测试人员来写，集成测试很多应用已经基于线上采集的真实流量来测试了，这对于核心应用都是必须的。出了事情大家都得背锅...
2.非核心应用（业务应用）：是否写单元测试完全取决于程序员自己的素养，而 CR 都同样也看团队主管或者程序员的自信心，对于容易出问题的代码大家都会互相帮忙看看。这时候自动化测试一般就没人来写了，而集成测试还是必须的。
3.以我个人的拙见，单测、CR 、自动化测试本质是软件质量和效率，而质量、效率本质是为商业服务。一个大概率只用一两次的功能有必要花数倍的时间去做这些吗？

代码规范，自动化部署，测试这些东西一般自己都能学吧，我还在学校经常看 github 就有意识学这方面的东西了。。

@utodea 业务应用代码写单测真是浪费时间。。。说不定明天需求就改了。。一直在小公司混，从来没见人写过什么单元测试。。

@wenlele 一般常识，写自动化测试时间是业务代码的 2-3 倍，也就微软会给你这么长工期。。

实际上很多开源项目是更加规范的
提交后会有大量的自动化测试+预览

大点的开源项目会有 good first issue 的 issue，是用来熟悉项目的

基建完善见仁见智了。。。
第一周看了天马 /奥创 /dx，这轮子一层又一层，看得我十分迷惑

没有网络问题是啥，我平时看的很多文档还是加载慢，得用自己的 **，而且园区出口 ip 虽然与 ** 一个网段，但是似乎并不走 CN2，也很迷惑

感觉阿里的数据平台不如字节的 Data 简单易用

感觉 alilang 体验也不如字节的 Seal，第一次连的时候那个提示我就没看明白

阿里很多英文文案 /场景感觉没有被 review 过，混着中文和词不达意的问题很多

那图标就像便秘了一样

@raaaaaar 我这些都学过，也参与过贡献过的开源项目 （ VS Code ,Ant Design )。

自己的开源项目 lint CI 持续集成都有搞。


就拿 VS Code 说，他们有专门团队来维护，你除非自己入职，不然就只能修修小 Bug，也没人来带你熟悉项目。

@jason94 9:30 吧，上家公司虽然 6:00 下班，但是我还是会呆在公司看代码，所以对我来说差不多。

@fengjianxinghun 不做自动化测试的代价可不小。

即使最后是别人再修改代码后引起线上故障，复盘的时候如果没有自动化测试把住缺陷，根因会被认为是一开始没加自动化测试。 写自动化测试，主要目的不是测试这次改动，而是把住以后的改动。

如果说是添加自动化测试成本太大，导致大多数人不想做这个事情，那么在总结事故的根因的时候会认为缺乏高效的自动化测试的编程框架也是其中一个原因，需要相应的团队在中长期（ 1-3 月）解决这个问题，比如优化自动化测试流程，从而减轻写自动化测试的成本。

为了赶工期而跳过写自动化测试，我觉得这只是将一些工作放在未来而已。在工程上，我并不觉得发生这种事很稀奇，哪怕在微软。只是我们在做这个选择的时候，明白要承担的风险，以及需要后续做减轻这个风险，比如之后一周内补自动化测试，等。

如果为了短期的工期牺牲了代码缺陷率，未来的工期怎么都快不了了。不过，我不知道在小公司是不是不需要考虑未来。。

@azh7138m

内部有提供 vs code 插件，可以去搜一下。

@utodea 谢谢分享。基本认同。 工程的基础设施是很重要的，如果测试的基础设施太差，我们测试的欲望也会受打击。如果测试的效率成为了产品工程流程的瓶颈，自然也会投入资源去改善。

我对最后一句话有点疑惑，如果大概率只用一两次的功能，为什么要实现它？

三板斧

可灰度, 可监控, 可回滚

很重要, 但是能每次上线都做好的人并不多

@wenlele 赶工期可以说是国内我听到最多的借口了。国内的程序员都是自己机器跑一下就完了（然后测试人员测出问题，他们还有一句经典的话，“在我的机器上是没问题的”），然后依赖人工 Exploratory Test，按一些统计来看，这种测试方法覆盖率仅 15-20%，一不小心引发线上系统的致命漏洞问题，所以在产品变得复杂的时候，这种全部依赖人工才是真正的浪费时。结果就常常就引发了全员加班改 Bug，常常很多时间去找问题所在。长期的结果，对技术完全没兴趣，对工作仅仅应付老板。

一般项目只要超过三个月，写测试的收益就可以收回，开始阶段你可能会认为花了太多时间去做基础，没有将注意力转移到业务上来。如果长期的产品开发，到了半年的时候，你的产品已经上线一两个大版本，有一定种子用户，每次上线必须保证兼容性，这时候你就会发现，在项目初期，投入几周去重点做 Insfrastruture （定制一系列产品发布自动化流程 Pipeline 脚本）有多么重要。只有平时写代码花时间积累足够的测试，每次修改都通过 CI Replay 去验证所有的测试场景都不会因为代码变更而罢工，在产品进入相对平稳的阶段，才可以做到真正意义上的省人省力。

@hantsy I can't agree with you any more.

说到小程序 IDE, 特别想吐槽下
能不能不要在我的用户目录下创建那么多的隐藏文件夹 ！！！！
配置文件啥的都统一到一个隐藏文件夹下很难吗？？？？

@uxstone 历史遗留问题, 要化大力气才改的了, 成本太高不合算

@hantsy 赶工期才不是借口，你要是在国内呆的足够多的地方，就会明白技术实施依赖于组织框架，很多问题的根源指向老板，不是你技术人员想的那么美好

我要是楼主，连面试机会都没有。楼主的确很厉害

说到开发规范最近能力才够参与一些被广泛的使用的项目，发现为开源项目贡献代码和产出公司的业务代码差距真大啊。

终于体会到什么是提交完代码可以去吃饭回来还没跑完测试，比如 jsdom 只跑一部分 https://github.com/web-platform-tests/wpt 的测试就得半个小时。。

可能我接触的行业比较少，感觉做项目 /外包的都是几个人就能做 1 产品、1 UI 、1 前端 、1 后端，大的也就加上一两个前后端、加个测试，小的就去掉 UI 直接前端开搞，产品也去掉直接开发对需求。

有的东西只能内网搞，内网最多有个 Git 。能外网搞的项目想上 CI/CD 直接给你 Jenkins 的账号自己配，中间用什么技术也没太大的限制后来的人能上手就行，写不写测试没有要求，代码基本不用考虑合并也不用审。后端倒是可能有时候会有数据量很大的时候，但不管用什么技术能解决就好。感觉主要还是因为有的地方的需求就只是想有录入数据的地方，有一些页面并且上面有真实的数据，稳定性要求不高，有 bug 也能容忍，别出致命的问题就行。

但这么搞有一点恨不能忍，就是出了问题总得有人背锅，没有运维和测试锅就直接穿到开发头上了。

谈谈自动化测试：在回归测试上的效用比较高，因为总不能改一个功能，全部人力从头穷举一遍。

@utodea 受教了。

@wenlele 微软 日常 bug 这么多，看来自动化解决不了啥问题呀。

赶工期当如果是商业行为也就算了，当它称谓政治行为那就是不可抗力了

小程序 ide ？又卡又难受，求快速优化