• 重构的分享


    不知道大家有没有想过,为什么入睡容易,起床很难,吃胖容易,减肥很难
    代码腐化容易,重构很难,诸如此内的问题,让大家感觉很烦恼?
    这些看似不相干的问题,有什么内在的原因?我也不绕弯子了,
    直接给出我分析的结论,那就是熵增定律
    什么是熵增定律呢?大家中学的时候都学过能量守恒定律
    但是这个定律有一个问题,它无法解释摩擦和耗散导致的影响。
    针对这个问题,德国的物理学家克劳修斯在前人的基础上
    通过实验验证提出,热机的能量是在不断耗散的,
    也就是说他的混乱度在增加,通过引入熵这个概念来描述这个能量耗散的过程
    简单的说,就是对于一个封闭的系统,如果不跟外界交换能量的话,这个系统就会一直混乱下去,直到毁灭。
    这个定律里面的系统可以延伸下,大到国家,社会,自然界,乃至宇宙,
    小到一个组织,一个生命体,同样也包括软件系统
    那么怎么抵抗熵增,减少这种无序的演变过程呢?
    这就要提到另外一个理论,耗散结构。
    这是另外一个物理学家普利高津提出的
    大概意思说,一个封闭系统如果跟外界能量交互能量是可以回到有序的状态的
    初听这个概念可能听起来有点难懂,如果我们再找几个大牛的名言理解一下。
    著名的物理学家薛定鄂有一句经典的话,人活着就是在对抗熵增定律,生命以负熵为主,
    这里的负熵指的就是逆熵,还有一句名言,一杯咖啡吸收宇宙能量
    说的也是类似的道理,就是多跟外部人才交流,才能增强公司的活力
    总结一下,熵增和熵减是同时并存的
    所以人即在衰老,也在通过运动来获得活力,软件在腐化,也需要通过重构来继续演变
    因此对于重构来说,他的本质就是逆熵,也就是说通过改变软件的架构或者说形态来减少熵值
    重而不断演进,重新获得新的生机的过程
    从更大的维度来看的话,不管是生命体还是软件架构都是一个不断演进的过程。
    比如说像蚕变成蝶的过程,是一个结茧,破茧,化蝶不断演进的过程。
    像手机的演变,也是经历了大哥大,GSM数字机,双频手机,一直到智能手机
    像软件架构的演变,从单一架构,到垂直架构,分布式架构,流计算机构,以及最近比较火的微服务架构
    那么对我们来说,怎么样才能跟上时代的脚步,不断的演进,以确保技术和架构不被淘汰呢?
    下面从技术和思维两个方面,分享下我的一些经验,
    从技术来看,感受最深的有三点,刻意练习,结对编程和持续重构。
    第一点,刻意练习,相信大家对代码的坏味道,重构的手法或者常见的步骤都比较了解了,
    但是碰到时间情况还是不知道怎么重构,
    这里我的感受就是没有经过刻意练习,也就是说只是达到了解的程度,还没有真正的熟练掌握。
    就像马丁富勒大叔在重构2.0版本中强调的,光掌握思想是没用的,还要有日积月累的勤学苦练。
    那么怎么练习呢?有没有什么技巧?确实是有的,不知道大家有没有听说过,code kata这个词?
    其实它的意思就是编码套路,最早是由《程序员修炼之道》的作者达沃,托马斯提出来的。
    达沃,托马斯认为可以将套路作为学习编程的一种技巧。
    方法很简单:每一个编码套路,都是一个简单的编码难题,容易解决,可以让练习者不断的尝试,直到完美。
    这样做的目的,就是帮助练习者每一次都能够找到更好的解决方法。
    练习者甚至可以对套路加一些限制,比如说要使用一种自己不常用的语言。
    像我们leetcode就是一个很好的编码套路的完整,上面有很多不同解答的方案。
    此外还有codewars,codeforces等此类的网站,可以在网上找到很多,大家都可以自己多动手去练习。
    练习编程套路最重要的是检测,不一定需要一万个小时,但至少需要达到熟练的程度。
    可能很多人会说,平时光搞业务都搞不完,哪有那么多时间搞别的?这个可能没有找到问题的重点。
    史蒂夫耶格在《程序员的呐喊》一书中说到,
    杰出的程序员成功的秘诀及时一直不断的锻炼,就跟健身一样,需要持续的锻炼才能获得完美的身材。
    我们知道肌肉如果不锻炼会转化为脂肪,那么软件和代码技能如果不锻炼会怎么样呢?
    那就是架构腐化,代码混乱。进一步会演化为问题单乃至现网问题
    第二点是结对编程,结对编程是敏捷开发中的一个优秀实践
    结对编程有一个明显的好处就是方便之处的传递,平时有很多团队内部的经验需要分享
    一般都是通过团队或者培训来做的,而结对编程开发就可以减少这些过程,比如一些编程技巧,通过手把手的操作可以快速传递和交流
    同时因为每个人的注意力都不会专注到某一个方面,可以互相监督,不容易偷懒去干别的。
    另外结对编程还可以确保项目内部的代码格式和设计思想保持一致
    结对编程具体来说有两种方式,一种是乒乓方式,
    这种模式是一个人写代码,另外一个人来重构,就像打乒乓球一样。
    这种方式比较适合两个人都是新手或者能力差不多的情况。
    还有一种方式是领航员驾驶员的方式,顾明思义,这种方式就是一个人写代码,另外一个人提供思路。这种方式适合一个人是专家,另外一个人是初学者,或者两个人都是专家的场景。
    总之结对编程,在我们的实践过程中起到了比较好的效果,推荐大家多多实践
    最后一点是持续重构,基于前面的熵增定律,软件腐化是不可避免的,那么技术债务必然会存在。
    在设计和迭代开发过程中就要预留好时间,专门清理技术债务
    ThoughtWorks的首席咨询师杰兹亨布尔曾说过,任何成功的产品和公司,他们的架构都必须在生命中不断演进。
    因此在设计阶段不要一上来就设计一个完美的架构,再完美的架构也会随着时间而腐化。
    最好是有一个小而精的,先满足现有的需求,随着产品和业务的演进不断的重构。
    第二部分,从思想的角度分享一下重构的心得。
    主要从信心,决心,恒心三个方面来说下:
    重构的信心主要来源于三个方面:掌握理论,磨炼技巧以及实战演练,前面两天就不说了,主要说下实战。
    实战主要是针对现有系统来说的,也可以称做遗留系统。
    从经验上看,基本上每个系统都会有一些需要重构的地方。
    一般大家对现有的系统比较熟悉,因此改动起来比较容易,也更容易发现一些问题。
    因此针对现有系统进行重构以提高自己的实战能力。
    这里有一个建议,就是大家在平时提交代码的时候多考虑下有哪些改进点,不要放过每一次提升的机会。
    第二点说下决心。
    说到决心,不到不说到72小时法则。
    这个法则的意思是说,当你决心做一件事的时候,必须要在72小时完成,否则你可能永远都不会再做了。
    所以需要大家把事情计划好,最好列一个清单,分清楚轻重缓急,让自己在72小时内动起来。
    这里举一个比较触动我的例子。
    2000年之前的亚马逊,他们的平台都是单体架构。
    每个开发人员只做一小块,但是一旦更新,必须要跟相关模块的人联调。
    这使得开发部署的效率特别的低,这也是之前我司大部分平台的开发模式。
    2002年的一天,贝索斯终于受不了了,他给全公司发了一封邮件。
    大概的意思是说,所有的亚马逊服务,必须基于接口进行通信。
    不允许进程间通讯,不能直接调用存储,不能使用共享内存。
    使用什么协议都可以,不服从这个要求的人将会被解雇。
    那时候这种架构还没有名字,其实就是我们现在比较流行的微服务机构。
    后面的故事可能大家比较清楚了。
    用了5年的时间,亚马逊把自己的所有服务都做了改造。
    经过转型以后,亚马逊的开发效率得到了极大的提升。
    然后他们把自己的平台开放给中小团队,成为全球最大的电商平台。
    第三点是恒心
    这里举一个人工智能的例子。
    如果大家听说过或者使用过tensorflow的话,应该了解tensorflow的核心就是张量。
    而张量最初的原型及时numpy数组,也就是多维矩阵。
    可以说他们都是矩阵计算家族的成员。
    我们翻开历史,在它之前还出现过几个其它成员,比如theano,dask,这些大家有可能听过。
    但是再早的numeric,numarray可能基本上就没人知道了。
    这里可以看出,矩阵计算也是不断重构演变的过程。
    刚开始只能支持本地小数据量的计算,慢慢地增加神经网络,分布式,以及大数据的能力。
    才有了今天人工智能的遍地开花的局面。
    总结下有几点比较关键:
    首先是要搞清楚事情的背景和价值,这是我们做下去的动力。
    然后是要有迭代的思路,把一个复杂的事情拆开,大事化小,然后把紧要的事情放在前面,快速迭代。
    第三是一次把事情做好,在做一个事情的时候,要想好兜底,一般,最优的三种方案。
    首先用一般的方案做,如果来不及了,就换成兜底方案,如果进度比较快,就换成最优的方案。
    最后是要有成长的心态,大家都不是天才,总会有能力不足的地方,只有不断磨练自己,才会有收获成功的时候。
    最后说一下心法,提到心法,大家可能会想到的是,类似功夫熊猫里面乌龟大师说的inner peace
    也就是中国功夫,提到的上善若水。
    但是在某一段时间内感觉到有状态,可以很顺利找到解决方案,并且达到比较好的效果。
    这在其他人活着自己回头看感觉都不大可能的事情。
    还有打游戏的时候,或者跑步的时候,感觉很有状态,时间也过得很快。
    这种状态下工作效率很高,所有我们希望可以更长时间进入这种状态。
    那么怎么做到呢?这里给大家分享几点经验:
    第一要主动做事,
    很多时候我们的任务都是被分配下来的,这时候你就可以想下,这个任务是要达成什么目标。
    首先让自己从内心上接受这个事情,从而转为自己的内在动力。
    第二设定目标,找到一个有跳转的可以达成的目标。
    比如不要光给自己说,要把某某书看完,要想下为什么要看这本书,要达到什么目的。
    确定好目标,然后这个目标也不是容易能达到的,也不是完全不可能的,是对自己来说比较合适的目标。
    第三,及时反馈和调整
    当事情做到一定阶段后,要看下当初的目标是否达成了。
    如果没有达成,还差哪些,如果达成了,是不是再重新定个目标。
    下面给大家分享一个视频,《被嘲笑的梦想》,对我感触很深。
    1884年,一个奥地利人,用一张图纸和一个轮盘向人们证明
    美国电力可走进千家万户,而绝非只能服务于工业,
    但两分钟不到,他的图纸就被最科学权威的爱迪生当场撕毁,
    所有人嘲笑他不自量力的胡言乱语
    这个人就是尼古拉特斯拉
    那个轮盘是人类史上第一台交流发电机
    而那张被撕毁的图纸正是如今220v民用电的最早的蓝图。
    1886年,在那个唯一交通工具还是马车的年代,
    一台喷着火,行动速度比马还慢的技巧出现在慕尼黑街头,
    马车店嘲笑发明者买不起马
    路人用石头打这个震耳欲聋的机器
    当地交通法也以惊扰行人为由
    禁止这个东西上路,
    而正是这个当时连马车都跑不过的机器,
    却载着人类跑向了不曾想到的未来
    这个机器就是人类历史上第一辆汽车,
    1903年,北卡罗来纳上空出现一个怪物,
    发明者声称它能像鸟一样飞,
    但是60秒不到,
    怪物掉落,
    发明者成了媒体口中的骗子,
    众人的笑柄
    但是,那个怪物,却是人类历史上第一架飞机
    正是当年那个不起眼的高度,
    让人类文明有了新的高度
    让我妈向这样的人致敬
    他们在冷眼和嘲笑中,
    依然保持一颗孩子般的初心
    进化了这个时代,
    总结一下我的感受:
    最重要的一点是,不要轻视自己的每一次改进,那怕是一小步,谁敢说这不是团队或者产品前进的一大步呢。
    第二,真理总是掌握在少数人手中,希望大家不要因为别人的嘲笑和谩骂而放弃自己的初心。
    最后我整理一个成长路线图,送给大家。
    迈开脚步,摆正心态,调整自己
    磨炼自己,刻意练习,打好基本功
    下定决心,定好规范,设定愿景,
    结对开发,技能传递,经验碰撞,
    持之以恒,迭代思维,持续改进
    架构演进,迭代开发,持续重构
    心流状态,目标明确,及时反馈
    从这张路线图可以看出来,成长的过程是曲折的,
    需要我们不断调整自己,才能不断跃迁,从而达到最终的彼岸。
    我的分享就在这里,谢谢大家。
     
     
     
     
  • 相关阅读:
    【Kafka】《Kafka权威指南》——从Kafka读取数据
    【Kafka】《Kafka权威指南》——分区partition
    【Kafka】《Kafka权威指南》——写数据
    【Kafka】《Kafka权威指南》入门
    六大设计原则
    EXCEPTION_ACCESS_VIOLATION(0xc0000005)
    属性文件——Java&Spring
    Maven——向Maven本地仓库中手动添加依赖包(ps:ojdbc.jar)
    使用Python轻松批量压缩图片
    Nginx常用命令,解决你日常运维的烦恼
  • 原文地址:https://www.cnblogs.com/gongxianjin/p/15906306.html
Copyright © 2020-2023  润新知