程序员进阶攻略
胡峰
京东成都研究院技术专家
33679 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 65 讲
蜕变:破茧成蝶 (3讲)
结束语 (1讲)
程序员进阶攻略
15
15
1.0x
00:00/00:00
登录|注册

50 | 技术分歧,如何决策?

作者的特定环境下的技术决策
康威定律
作者经历
在受限的约束条件下,围绕成本与效率做出选择权衡
政治决策,与博弈与利益有关
决策原则与成本效率有关
团队、环境、技术、约束
最大化团队核心能力,最小化沟通成本
作者案例:简化代码移到数据库函数中
数据删除与存储
设计模式
经典的关系数据库表设计原则
追求技术的完美与合理性,但现实需要更多的行动柔性
适合的技术决策在受限的约束条件下做出的选择权衡
技术没有绝对的标准
技术决策
非纯粹部分
技术决策的纯粹部分
技术方案决策的核心
康威定律
适合的技术决策在相对条件下做出
大规模分布式领域与反范式设计
技术并非绝对客观
总结
原则
相对
绝对
技术分歧,如何决策?

该思维导图由 AI 生成,仅供参考

作为一名程序员或技术人,总会碰到这样的场景:在一些技术评审会上,和其他程序员就技术方案产生分歧与争论。如果你是一名架构师或技术 Leader,站在技术决策者的立场和角度,该如何去解决分歧,做出决策呢?
这背后,有什么通用的方法和原则吗?

绝对

曾几何时,我以为技术是客观的,有绝对正确与否的标准判断。
在学校我刚开始学习编程技术时,捧着一本数据库教材,它在述说着经典的关系数据库表设计原则:第一、第二、第三范式。后来,我参加工作,那时的企业应用软件系统几乎都是以数据库为核心构建的,严格遵守范式定义的表结构。所以,当时觉得所有不符合范式设计的应用肯定都是错的,直到后来进入大规模的分布式领域,碰到了反范式设计。
也还是在学校做课程设计时,一起学习的同学总跟我讨论设计模式。一边写代码,一边研究这个代码到底符不符合某种模式,似乎没有套进某种模式中的代码就像没有拿到准生证的婴儿,带有某种天生的错误。直到后来,我碰到了反模式设计。
刚工作不久,同事和我讨论当用户删除自己的数据时,我们到底应不应该删掉它?我那时觉得理所应当写个 Delete 的 SQL 语句把它删掉。因为当时是这么想的:既然用户都不要他的数据了,我们还把它保留下来做什么呢?不是浪费资源嘛,而且服务器存储资源还算挺贵的。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文以程序员和技术人员的视角,探讨了技术决策的相对性和康威定律的应用。作者分享了自己在技术决策上的经历和思考,强调了技术决策的相对性和适用性。文章通过讨论数据库设计原则、设计模式、数据删除等案例,阐述了技术决策的相对性和适用性。作者以自身经历为例,说明了技术决策的相对性和康威定律的应用。文章深入浅出地阐述了技术决策的相对性和康威定律的应用,为读者提供了有益的思考和启示。 文章强调了技术决策的相对性和适用性,以及康威定律在技术决策中的应用。在足够大的组织中,沟通成本已经是一个足够大的成本,有时可能远超采用了某类不够优化的技术方案的成本。每一次人事组织架构变动的背后,都意味着需要相应的技术架构调整去适应和匹配这种变化,才能将沟通成本降下来。而技术方案决策的核心,围绕的正是关于方案的实施成本与效率。在技术的理想世界中,技术决策的纯粹部分,其决策原则都和成本效率有关;而其他非纯粹的部分,其实都是“政治”决策,没有所谓通用的原则,只和博弈与利益有关。 总的来说,技术没有绝对的标准,适合的技术决策总是在受限的约束条件下,围绕成本与效率做出的选择权衡。文章通过案例和作者经历,深入浅出地阐述了技术决策的相对性和康威定律的应用,为读者提供了有益的思考和启示。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《程序员进阶攻略》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(12)

  • 最新
  • 精选
  • 公号-技术夜未眠
    技术决策无关乎是非对错,但是存在合适与否。 技术决策的确是成本,效率,质量,政治综合博弈的综合结果。所以在实践中会对上述进行优先级排序。 在决策考虑的因素方面,优先级是由以下几个方面所决定:不同的组织环境(传统与扁平化),所开发的不同的软件系统(业务系统,用户产品,中间件等),约束性条件(团队的人力与技术储备,开发与运维环境条件,进度等)。 形式上一般会是一主两备(第三选择),先民主后集中,在讨论各种中大家充分表达意见,但是最后还是需要技术团队的老大拍板,避免议而不决;原则上采用遵循简单,合适,不断演进的思路;最终决定了大家就统一行动。 技术决策很重要,会花费一定的时间去做讨论与取舍。这个时间是值得的,越是越早发现问题,其后期的成本消耗就越少,磨刀不费砍材功,应该就是这个道理。

    作者回复: 理解了博弈,就没那么多纠结了😄

    2018-11-27
    8
  • 汪玉斌
    就算有好的,新的解决方案,实施的过程不能贯彻好,最后也很坑。 解决方案的评估需要和团队的情况结合!不只是技术上的事,还有成本和团队效率。

    作者回复: 嗯,需要多维全面的考察并平衡

    2019-04-04
    2
  • hua168
    大神能分享一下你的自学方法吗?为了提高视频学习的速度,我是不是不截图直接一次去看过,然后就按着记忆去练习写代码?不截图的话又感觉忘的很快,学习完一章之后,我简单做个笔记会好一点?还是直接看书来得更快一点?我的学习方法效率太低,花大量时间得到的是入门级的技能。

    作者回复: 只能照着视频写代码是不够的,或者你搭配个入门级书籍,要消化教程样例代码,举一反三

    2018-11-26
    2
  • hua168
    大神,我想请教一下一个关于自学的问题,我自学习惯一般是这样的: 1.去下载过购买视频,利用业余时间或周末学习,学习时边看视频边截图,周一到周五上班有时间就敲代码 2.再找下有什么相关的书,简单看下 这样造成了: 1.看视频花时间太长,1小时视频得花3小时才搞完,截图,打字 2. 视频比较简单,讲得不深入,所以找书看下,外看下spring官网哪些更新。 3.发现了,学完了没经验,而已水平也是视频教入门的程度 疑问: 我总觉得好像自己不是这样的,怎么提高学习效率,深入这,找经验?

    作者回复: 视频学习的局限就在这,估计大部分视频教程都是入门用的。还需要自己把技术用在实践中去磨练,编程是实践的技术和艺术。想一个真实的场景和真的有个问题,再用技术实践去解决

    2018-11-26
    2
  • 亚林
    旁边的波波老师也提到了康威定律

    作者回复: 想成为架构师的程序员都需要知道这个定律😄

    2018-12-23
    1
  • 我们会先讨论,如果能定下来就定,如果还存在分歧就找相关方及架构师,让架构来定,到这基本能定,还有些方案都行的情况就有自己来定了,leader只关心结果。能搞定就行,不管你怎么弄的!

    作者回复: 😂Leader也太high了

    2018-11-28
    1
  • Ripper
    中国特色社会主义道路😃
    2019-06-24
    1
  • third
    决策的本质是总成本最小,总收益最大。 但是个体和群体的收益和成本可能正相反。 康威定律。 所有群体在设计一套方案时,所提交的系统方案在结构上都与该组织的沟通结构保持一致。 成本与效率背后的考量 团队:人 环境:能利用的环境支持 技术:技术的成熟度和发展趋势 约束:
    2018-12-15
    1
  • 猴子警长
    就像两人合作砌一堵墙,中间的交界处总要有人多做一些
    2021-06-08
  • Sch0ng
    分歧的产生来自双方或者多方利益不一致。 参与竞争合作的个体,都是趋利避害的。 PK的时候重点要找利于己方的公理,可以很发散的找,大到这是OKR目标,小到这是最佳实践。 反正没有统一答案,也没有法律条文规定,言之成理即可。
    2021-03-01
收起评论
显示
设置
留言
12
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部