通常是因为 makefile 的依赖没写好导致并行编译了互有依赖的过程

比如本来 A 依赖 B 编译时自动生成的配置，B 没编译时用占位数据来代替，这样就并行就会编译出不正常的 A

为什么你能确认这个局面是平台在操纵
而不是人性本来就如此？

@ajaxfunction 最好别跨领域挑战别人的饭碗

一个网站日流量 100 与这个网站后台包含 100w 人的信息之间没有任何因果关系
你的网站哪怕只是有一个可遍历账号公开信息的接口，那也可能存在着整站所有注册用户全部实名信息泄露的风险。因为可遍历信息意味着有撞库的可能，可撞库则可登录，可登录则有鉴权，有鉴权则很可能可跨业务查询自己的实名信息

不搞安全，你自认自己有这样的直觉和意识吗


说句不好听的，搞安全的，路过这种 pv100 的小破站哪怕直接能扒得底裤都不剩也没有挖出大厂一个犄角旮旯的业务微不足道的 xss 有成就感。因为可能这个 xss 能让这个大厂给他发实物奖励让他发在朋友圈炫耀，但小破站往往只会出来一个不懂装懂反手无威胁+报警的骚操作运维让他吃不了兜着走

lz，漏洞公开时间和流程是平台规定的。如果平台提早公开，是平台的问题，如果提交者未经平台披露自己先行公开，那他确实不受保护，可以予以追责

@tocherrygo 平台是提交人的保护者，事实上是平台在担保漏洞修复-公布流程的合法性和保密性

设想一下如果漏洞研究者直接提给厂商，厂商一边修复一边先送了奖励然后反手把研究者送公安那去破坏计算机信息系统罪+起诉敲诈勒索，他有什么自保措施么？完全没有

提交给平台，平台审核测试合法性、保证通知-修复-公开流程的完善性、担保厂商的修复奖励真实有效，这样研究者才有可靠合法的施展空间

平台直接公开了漏洞，那是平台有问题，你为什么会想到解决研究者？

我们目前的实践（ gitlab EE ）：
- protected: master 、R-*
- 开发分支随便开，命名要求由 ci 维护者制定，但不做特殊要求。这条的意思是，我可以写前端 check 只在 fe/*分支上跑，那么自然所有的前端 feature 都需要带 fe/前缀
- 设置自动发布环境的 CI，T-* 分支会自动执行发布脚本发布到测试环境，意味着你想要做前后端集成测试，必须把 fe/*分支和 be/*分支都 merge 到一个 T-* 上，由于 T-*分支不设保护，所以任何人都能进行 merge 操作，方便前后端联调
- 规定 R-*和 master 分支只允许从 T-*分支合并，由于分支受保护，因此仅有 maintainer 可以合并，他们可以拒绝不合规的 MR;同时这些 MR 信息必须使用模板，填写相关看板任务并通过 check list
- master 会集中所有主线修改，所有 feature 和修复优先进入 master 。当某个迭代周期结束后，产生该迭代的 release 分支 R-*，并且打上版本 tag 。 R-*分支只接受与该期迭代相关的修改 MR，如 bug 修复，该迭代结束日暂时没做完 delay 掉的 feature 等
- T-*分支的发布使用测试私钥签名，R-*分支使用生产私钥签名（与产品 license 相关）


其实只要用得熟练小团队也可以很完善很自动。一开始这个组三四个人的时候只有 master 、T-*、开发分支，现在全组大概 30 个人，也基本还是沿用以前的流程

顺带一提，你想让我用英语回复的目的是论证哪个逻辑链？

我没有用英语回复->我无法用英语回复->大家都该用中文写代码？

吗？

害 你看看有人理你吗

我翻了你最近好几个帖子的回复，除了拉靶子出来打不知所云的 /t/685792
其它你自娱自乐的主题大家的感受和回复是啥？不用说吧

> 我只听说过前者，没听说过唯独英语好但搞不定其他学科的。各位情况如何？
我高考语文 130 左右英语 120 左右数学 80 左右，当年广东卷是口语 30 分没有听力题的。然后这能说明什么呢？

哪怕全中国人都觉得英语难学，也不存在一个严谨的可得出“所以我们要用母语写代码”的论证过程，在你想推进的领域里也没有什么人关心在意是否能用其它语言编程，大家只需要一个符合直觉的方便的符号体系而已这点你不明白吗


你试图用“义务教育阶段英语很困难”推导出什么进一步结论？不该学？应该用中文写代码？



我再概括一下我之前这段回复的意义：
> 学用英语三十载，不及幼儿园大班——国内英语教学到底是为了什么？
为了给之后需要用英语的人提前准备，就跟学数理化生政史地美乐，一样。

我的回复只包含了对“到底是为了什么”的回应，“学用英语三十载，不及幼儿园大班”这个命题的谬误就不帮你概括其它大多数人回复的观点了，你已经装作看不见了

为什么往一个库里怼不好？ 又不是往一个分支怼

啊。。。 贵前端圈已经慢到一万个字符串就要考虑性能优化的程度了？（滑稽

架构。

软考系统架构师那本书里面基本上涵盖了作为技术创业者需要具备的大部分素质，从编程技术到软件工程方法论。而且系统架构师软考有个难点是基于实际项目经验的现场论文。如果能考过去那基本上管团队也会了，商务部分可以找其它合伙人或者再学其它课程，这部分另说

@hantsy 老哥你是不是不管团队也不需要在客户销售老板研发中间 4 方受气。。

研发和产品岗都呆过，所以深知推行起来有多难。研发这一侧可能理想很好，把需求都挡在外面，团队内部按部就班。

但地球不是这么转的，现实情况因果依赖是反的。销售浑身解数把你做了 1 的产品吹成了 10，客户同意验收 3，现在你是产品，是项目管理，你有的选吗，没得选。你只能赶紧用尽量短的时间把没做完的 2 赶出来，不可能不干了让友商看你笑话一边接盘一边挖你的人一边嘲讽你是傻逼，这很残酷的事。

即使在这种情况下我们还是走完了发版流程，还是保证了单测覆盖率，还是跑完了全 feature 回归测试；但 —— 不可能一切都这么顺利对吧

scrum 是一个不错的模型，但它是理想化的，我们肯定要有修改的地方。讨论推进采用敏捷模型的时候，你自己就是要介入的管理层。你就是要亲手去解决你发现的问题，为什么说得好像自己置身事外“那是别人的事”一样？

我们有 ci/cd，有 codeowners 和交叉 review，有看板、需求和缺陷生命周期管理、sprint 和版本发布管理，有站会、集体 bug review，产品不是自己的在线业务所以没有运维过程但有自动化的单元测试、发版流程固定的集成回归测试环节。但我们仍然不是很敏捷，一个是前面提到的研发素质和客观属级存在会阻碍完全扁平化的敏捷模式理想，一个是对于文档和临时 feature 产出的需求会打断理想工作流，甚至迫使整个团队做一些完全不敏捷的事情去满足交付目标（ 2b 产品）。还是那句话，scrum 真就只适合小而美的团队。在我们几个 codeowners 没有感觉到人手不足而招进来一批实习生和相对低端的 crud boy 之前都还跑得挺好的。团队大了之后必须向理想妥协

@hantsy 说的是落实到具体研发任务的[团队]。整个 MS 不可能只做一个产品一个项目对吧，最终每个项目都会拆分落实到那么几个人十几个人 的小团体上。而在国内来说，可能是个几十人的小团体。可以想象一个人带 5 个实习生、两三个后端一人给所有产品写中间件、一人写业务 CRUD 、一人写算法，这样的团队开个站会你能指望增进什么样的交流？ 3 个人负责方面互不交叉怎么安排相互估时和 review ？

“这是管理层的问题”。是的，我在说的就是管理层面的困难带来的水土不服

1. lz 误以为同一行政等级的不同站点是同一系统在管，然而并不是，不同行政等级、不同系统单位、甚至不同分属部门的站点和信息系统都有自己的管理维护体系。你甚至说不清某个县级单位的站点到底是市属分支机构在管还是某个外包在管
2. 误以为机关单位只运维.gov ，然而也并不是，政务 app，域名接 gov 吗？健康码，域名接 gov 吗？这可说不准。非 gov 域名，重名率有多高不用说吧
3. 误以为英文表达的域名重名率低且精简，但事实上国外机构单位都让你一头雾水 cgifederal.secure.force.com ustraveldocs.com 这两个站关系是啥？他们的域名是啥意思，跟它们服务业务有何关联，不进网站能看出来？
4. 误以为那些网站真是给人看给人用的。除了用来给你交钱办事的站，还有一大批做样子、只说不听、只放静态 html 自吹文登录按钮都是假的“宣传用”的小机关站点。给他们取个贴切的英文域名，图啥？

scrum 毕竟还是个理想模型，适用于团队很小，参与者水平都足够开发系统中任何一个模块，不存在上下属级，大家效率都差不多等情况。现实中的团队会有非常多杂七杂八的因素干扰，比如团队成员可能并不只参与一个项目，水平参差不齐上下属级制约、系统设计模块多而导致大家只能顾及自己实现的部分无法交叉 review 等等。而且标准 scrum 模型含有一些执行起来很困难的项，比如 story point 、time estimation 等；还忽略了项目文档（产品文档 /技术文档）这种可能需要集中产出的副产物。所以我们实际研发团队运行模式参考了敏捷模型，但要完全敏捷是不可能的。敏捷模型的最大特点还是持续交付，只要把需求-研发-交付的固定循环周期建立起来，那么项目组的迭代大体上就还是健康的。

@zhongjun96 其实。。。很多团建的契机恰恰是有人要走了。你可能弄反了因果顺序

我会如下回复：

别跟我扯没用的，我现在就 tm 觉得不会找技师最吃亏，陪客户出差人家问我一问三不知那叫一尴尬（夸张口气）哎快给点路子，烟学不学问题不大，先赶紧教教老子怎么约妞