- 主题:碰上能力低的下属真消耗啊，有什么管理的好办法呢？
re
水平低的不可能有机会挖大坑。否则肯定是管理有问题放错地方了
【 在 combo 的大作中提到: 】
: 让能力低的下属写了重要的公共接口？这是领导的问题吧？
:
--
FROM 114.242.249.*
“小”bug一个团队都搞不定
【 在 meiyou2015 (meiyou2015) 的大作中提到: 】
: 你也不是什么好东西
--
FROM 114.249.29.*
我觉着在任何地方解耦都是必要要考虑的。除非是那种所谓只看结果不懂技术细节的kpi导向：
时间太紧了，先这样吧...
情况复杂，只能先如此了...
【 在 eggcar (eggcar) 的大作中提到: 】
: 张嘴闭嘴就是解耦合的，明显没参与过项目
: 业务发展的不确定性带来的耦合你拿头去解？真当架构都是圣人啊
: 龟板都是在大厂呆惯了，过惯了一个小team几十上百号人还都是精挑细选留下来的富裕日子啊
: ...................
--
FROM 114.249.20.*
有道理。很多项目负责的人根本就没有那个自律精神去整理完整的信息，和传递完整的信息。这是懒。要么就根本不懂如何整理和传递完整的信息。这是笨。
【 在 xcty (xcty) 的大作中提到: 】
: 凡是事先不知道bug可能在哪里的，都不叫bug，而叫defect缺陷
: 一个算法里的bug才是bug，因为如果有bug，那么知道bug一定在这几行代码里，但是算法的输入输出定义明确，不需要修改，出bug也不用修改其它地方
: 一个不知道在哪里的bug不是算法的bug，而是系统设计的bug，是因为多模块信息不对称导致的信息匹配失误，也就是如过信息充足完备，写新代码的人是100%不会有bug的。是什么导致信息不完备？比如系统模块耦合、重复代码太多导致事实上的无法100%掌握系统所有可用信息或根本
: ...................
--
FROM 114.249.20.*
你没看见lz的前提条件么。他说的是能力不行的那个人埋的小bug。难道他们那里所有人都把代码写在一起。也不分个模块和结构么？如果这个都没有，那当然就是管理的问题。
甚至可以这么说：所有问题，都是管理问题。
【 在 eggcar (eggcar) 的大作中提到: 】
: 当然应该考虑，但是谁能保证最开始设计的架构到后面业务需求不会变？业务变了真的还能保持低耦合吗？
: 重点也不在这，重点在一个人埋了个bug 花一两周去擦屁股不是很正常的事请么？到了龟板就成了架构的锅管理的锅了？贵版的水平真是比微软都不知道高到哪里去了
--
FROM 114.249.20.*
最后那句话是管理学中的一个常识。
【 在 mageofu 的大作中提到: 】
: 这就像一个人有啥问题，说都是原生家庭问题。
: :
--
FROM 114.242.249.*
没人说一定在他的模块中。这就是你搞不清楚耦合架构的原因。
这不只是程序上的问题，这和组织方式有关。
【 在 eggcar 的大作中提到: 】
: 就很奇怪，你们为什么有一个前提条件就是，他埋的bug 现象一定发生在他自己的模块里？为什么能假设模块与模块之间有强运行时的隔离机制？
: 没写过c/c++吧？没遇到过性能瓶颈吧？
:
--
FROM 114.242.249.*
你不如举这样的例子：有初级选手犯了一个低级的错误，把核弹给发射出去了。
那是谁让这个人去负责发射核弹的？
【 在 eggcar (eggcar) 的大作中提到: 】
: 来我给你举个例子：
: 小A的工作是给其他人提供一个c实现的接口，这个接口根据传入的参数返回一个函数指针，供其他人使用。结果由于小A没有完善处理他内部的一个数组的越界检查，导致在某种特定的输入条件下，应当被返回的函数指针地址0x12345678的一个字节被擦了，变成了0x12345689，结果错
: 再来个例子：
: ...................
--
FROM 114.249.29.*