C 不是一个 OO 语言，所以不存在“Array 对象”、“Stream 对象”。“流”是一个典型的 OO 概念，在传统 C 里是没有这种抽象的。

C 的思维： 数据都在内存里了，都能随机访问了，还套都一层函数干啥，吃饱了撑着？

@speculatorA 拿份工资跟帮其它成员考虑一步冲突吗？ 是不是拿份工资=有啥写啥，拿份股权=缺啥写啥，拿个公司=谁给钱做啥就做啥？


为什么“拿份工资”就不能缺啥写啥？

这就是 ptsd 。。

绝望感是错觉。

/t/581133 #255
/t/495443 #70
/t/570928 #13
/t/581133 #65
/t/490763 #4

讲流程没用，流程得有基础设施
我给你讲一下我们 30 人的团队都有哪些基础设施

- CI，不提，大家有手都会用

- 产品基础平台，包含前端和后端的一部分组件，由设计师直接管从出图到验收的全部分，从按钮文字到列表对话框动画等一系列 UI 都由它定义好，各产品的交互定义一律以基础平台为准，所以绝大部分页面不需要高交互原型，有没实现的特殊交互产品先跟设计沟通定成通用方案，做好后再引用，只有极少数 UI 是产品特有，则设计额外给设计稿。这个项目有一个几个人（含设计师）的小团队维护

- API 生成器；我们主要用 golang，有一个把 golang 特有形式 API parse 并输出对应前端使用的 (ts) 接口函数的编译器，CI 上会有 check 来保证 server golang 代码和 ts 始终能一一对应。这个 parser 项目由公司各个产品组的核心资深研发共同维护。

- jira 记任务，confluence 记 sprint 文档和任务汇总，并且与 gitlab 三方相互集成，在 gitlab 上的 mr 会自动创建任务的 weblink，保证每期迭代每个任务每个 mr 都是能相互关联复查的。各个内部系统的相互集成和二次开发，又有一个小团队专门开发维护

- 原型是放在 gitlab pages 上的，所有人都能随时检查，如果看不到则这个需求不会进入研发阶段，并且由于一直在线所以任何人随时都可以提出争议，无争议了才会通过评审

- 应急的时候我们的产品经理前后端代码能自己写，数据库能自己远程上去调试，哦不如说他还是核心研发角色之一










*其它的流程基本跟你描述的流程一样

通常是因为 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 之前都还跑得挺好的。团队大了之后必须向理想妥协