微信网站是多少钱一年,wordpress书签插件,广西造建设工程协会网站,洛可可#x1f308;个人主页: 鑫宝Code #x1f525;热门专栏: 闲话杂谈#xff5c; 炫酷HTML | JavaScript基础 ​#x1f4ab;个人格言: 如无必要#xff0c;勿增实体 文章目录 【翻译】再见, Clean Code!正文那是一个深夜次日早晨这只是一个阶段 【翻译】再见… 个人主页: 鑫宝Code 热门专栏: 闲话杂谈 炫酷HTML | JavaScript基础 ​个人格言: 如无必要勿增实体 文章目录 【翻译】再见, Clean Code!正文那是一个深夜次日早晨这只是一个阶段 【翻译】再见, Clean Code! 这篇文章翻译于React核心开发者Dan的这篇博客。 原文链接overreacted.io/goodbye-cle… 正文 那是一个深夜 我的同事刚刚提交了他们整个星期一直在编写的代码。我们正在开发一个图形编辑画布他们实现了通过拖动矩形和椭圆等形状边缘的小手柄来调整其大小的功能。 代码能正常运行。 但显得很冗余。每个形状如矩形或椭圆拥有各自不同的手柄集合而拖动手柄的不同方向会以不同的方式影响形状的位置和尺寸。如果用户按住 Shift 键我们还需要在调整大小时保持形状的长宽比。涉及了大量的数学计算。 代码大致如下 let Rectangle {resizeTopLeft(position, size, preserveAspect, dx, dy) {// 10 repetitive lines of math},resizeTopRight(position, size, preserveAspect, dx, dy) {// 10 repetitive lines of math},resizeBottomLeft(position, size, preserveAspect, dx, dy) {// 10 repetitive lines of math},resizeBottomRight(position, size, preserveAspect, dx, dy) {// 10 repetitive lines of math}, };let Oval {resizeLeft(position, size, preserveAspect, dx, dy) {// 10 repetitive lines of math},resizeRight(position, size, preserveAspect, dx, dy) {// 10 repetitive lines of math},resizeTop(position, size, preserveAspect, dx, dy) {// 10 repetitive lines of math},resizeBottom(position, size, preserveAspect, dx, dy) {// 10 repetitive lines of math}, };let Header {resizeLeft(position, size, preserveAspect, dx, dy) {// 10 repetitive lines of math},resizeRight(position, size, preserveAspect, dx, dy) {// 10 repetitive lines of math}, }let TextBlock {resizeTopLeft(position, size, preserveAspect, dx, dy) {// 10 repetitive lines of math},resizeTopRight(position, size, preserveAspect, dx, dy) {// 10 repetitive lines of math},resizeBottomLeft(position, size, preserveAspect, dx, dy) {// 10 repetitive lines of math},resizeBottomRight(position, size, preserveAspect, dx, dy) {// 10 repetitive lines of math}, };那些重复的数学运算令我颇为烦恼。 代码不够整洁。 大部分重复出现在处理相似方向的函数之间。比如Oval.resizeLeft()和 Header.resizeLeft() 就有相似之处因为它们都涉及拖动左侧的手柄。 另一类相似性存在于处理相同形状的所有方法之间。例如Oval.resizeLeft() 与其它 Oval类的其他方法也有共通之处因为它们都是围绕椭圆进行操作。同样Rectangle、Header 和 TextBlock 之间也存在一些重复因为文本块本质上就是矩形。 我有了一个想法。 我们可以这样对代码进行归类从而消除所有重复: let Directions {top(...) {// 5 unique lines of math},left(...) {// 5 unique lines of math},bottom(...) {// 5 unique lines of math},right(...) {// 5 unique lines of math}, };let Shapes {Oval(...) {// 5 unique lines of math},Rectangle(...) {// 5 unique lines of math}, }然后组成他们的行为 let {top, bottom, left, right} Directions;function createHandle(directions) {// 20 lines of code }let fourCorners [createHandle([top, left]),createHandle([top, right]),createHandle([bottom, left]),createHandle([bottom, right]), ]; let fourSides [createHandle([top]),createHandle([left]),createHandle([right]),createHandle([bottom]), ]; let twoSides [createHandle([left]),createHandle([right]), ];function createBox(shape, handles) {// 20 lines of code }let Rectangle createBox(Shapes.Rectangle, fourCorners); let Oval createBox(Shapes.Oval, fourSides); let Header createBox(Shapes.Rectangle, twoSides); let TextBox createBox(Shapes.Rectangle, fourCorners);代码的总大小减半重复的部分也完全消失了如此整洁。如果我们想要改变某个特定方向或形状的行为我们可以在一个地方进行修改而不是到处更新方法。 已经是深夜了我太投入了。我将我的重构代码提交到了主分支然后去睡觉了为自己解开了同事混乱的代码而感到骄傲。 次日早晨 ……并未如我所料。 上司找我进行了一次单独交谈委婉地要求我撤销那次修改。我惊愕不已。旧代码一团糟而我的代码整洁明了 尽管心有不甘我还是照做了。然而我花了好几年才意识到他们是对的。 这只是一个阶段 对“清洁代码”痴迷、热衷于消除重复是我们许多人必经的一个阶段。当我们对自己的代码缺乏信心时往往会将自己的自我价值感和职业自豪感寄托于那些可度量的事物上。一套严格的代码风格规则、一种命名方案、一种文件结构、对重复的零容忍…… 虽然无法完全自动化地消除重复但随着练习这一过程会变得愈发容易。通常情况下每次修改后你都能判断出代码中的重复是增多了还是减少了。因此消除重复仿佛是在提升代码某个客观指标给人以成就感。更糟糕的是它还会影响人们的自我认知“我是那种编写清洁代码的人”。这种错觉具有极强的迷惑性。 一旦我们掌握了创建抽象的能力就很容易对此上瘾只要看到重复的代码就会迫不及待地从中抽离出抽象。经过几年编程历练我们会发现到处都是重复——而抽象化正是我们的新超能力。如果有人告诉我们抽象是一种美德我们会欣然接受并开始评判他人不崇尚“清洁”。 我现在明白那次所谓的“重构”在两方面都是一场灾难 首先我没有与原作者沟通。我在没有征得他们意见的情况下重写了代码并提交。即便这算是一种改进我现在已不再这么认为这种方式也极其糟糕。一个健康的工程团队始终在建立信任。未经讨论就擅自重写队友的代码将严重损害你们在代码库上的协作效率。其次没有什么是免费的。我的代码牺牲了应对需求变更的能力换取了减少重复但这并非一笔划算的交易。例如后来我们需要为不同形状的不同手柄添加许多特例和行为。若沿用我的抽象设计实现这些变更会复杂数倍而若是采用原先“杂乱”的版本这些改动则轻而易举。 那我是否在建议你应该编写“脏”代码呢并非如此。我想强调的是当你谈论“清洁”或“脏乱”时应当深入思考其含义。这些词语会让你产生反感、正义感、美感或是优雅感吗你能否确切指出这些品质所对应的工程成果它们又是如何具体影响代码的编写与修改方式 我当初的确未曾深入思考这些问题只是过分关注代码的外观却忽视了它在一个由充满变数的人类组成的团队中如何演变。 编程是一段旅程。想一想从写下第一条代码至今你已走了多远。第一次体验到通过提取函数或重构类让复杂代码变得简洁想必令你欣喜不已。如果你对自己的技艺引以为豪追求代码清洁自然颇具吸引力。那么就先这样做一段时间吧。 但切勿止步于此。不要成为清洁代码的狂热信徒。清洁代码并非目标而是我们在面对系统无尽复杂性时试图理清头绪的一种手段是在面对未知领域、不清楚某项改动会对代码库产生何种影响时的导航工具。 让清洁代码指引你然后适时放下它。 个人感言clean code固然重要但不可过度封装‍♂️。