- 主题:碰上能力低的下属真消耗啊，有什么管理的好办法呢？
re
感觉都没做过开发的样子
没见过小白把库搞崩了要手动修的吗
嘴上都说架构要解耦合弱耦合 模块崩了不能影响全局，管理要合理分割工作 关键代码不能让能力低的上，世上都是这么纯粹的业务就好了，那还要这么多码农有啥用
【 在 expexp 的大作中提到: 】
: 这楼里都是做过开发的吗？咋感觉好多人就那么不接地气呢？还是码农也相轻？
: 一个小BUG可能影响一大片不是很常见的吗？
: 要不就是在国际大厂里干的？每个人只写自己每天都写的那些代码，每个岗位上还有冗余人员可以互查？
--
FROM 111.198.57.*
张嘴闭嘴就是解耦合的，明显没参与过项目
业务发展的不确定性带来的耦合你拿头去解？真当架构都是圣人啊
龟板都是在大厂呆惯了，过惯了一个小team几十上百号人还都是精挑细选留下来的富裕日子啊
【 在 freyoneby 的大作中提到: 】
: 明显沒见过好的东西，中间件估计都不知道，现在都是ubus，DBus解耦合，根本不存在复杂相目
: - 来自「最水木 for iPhone 7 Plus」
--
FROM 111.198.57.*
当然应该考虑，但是谁能保证最开始设计的架构到后面业务需求不会变？业务变了真的还能保持低耦合吗？
重点也不在这，重点在一个人埋了个bug 花一两周去擦屁股不是很正常的事请么？到了龟板就成了架构的锅管理的锅了？贵版的水平真是比微软都不知道高到哪里去了
【 在 chunhui 的大作中提到: 】
: 我觉着在任何地方解耦都是必要要考虑的。除非是那种所谓只看结果不懂技术细节的kpi导向：
: 时间太紧了，先这样吧...
: 情况复杂，只能先如此了...
: ...................
--
FROM 111.198.57.*
是了是了，贵司真是比微软都高到不知道哪里去了
【 在 freyoneby 的大作中提到: 】
: 你是小作坊的吧就别来参和了，业务量诂计是大厂的九牛一毛，大厂发货量都是几十亿，千分之一概率出bug都受不了，出差到现场去搞？客户需求各式各样，真是沒见过世面
: :
: - 来自「最水木 for iPhone 7 Plus」
--
FROM 111.198.57.*
是是是你说的都对，下次不用说了
回去重读语文吧
【 在 freyoneby 的大作中提到: 】
: bug一旦爆出来花一两周，你断网一两周试试，客户不让你赔惨，以为都和你一样做得东西无关紧要，出了问题也不用赔钱。设备全部退回，现场重新部署回老设备，一年利润全部赔完，高管直接下台
: :
: - 来自「最水木 for iPhone 7 Plus」
--
FROM 111.198.57.*
就很奇怪，你们为什么有一个前提条件就是，他埋的bug 现象一定发生在他自己的模块里？为什么能假设模块与模块之间有强运行时的隔离机制？
没写过c/c++吧？没遇到过性能瓶颈吧？
【 在 chunhui 的大作中提到: 】
: 你没看见lz的前提条件么。他说的是能力不行的那个人埋的小bug。难道他们那里所有人都把代码写在一起。也不分个模块和结构么？如果这个都没有，那当然就是管理的问题。
: 甚至可以这么说：所有问题，都是管理问题。
:
--
FROM 111.198.57.*
来我给你举个例子：
小A的工作是给其他人提供一个c实现的接口，这个接口根据传入的参数返回一个函数指针，供其他人使用。结果由于小A没有完善处理他内部的一个数组的越界检查，导致在某种特定的输入条件下，应当被返回的函数指针地址0x12345678的一个字节被擦了，变成了0x12345689，结果错误的指针指恰巧向了另一个与期望的函数接口相同功能类似但行为略有不同的函数入口。结果最终偶发地在一个八竿子打不着的功能上炸了。
再来个例子：
小B是个crud boy，就负责一个落库的逻辑，结果犯了一个低级的thread unsafe的错误没有被单元测试抓到，偶发的错误导致落库的数据错了，只能根据系统的log重新修复数据库
你要花多久去擦这种屁股？你作为一个架构怎么完全避免这种问题而不引入新问题？解耦就能避免这种问题了？那公司招人的时候还设置什么专业门槛，随便招个阿猫阿狗来不都没什么差别？
【 在 chunhui 的大作中提到: 】
: 没人说一定在他的模块中。这就是你搞不清楚耦合架构的原因。
: 这不只是程序上的问题，这和组织方式有关。
: :
--
FROM 111.198.57.*