这是一个创建于 1581 天前的主题，其中的信息可能已经有所发展或是发生改变。
我在小厂做了接近 2 年的 Java 后端，1 年多的 React 前端，前段时间跳槽到了福报厂当 webpack 工程师，说一下三个月的体验。
部门太多，不同的部门的体验完全不一样，我说的只是我的感受，不代表其他部门也是这样的。
流程更规范
代码提交有 CR，有自动化测试。发布讲究三板斧（灰度，监控，止血）。
项目更深度
做的是小程序 IDE，在外部真的很难接触到这么复杂的前端项目。虽然有开源的 VS Code，但是你只能生啃源码，没有人带你熟悉，给你小需求让你熟悉整个项目 /
基建更完善
所有内部工具都是自研的，没有网络问题，遇到问题可以找人修，不行还能自己 PR 。
部门太多，不同的部门的体验完全不一样，我说的只是我的感受，不代表其他部门也是这样的。
流程更规范
代码提交有 CR，有自动化测试。发布讲究三板斧（灰度，监控，止血）。
项目更深度
做的是小程序 IDE，在外部真的很难接触到这么复杂的前端项目。虽然有开源的 VS Code，但是你只能生啃源码，没有人带你熟悉，给你小需求让你熟悉整个项目 /
基建更完善
所有内部工具都是自研的，没有网络问题，遇到问题可以找人修，不行还能自己 PR 。
 |
1
wenlele 2020-07-12 07:19:11 +08:00  2
原来野生这么“野生”啊 = =
有点理解为什么有些关于程序员基础技术素养的书总建议要做 code review，要搭建自动化构建流程，要将代码规范自动化起来之类的话。从我的理解，这不都是常识吗？ |
 |
3
becauseOf 2020-07-12 09:16:36 +08:00 via Android
Java 转前端？
|
 |
5
hantsy 2020-07-12 09:43:55 +08:00
阿里的相当混乱，写测试，做自动化测试的项目估计没几个，看看阿里开源的项目就知道样子了。大部分人和一般公司一样，出了问题还是靠人的嘴扯皮，还是人肉测试，人肉运维，反正 996 可以加班赚加班费的嘛 。
@wenlele 这些本来就是常识啊，我开始工作的时候，工作主要是 70，80 后，对这些东西代码质量等都有公司的要求，那时候 CI 可能没有今天这么丰富，用 Apache ANT 时代的只知道有经典的 AntHill 。 现在 CI 都云化了，这些东西给以前简单多了。只是在国内的新一代的程序员中，这些都成了装逼，不符合国情，拖延进度等等借口。 |
 |
6
Loserzhu 2020-07-12 09:44:36 +08:00 2
那么难用的蚂蚁开发者工具原来就是楼主搞的😂
|
|
7
wenlele 2020-07-12 09:53:59 +08:00
@hantsy wow 。突然想到一年前看到抖音里某阿里研发部门的视频，一个程序员问另一个程序员写不写单元测试，对方说当然不写然后不屑地呵呵一笑，然后问的程序员也表示露出了表示认同的邪笑。当时我还觉得应该是开玩笑的段子，看来有可能是真的。
在微软，自动化测试还是相当重要的。没法自动化测试，改代码的代价太大了。我们没有单独的测试和运维，全是工程师干；也许这样自己就不想给自己挖坑了。 |
 |
8
jason94 2020-07-12 09:54:06 +08:00
每天几点下班😳
|
 |
9
utodea 2020-07-12 11:01:24 +08:00 2
@hantsy @wenlele 阿里内部虽然没有一致的要求，写不写单测和自动化测试完全取决于是否核心应用、基础设施、程序员素养。
1.核心应用和基础设施：单元测试、CR 要求是必须的，自动化测试会有独立的测试人员来写，集成测试很多应用已经基于线上采集的真实流量来测试了，这对于核心应用都是必须的。出了事情大家都得背锅... 2.非核心应用（业务应用）：是否写单元测试完全取决于程序员自己的素养，而 CR 都同样也看团队主管或者程序员的自信心，对于容易出问题的代码大家都会互相帮忙看看。这时候自动化测试一般就没人来写了，而集成测试还是必须的。 3.以我个人的拙见，单测、CR 、自动化测试本质是软件质量和效率，而质量、效率本质是为商业服务。一个大概率只用一两次的功能有必要花数倍的时间去做这些吗？ |
 |
10
raaaaaar 2020-07-12 11:55:36 +08:00 via Android
代码规范，自动化部署，测试这些东西一般自己都能学吧，我还在学校经常看 github 就有意识学这方面的东西了。。
|
 |
11
fengjianxinghun 2020-07-12 12:16:46 +08:00
@utodea 业务应用代码写单测真是浪费时间。。。说不定明天需求就改了。。一直在小公司混，从来没见人写过什么单元测试。。
|
|
12
fengjianxinghun 2020-07-12 12:17:47 +08:00
@wenlele 一般常识，写自动化测试时间是业务代码的 2-3 倍，也就微软会给你这么长工期。。
|
 |
13
azh7138m 2020-07-12 13:03:42 +08:00 via Android
实际上很多开源项目是更加规范的
提交后会有大量的自动化测试+预览 大点的开源项目会有 good first issue 的 issue，是用来熟悉项目的 基建完善见仁见智了。。。 第一周看了天马 /奥创 /dx，这轮子一层又一层，看得我十分迷惑 没有网络问题是啥，我平时看的很多文档还是加载慢，得用自己的 **，而且园区出口 ip 虽然与 ** 一个网段，但是似乎并不走 CN2，也很迷惑 感觉阿里的数据平台不如字节的 Data 简单易用 感觉 alilang 体验也不如字节的 Seal，第一次连的时候那个提示我就没看明白 阿里很多英文文案 /场景感觉没有被 review 过，混着中文和词不达意的问题很多 |
|
14
azh7138m 2020-07-12 13:08:37 +08:00 via Android
说到小程序 IDE
我是用 VSCode，所以自己做了一份简易的标签提示 https://github.com/muzea/ali-mp-custom-data/blob/master/ali-mp.html-data.json 我看 IDE 似乎是自己嗯糊的一个提示，还带着捉鸡的 snippets，不考虑迁移到标准的 custom data 上面吗？ https://code.visualstudio.com/blogs/2020/02/24/custom-data-format |
 |
15
blurh11E27 2020-07-12 13:20:57 +08:00
那图标就像便秘了一样
|
 |
16
yuanfnadi OP @raaaaaar 我这些都学过，也参与过贡献过的开源项目 （ VS Code ,Ant Design )。
自己的开源项目 lint CI 持续集成都有搞。 就拿 VS Code 说，他们有专门团队来维护，你除非自己入职，不然就只能修修小 Bug，也没人来带你熟悉项目。 |
|
18
wenlele 2020-07-12 13:23:35 +08:00
@fengjianxinghun 不做自动化测试的代价可不小。
即使最后是别人再修改代码后引起线上故障，复盘的时候如果没有自动化测试把住缺陷，根因会被认为是一开始没加自动化测试。 写自动化测试，主要目的不是测试这次改动，而是把住以后的改动。 如果说是添加自动化测试成本太大，导致大多数人不想做这个事情，那么在总结事故的根因的时候会认为缺乏高效的自动化测试的编程框架也是其中一个原因，需要相应的团队在中长期（ 1-3 月）解决这个问题，比如优化自动化测试流程，从而减轻写自动化测试的成本。 为了赶工期而跳过写自动化测试，我觉得这只是将一些工作放在未来而已。在工程上，我并不觉得发生这种事很稀奇，哪怕在微软。只是我们在做这个选择的时候，明白要承担的风险，以及需要后续做减轻这个风险，比如之后一周内补自动化测试，等。 如果为了短期的工期牺牲了代码缺陷率，未来的工期怎么都快不了了。不过，我不知道在小公司是不是不需要考虑未来。。 |
|
20
wenlele 2020-07-12 13:28:02 +08:00
@utodea 谢谢分享。基本认同。 工程的基础设施是很重要的，如果测试的基础设施太差，我们测试的欲望也会受打击。如果测试的效率成为了产品工程流程的瓶颈，自然也会投入资源去改善。
我对最后一句话有点疑惑，如果大概率只用一两次的功能，为什么要实现它？ 😂 |
 |
21
Jooooooooo 2020-07-12 14:17:47 +08:00
三板斧
可灰度, 可监控, 可回滚 很重要, 但是能每次上线都做好的人并不多 |
|
22
hantsy 2020-07-12 15:40:42 +08:00
@wenlele 赶工期可以说是国内我听到最多的借口了。国内的程序员都是自己机器跑一下就完了（然后测试人员测出问题，他们还有一句经典的话，“在我的机器上是没问题的”），然后依赖人工 Exploratory Test，按一些统计来看，这种测试方法覆盖率仅 15-20%，一不小心引发线上系统的致命漏洞问题，所以在产品变得复杂的时候，这种全部依赖人工才是真正的浪费时。结果就常常就引发了全员加班改 Bug，常常很多时间去找问题所在。长期的结果，对技术完全没兴趣，对工作仅仅应付老板。
一般项目只要超过三个月，写测试的收益就可以收回，开始阶段你可能会认为花了太多时间去做基础，没有将注意力转移到业务上来。如果长期的产品开发，到了半年的时候，你的产品已经上线一两个大版本，有一定种子用户，每次上线必须保证兼容性，这时候你就会发现，在项目初期，投入几周去重点做 Insfrastruture （定制一系列产品发布自动化流程 Pipeline 脚本）有多么重要。只有平时写代码花时间积累足够的测试，每次修改都通过 CI Replay 去验证所有的测试场景都不会因为代码变更而罢工，在产品进入相对平稳的阶段，才可以做到真正意义上的省人省力。 |
 |
24
uxstone 2020-07-12 17:53:56 +08:00 1
说到小程序 IDE, 特别想吐槽下
能不能不要在我的用户目录下创建那么多的隐藏文件夹 ！！！！ 配置文件啥的都统一到一个隐藏文件夹下很难吗？？？？ |
 |
26
abcbuzhiming 2020-07-12 20:50:48 +08:00
@hantsy 赶工期才不是借口，你要是在国内呆的足够多的地方，就会明白技术实施依赖于组织框架，很多问题的根源指向老板，不是你技术人员想的那么美好
|
|
27
utodea 2020-07-12 22:06:46 +08:00 1
@wenlele 一次性功能其实在电商的活动类应用中挺多的，比如只是在某次大促的玩法非常业务化，这种功能做成配置化的成本又相对较高，很多时候这种功能只需要集中精力一两个小时就搞定了。
很多时候这种功能其实开发自己是知道沉淀不出来什么东西的，甚至很多团队是把这种功能集中放在一个独立的应用上，便于不影响核心功能，这时候基本就是开发做完功能自测没问题就提交给测试来测了，很少写单测；而 CR 就完全看开发自己有没有信心了，如果你自己觉得不放心就在测试测完后再提给有空的人来帮忙看看。 |
 |
28
az22c 2020-07-12 22:34:21 +08:00
我要是楼主，连面试机会都没有。楼主的确很厉害
|
 |
29
1010543618 2020-07-12 22:43:23 +08:00
说到开发规范最近能力才够参与一些被广泛的使用的项目，发现为开源项目贡献代码和产出公司的业务代码差距真大啊。
终于体会到什么是提交完代码可以去吃饭回来还没跑完测试，比如 jsdom 只跑一部分 https://github.com/web-platform-tests/wpt 的测试就得半个小时。。 |
|
30
1010543618 2020-07-12 23:11:11 +08:00
可能我接触的行业比较少，感觉做项目 /外包的都是几个人就能做 1 产品、1 UI 、1 前端 、1 后端，大的也就加上一两个前后端、加个测试，小的就去掉 UI 直接前端开搞，产品也去掉直接开发对需求。
有的东西只能内网搞，内网最多有个 Git 。能外网搞的项目想上 CI/CD 直接给你 Jenkins 的账号自己配，中间用什么技术也没太大的限制后来的人能上手就行，写不写测试没有要求，代码基本不用考虑合并也不用审。后端倒是可能有时候会有数据量很大的时候，但不管用什么技术能解决就好。感觉主要还是因为有的地方的需求就只是想有录入数据的地方，有一些页面并且上面有真实的数据，稳定性要求不高，有 bug 也能容忍，别出致命的问题就行。 但这么搞有一点恨不能忍，就是出了问题总得有人背锅，没有运维和测试锅就直接穿到开发头上了。 |
 |
31
KunMinX 2020-07-13 00:26:58 +08:00
谈谈自动化测试：在回归测试上的效用比较高，因为总不能改一个功能，全部人力从头穷举一遍。
|
 |
34
jethroWush 2020-07-13 14:29:09 +08:00
赶工期当如果是商业行为也就算了，当它称谓政治行为那就是不可抗力了
|
 |
35
zhouyg 2020-07-13 19:17:23 +08:00
小程序 ide ？又卡又难受，求快速优化
|
Select Language