后端技术面试 38 讲
李智慧
同程艺龙交通首席架构师,前 Intel& 阿里架构师,《大型网站技术架构》作者
37373 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 46 讲
不定期加餐 (1讲)
后端技术面试 38 讲
15
15
1.0x
00:00/00:00
登录|注册

10 | 软件设计的目的:糟糕的程序员比优秀的程序员差在哪里?

分享糟糕代码的体验
设计原则和设计模式
需求变更导致代码腐坏
晦涩性
粘滞性
牢固性
脆弱性
僵化性
对待需求变更的态度
应对需求变更的能力
程序设计能力
编程能力
糟糕程序员导致项目失败
优秀程序员产出高100倍
思考题
解决之道
一个设计腐坏的例子
糟糕的设计特点
软件设计的关键差别
程序员的好坏体现在
优秀程序员 vs 糟糕程序员
软件设计的目的

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

有人说,在软件开发中,优秀的程序员比糟糕的程序员的工作产出高 100 倍。这听起来有点夸张,实际上,我可能更悲观一点,就我看来,有时候,后者的工作成果可能是负向的,也就是说,因为他的工作,项目会变得更加困难,代码变得更加晦涩,难以维护,工期因此推延,各种莫名其妙改来改去的 bug 一再出现,而且这种局面还会蔓延扩散,连那些本来还好的代码模块也逐渐腐坏变烂,最后项目难以为继,以失败告终。
如果仅仅是看过程,糟糕的程序员和优秀的程序员之间,差别并没有那么明显。但是从结果看,如果最后的结果是失败的,那么产出就是负的,和成功的项目比,差别不是 100 倍,而是无穷倍。
程序员的好坏,一方面体现在编程能力上,比如并不是每个程序员都有编写一个编译器程序的能力;另一方面,体现在程序设计方面,即使在没有太多编程技能要求的领域下,比如开发一个订单管理模块,只要需求明确,具有一定的编程经验,大家都能开发出这样一个程序,但优秀的程序员和糟糕的程序员之间,依然有巨大的差别。
在软件设计开发这个领域,好的设计和坏的设计最大的差别就体现在应对需求变更的能力上。而好的程序员和差的程序员的一个重要区别,就是对待需求变更的态度。差的程序员害怕需求变更,因为每次针对需求变更而开发的代码都会导致无尽的 bug;好的程序员则欢迎需求变更,因为他们一开始就针对需求变更进行了软件设计,如果没有需求变更,他们优秀的设计就没有了用武之地,产生一拳落空的感觉。这两种不同态度的背后,是设计能力的差异。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

软件设计的关键在于应对需求变更的能力。优秀的程序员应该具备良好的设计能力和对需求变更的灵活态度。糟糕的设计和代码会导致软件的僵化、脆弱、牢固、粘滞性和晦涩性,从而影响软件的可维护性和稳定性。为了改善这些问题,人们总结了设计原则和设计模式,以提高软件的灵活性和强壮性。在软件开发过程中,需要不断重构代码,保持对需求变更的灵活性。文章强调了设计原则和设计模式在软件设计中的重要性,以及如何应对需求变更和保证软件质量。通过接口抽象输入和输出,可以使程序更加灵活,易于维护和扩展。在面试中,考察候选人的编程能力和技巧时,设计原则和设计模式是重要的考察点。最后,文章提出了思考题,鼓励读者分享自己在软件开发实践中遇到的问题和经验。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《后端技术面试 38 讲》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(30)

  • 最新
  • 精选
  • LA
    看吐了是真实,之前接触过一项目,因为银行的某些原因做了分包,拆分为互联网区和 xxx 区。 新需求看起来挺简单,走 OAuth 授权用授权码换用户信息,返回的数据里面屏蔽几个字段,刚开始用 idea 全局搜索 /oauth 打头的文件定位后,修改、发布测试、测试,看起来很乐观,很简单,但测试一跑数据不对,日志文件显示也改了,最后定位发现他们分包用文件复制方式,一份相同的实体问题在多个地方都有,你只要改了一个点,所有问题必须硬编码改。 人总是想往好的方向发展,读优秀代码,看优秀开发的相关思路和实现是良性有成长的,看垃圾代码,最后就是抱怨,怀疑人生,甚至变态。

    作者回复: 🤗

    2022-07-19
    3
    2
  • 席席
    老师,改造后的打印您是不是没有写纸带机打印的实现类,如果写的话应该是再创建一个纸带机读取类实现读取接口,和一个纸带机输出类实现输出接口。然后最终达到了在别人调用时接口以及类和方法便易于被理解的效果嘛?但我觉得在实践中很少有人会将一个方法写成6个类,因为功能的拆解与抽象似乎边界也很难界定。工作时间上也很难把握。

    作者回复: 我们努力学习更好的技术就是为了提高实践呀~

    2020-06-29
  • Paul Shan
    僵化性代码的例子是滥用了继承,导致添加一个小功能,所有的基类和派生类都要修改。 脆弱性代码的例子是引入全局依赖,导致意外的修改扩散。每当我看到很多全局变量的时候,对程序的掌控感荡然无存。 牢固性代码的例子是超大类,由于类内部是可以任意访问,所有的巨量函数和属性组成了一个巨大完全图,牵一发而动全身,根本不知道从哪里下手。 粘滞性代码的一个例子还是全局变量,大家觉得觉得用得也挺顺手的,还有人说重用这些能提高效率,让我也很无语。有了注入依赖以后,这些全局变量被包了一层外衣,到处泛滥而不可收拾。 晦涩性代码的例子是过多if语句,一开始可能还好,最后if越加越多,导致看完都成问题。
    2019-12-13
    3
    62
  • 不记年
    差的程序员总是用行动的勤奋来掩盖思考的懒惰
    2020-02-01
    2
    43
  • 难得糊涂ck
    A:可以说脏话嘛? B:不能。 A:那我没什么好说的
    2019-12-13
    15
  • 一路前行
    a丨b丨c 之前看到过一个这样代码段子,请将这个字符串切分开。一个人一天调了很久没调出来,最后发现“丨”这玩意竟是个汉字。
    2020-05-12
    7
  • 杯莫停
    说起僵化性的代码我就不得不吐槽我的前同事,离职后我接管了他的任务。我估计他就是实在怕以后的bug成堆才赶紧甩锅走人的。设计一个业务稍微复杂的功能,他一个方法写了将近两千行。一个类几千行代码,我用编辑器打开都卡。最近需求变更,差点没把握逼疯。要重构嘛,已经上线了,工作量也有点大,而且不止到还有没有其他坑。
    2020-08-18
    1
    6
  • 观弈道人
    想了解下智慧老师是如何提问考察应聘者编程能力和编程技巧
    2019-12-13
    2
    6
  • 米亮
    感觉这种情况会恶性循环,第一家公司尤为重要 那么糟糕程序员诚然有自己的原因,大环境下的各公司开发氛围良莠不齐我感觉才是主因
    2020-04-04
    3
  • 虢國技醬
    1. "你开始犹豫是不是需要跑路了" 过于形象 😂 2. 其实很多时候当我们因为需求变更的时候,我们更够感觉到代码正在变坏,好的做法应该是关联地方整体考虑重构; 3. 可是有时候有些业务代码真不知道怎么重构,就是一条逻辑,可以抽重来短小的方法,但是却没有别的地方能够重用,这种真实很纠结,不抽出来逻辑太长,不清晰,抽出来吧又没有别的地方重用
    2020-01-14
    2
收起评论
显示
设置
留言
30
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部