【外评】我对 The Clean Coder 的看法
简介
前段时间,我一直在寻找一本与软件相关但不纯粹是技术性的书籍,这样我读起来会更轻松。我想找一本即使下班后工作再忙也能乐在其中的书。
在查看了 Goodreads 的待读列表后,我决定阅读The Clean Coder(代码整洁之道),并立即开始了阅读。这本书的简介吸引了我,我最终读完了这本书。
说明一下,这篇文章不是一篇评论。关于这本书的评论已经有很多了。这篇文章只是我对一些特别有趣或有争议的话题的一些想法。
不惜一切代价说不
对于软件工程师或经理来说,经常会遇到产品经理或利益相关者在没有足够时间或资源的情况下要求在截止日期前完成任务的情况。在这种情况下,我们中的很多人,包括读这本书之前的我,都会回答 “我会尽力”。
但这种回答会让人产生一种期望,而这种期望可能与任务可能无法在截止日期前完成的现实不符。这样一来,我们就经常加班或在周末工作,承担了很大的风险,我在管理逾期任务一文中对此有更详细的阐述。
鲍勃大叔(Uncle Bob)在第 2 章中指出,你必须不惜一切代价说 “不”。说 “好吧,我试试 “是不合理的。然而,有时决定已经做出,你无法改变。在这种情况下,我认为更务实的做法是尽可能地与你的经理或利益相关者沟通。他们可能对技术细节有一些不正确的假设。在此之后,作为工程师,我们应该努力寻找并提供替代方案,以在截止日期前完成任务,即使这意味着要少走弯路。要说明的是,我所说的 “偷工减料 “并不是指减少单元测试的编写或粗心大意地部署。
了解基础知识
随着时间的推移,软件工程的抽象程度越来越高。随着抽象程度的提高,了解本领域基础知识的必要性也大大降低。如果你有计算机科学背景,那么你已经学习过其中的大部分知识,但如果你来自其他领域,那么你很可能会错过一些知识。
虽然我学的是计算机工程,但我已经忘了很多,有时只记得标题。
但阅读或复习它们仍然很重要。尽管我们的领域每年都会出现数百个新创意,但我们仍然可以通过强化计算机知识肌肉来提高我们的思维和创造力。也许在你的余生中(除了在面试中)都没有必要使用新的人工智能工具来实现合并排序,但合并排序背后的理念依然有效。
鲍勃大叔(Uncle Bob)推荐了一份每个软件专业人员都应熟悉的领域清单:
- 设计模式。你应该能够描述 GOF 书中的全部 24 种模式,并对 POSA 书中的许多模式有所了解。
- 设计原则。您应该了解 SOLID 原则,并充分理解组件原则。
- 方法。应了解 XP、Scrum、Lean、Kanban、Waterfall、Structured Analysis 和 Structured Design。
- 学科。你应该实践 TDD、面向对象设计、结构化编程、持续集成和结对编程。
- 工件:你应该知道如何使用UML、DFD、结构图、Petri 网、状态转换图和表、流程图和决策表。
通过做这些练习,我们的计算机肌肉会变得更加有力,我相信在我们职业生涯的某些阶段,这会对我们有所帮助。
在家练习,在工作中表现
我记得在我的职业生涯中,有一段时间我在工作中没有学到多少东西。我很苦恼,认为这一定是短期问题,于是我试着自己学习。我读了一些书,做了一些副业,比如《探险日记》。虽然我的想法可能并没有错,但 “在家实践,在工作中表现 “的理念改变了我的心态。
鲍勃大叔(Uncle Bob)把程序员比作音乐家。音乐家在训练和在家时总是练习学习新东西,而在音乐会上表演时,他们使用的是自己的知识和技能,并不指望学到新东西。作为程序员,我们应该在工作中运用自己的知识,而不要指望雇主提供学习机会。如果他们提供了,那很好。但我们不应该期待,因为他们已经为我们的工作支付了报酬,他们没有责任教我们。
这改变了我的想法,因为现在,如果我发现自己在目前的工作中无法学到东西,我知道这不是雇主的责任。这是我的责任。接受了这一点,我就能在不抱怨的情况下做出更好的决定。我可以做副业,看书,甚至换工作。
了解你的产品领域
书中讨论的另一个有趣的话题也提醒了我,那就是了解我们团队、项目和公司的领域。开发人员为产品编写代码。通过了解产品领域及其衡量标准,我们可以更容易地与产品人员和利益相关者合作。这让我们有能力为产品做出更好的权衡和长期决策。
鲍勃大叔(Uncle Bob)建议,在加入一个团队时,你应该阅读一些书籍、与专家交流或与客户交谈,以便更好地了解该领域。
根据我的经验,产品负责人和经理更喜欢与那些了解领域并能帮助他们做出更好决策的开发人员合作,而不是那些什么都接受、像编码机器一样的人。这对每个产品团队来说都是巨大的好处。
结论
The Clean Coder(代码整洁之道) 是一本简单易读的书,我非常喜欢。虽然有些部分我并不完全赞同,但它为我提供了新的、有帮助的内容。
如果你是职业生涯的初学者,阅读这本书肯定会对你有所帮助。如果你是一名经验丰富的编码员,有些主题你可能仍然感兴趣。
本文文字及图片出自 My Thoughts on The Clean Coder Book
你也许感兴趣的:
- 【外评】15 年前我给自己的一系列编程建议
- 【外评】软件复杂性的三大法则(或:为什么软件工程师总是脾气暴躁)
- 【外评】我为什么编程
- 【外评】我们应该将编程法则视作谚语
- 【译文】40 亿条 if 语句
- 现在开始,把代码里的 else 丢掉!
- 程序员提交 PR 的理想长度是多少?有人答:50 行代码!
- 别再说 “技术债” 了!
- 经历多次重写,苹果平台最强科学计算器PCalc背后的故事
- 世界级编程大师Bob 大叔为“干净代码”辩护遭质疑:时代变了,别用Clean Code那套要求我们了!
你对本文的反应是: