部门太多，不同的部门的体验完全不一样，我说的只是我的感受，不代表其他部门也是这样的。
流程更规范
代码提交有 CR，有自动化测试。发布讲究三板斧（灰度，监控，止血）。
项目更深度
做的是小程序 IDE，在外部真的很难接触到这么复杂的前端项目。虽然有开源的 VS Code，但是你只能生啃源码，没有人带你熟悉，给你小需求让你熟悉整个项目 /
基建更完善
所有内部工具都是自研的，没有网络问题，遇到问题可以找人修，不行还能自己 PR 。
有点理解为什么有些关于程序员基础技术素养的书总建议要做 code review，要搭建自动化构建流程，要将代码规范自动化起来之类的话。从我的理解，这不都是常识吗？
@wenlele 这些本来就是常识啊，我开始工作的时候，工作主要是 70，80 后，对这些东西代码质量等都有公司的要求，那时候 CI 可能没有今天这么丰富，用 Apache ANT 时代的只知道有经典的 AntHill 。
现在 CI 都云化了，这些东西给以前简单多了。只是在国内的新一代的程序员中，这些都成了装逼，不符合国情，拖延进度等等借口。
在微软，自动化测试还是相当重要的。没法自动化测试，改代码的代价太大了。我们没有单独的测试和运维，全是工程师干；也许这样自己就不想给自己挖坑了。
大点的开源项目会有 good first issue 的 issue，是用来熟悉项目的
基建完善见仁见智了。。。
第一周看了天马 /奥创 /dx，这轮子一层又一层，看得我十分迷惑
没有网络问题是啥，我平时看的很多文档还是加载慢，得用自己的 **，而且园区出口 ip 虽然与 ** 一个网段，但是似乎并不走 CN2，也很迷惑
感觉阿里的数据平台不如字节的 Data 简单易用
感觉 alilang 体验也不如字节的 Seal，第一次连的时候那个提示我就没看明白
阿里很多英文文案 /场景感觉没有被 review 过，混着中文和词不达意的问题很多
我看 IDE 似乎是自己嗯糊的一个提示，还带着捉鸡的 snippets，不考虑迁移到标准的 custom data 上面吗？
https://code.visualstudio.com/blogs/2020/02/24/custom-data-format
自己的开源项目 lint CI 持续集成都有搞。
就拿 VS Code 说，他们有专门团队来维护，你除非自己入职，不然就只能修修小 Bug，也没人来带你熟悉项目。
即使最后是别人再修改代码后引起线上故障，复盘的时候如果没有自动化测试把住缺陷，根因会被认为是一开始没加自动化测试。 写自动化测试，主要目的不是测试这次改动，而是把住以后的改动。
如果说是添加自动化测试成本太大，导致大多数人不想做这个事情，那么在总结事故的根因的时候会认为缺乏高效的自动化测试的编程框架也是其中一个原因，需要相应的团队在中长期（ 1-3 月）解决这个问题，比如优化自动化测试流程，从而减轻写自动化测试的成本。
为了赶工期而跳过写自动化测试，我觉得这只是将一些工作放在未来而已。在工程上，我并不觉得发生这种事很稀奇，哪怕在微软。只是我们在做这个选择的时候，明白要承担的风险，以及需要后续做减轻这个风险，比如之后一周内补自动化测试，等。
如果为了短期的工期牺牲了代码缺陷率，未来的工期怎么都快不了了。不过，我不知道在小公司是不是不需要考虑未来。。
内部有提供 vs code 插件，可以去搜一下。
我对最后一句话有点疑惑，如果大概率只用一两次的功能，为什么要实现它？
可灰度, 可监控, 可回滚
很重要, 但是能每次上线都做好的人并不多
一般项目只要超过三个月，写测试的收益就可以收回，开始阶段你可能会认为花了太多时间去做基础，没有将注意力转移到业务上来。如果长期的产品开发，到了半年的时候，你的产品已经上线一两个大版本，有一定种子用户，每次上线必须保证兼容性，这时候你就会发现，在项目初期，投入几周去重点做 Insfrastruture （定制一系列产品发布自动化流程 Pipeline 脚本）有多么重要。只有平时写代码花时间积累足够的测试，每次修改都通过 CI Replay 去验证所有的测试场景都不会因为代码变更而罢工，在产品进入相对平稳的阶段，才可以做到真正意义上的省人省力。
很多时候这种功能其实开发自己是知道沉淀不出来什么东西的，甚至很多团队是把这种功能集中放在一个独立的应用上，便于不影响核心功能，这时候基本就是开发做完功能自测没问题就提交给测试来测了，很少写单测；而 CR 就完全看开发自己有没有信心了，如果你自己觉得不放心就在测试测完后再提给有空的人来帮忙看看。
终于体会到什么是提交完代码可以去吃饭回来还没跑完测试，比如 jsdom 只跑一部分 https://github.com/web-platform-tests/wpt 的测试就得半个小时。。
有的东西只能内网搞，内网最多有个 Git 。能外网搞的项目想上 CI/CD 直接给你 Jenkins 的账号自己配，中间用什么技术也没太大的限制后来的人能上手就行，写不写测试没有要求，代码基本不用考虑合并也不用审。后端倒是可能有时候会有数据量很大的时候，但不管用什么技术能解决就好。感觉主要还是因为有的地方的需求就只是想有录入数据的地方，有一些页面并且上面有真实的数据，稳定性要求不高，有 bug 也能容忍，别出致命的问题就行。
但这么搞有一点恨不能忍，就是出了问题总得有人背锅，没有运维和测试锅就直接穿到开发头上了。