最近买了一本书《程序员修炼之道》,这书名起得跟葵花宝典一样😂,我一开始是拒绝的。就跟那些在畅销榜上的什么《阿弥陀佛么么哒》这种一听名字就反胃的书一样,畅销榜上的书都是好书吗?这年头花点钱就能上头条上热搜。写过代码的都知道,要想把某个东西排在前面再简单不过了,只要把数据库里这条记录的IsTop设为true就完事儿。这本书里的第18页说到:

      “永远不要低估商业主义的力量,网络搜索引擎仅仅把最热门的东西列在最前面而已,并不能说明这是你的最佳选择,而且内容提供商也可以花钱把他们的内容排到前面。书店有时候仅仅是把一本书摆在显著的位置而已,并不能说明这是一本好书,甚至不能说明这本书很流行,可能只是有人花钱把他摆在了那里”——《程序员修炼之道(第2版)》

        非常有道理,现在的网络,为了讨好、迎合和吸引用户,总是把你个人喜好的内容推送给你,慢慢的就会让你变成井底之蛙,某信、某博、某音、某手,某乎总有一款适合你,时间都会被这些快餐式的,没有什么内涵营养的内容给浪费掉,这些东西看的多了,人会感觉空虚,远没有读到一本好书有充实感。

       不过这本书我仔细看了一下,这个是20周年纪念版,表示这本书出来好多年了,而且译者看起来还很靠谱,就在某当上买了,目前看了前面几章,感觉不错,关于选书的原则我在一点读书笔记之二里说过一些。其实这类书以前也看过一些,比如《人月神话》《代码大全2》,《重构》之类的,说到《人月神话》,我想说一下,这本书大概是讲软件工程人与时间的关系,其中有一个地方说:

      “把项目的工作量定义成人月,并认为人和月可以互换,例如认为一个500人月的项目,如果100个人做5个月可以完成,而500个人做只需要一个月就可以完成,这只是一个神话(注:书名人月神话可能就是来自这里)。人类的认识需要时间周期、项目的运行也需要时间周期,这个周期相对固定,不会因为人多而变短;相反,向一个进度滞后的项目中添加人手,只会使项目更加滞后,因为需要额外的培训、交流,需要占用现有人员的时间。”——《人月神话》

      我以前在一家公司,需求很多而且变化快,时间很紧,天天加班,几个开发组的负责人跟老板说,能不能减少一些需求,调整一些优先级,把最重要的先做完,先发布一个可以使用,但是功能没有那么多的小而精的版本,后面再升级完善。老板却说,干不完招人啊,他不明白软件工程有时候不是简单的增加人手那么简单,听到只有吐血🙄,最后的结果可想而知,任何事情都要讲究科学,不能硬来,否则必然适得其反。

     这几本书,我其实都没看完,仅有一个大概的印象,以后还要拿出来翻翻。他们有个共同点,就是教方法论,简单来说就是教你写代码中的一些通用思想和方法,而不是针对某一具体的编程语言。

     看了这本书的前几章,跟之前看到的一些书里的思想其实很相似,比如什么DRY(Do not Repeat Yourself)、ETC( Easy to Change)、正交性(就是高内聚,低耦合,模块之间相关性低,往大了说就像手机app里面的沙盒,应用程序里的进程,软件开发里面的插件系统那样,模块之间依赖很少)。所以我时常在想,为什么看了这些,依然在实际编码中还是会犯错误,为什么没有成为高手。为什么那些反反复复说的道理,在实践中却一而再再而三的犯错,就跟某电影里的那句台词「听过很多道理,依然过不好这一生」一样,问题出现在哪儿。看了这本书我大概有了一些想法,可能各行各业也许都有类似的问题吧,想想大家在生活中是否也经常会犯一些常见的错误。

为什么会犯一些经常会犯的错误

      这一问题可能普遍存在,“知行合一”中,行为什么困难,一个原因是懒惰。不管是肉体的还是思想上的,可能“过好这一生”太难了,然而随随便的过,浑浑噩噩的过太容易,就像有句心灵毒鸡汤说的「努力,不一定成功;但不努力一定很舒服」,举个例子🌰,我之前给自己定了每天锻炼身体的目标,比如每天跑步至少五公里,刚开始一段时间很累,好不容易坚持了几个月好多了,但又碰上疫情,又几个月没锻炼,于是就改在室内,但是效果感觉远没有室外的好,一个原因是练着练着就开始玩手机了,因为玩手机舒服啊。拿到编程里来说,想写好代码太难了,但是随随便便弄个能交差的软件相对来说就比较容易,“又不是不能用”,“能运行就行了”,“妈的这代码写的一坨屎,我也懒得去改了,就这样吧”,“天天加班,怎么东西还有这么多,也懒得想了,怎么快怎么来,复制粘贴一下,能跑起来就行。至于代码效率,可扩展什么的以后再说吧”,“反正有测试给我兜底呢,代码看起来差不多,应该没问题,先提交吧,等测试报bug我再来改 ” 这些想法是不是经常会像幽灵一样,在你不想干的时候,在你脑海中浮现🤣。生活中是不是也是这样,总能给自己找一些活的不那么痛苦的借口。思想上或者肉体上的懒惰,虽然一时舒服,但是将来是要承担后果的,比如疫情期间没好好锻炼的我那又胖了几斤的肉😂。在编程领域,有个术语叫“技术债”,在这本书里说道:

    “虽然软件开发不受绝大多数物理法则的约束,但我们无法避免来自熵的增加的重击,熵是一个物理学术语,它定义了一个系统的“无序”的总量,不幸的是热力学法则决定了宇宙中熵会趋向最大化。当软件中的无序化增加时,程序员会说“软件在腐烂”,有些人可能会用更乐观的术语来称呼它,即“技术债”,潜台词是是他们总有一天会偿还的——恐怕不会还了(注:99%不会还😂),不过不管叫什么名字,债务和腐烂都可能失控地蔓延开

    “有很多原因会导致软件腐烂,最重要的一个似乎是项目工作中的心理状态,或者说是文化。即使是一个单人团队,你的项目的心理状态也是个非常脆弱的东西”

      我最近看ASP.NET Core MVC顺便看了一下单元测试,觉得挺好的,一个是方便调试,就是我不需要每次把整个项目编译,然后把程序启动起来,只需要就单个功能语句,单个代码逻辑进行测试就可以,如果每个小的模块,小的语句没问题,那么组合起来大概率没问题,这或许有点像系统工程,测试每一个小部分,提高每个小部分的稳定性,那么封装起来之后,大概率也没问题。二是方便以后对代码进行重构,因为没有单元测试对代码进行重构是很危险的,单元测试是一种testcase,他能保证代码的修改后所有的用例都能通过。单元测试这么好,但是写单元测试太累了,而且还需要有一定的能力,因为之前写的代码可能没那么容易进行测试,需要学习mock一些对象来隔离依赖,或者回过头来需要去修改代码让它的结构变得更合理,更容易测试。这些都需要时间成本,都需要精力,也需要学习。有一些事情,在平常没压力的情况下可能还好,但是在时间,效率受限的条件下可就不一样了,懒惰随时会想,我以后再加吧,以后再处理吧,殊不知这跟请客吃饭一样,如果某人跟你说改天请你吃饭啊,一定不要听他的鬼话🤣。

     还有一个原因是自我麻痹,这种其实是一种思想上的懒惰,但是他让自己觉得自己看起来甚至还很勤快,以前看过一本书,里面有说道:

    “工作狂往往不得要领。他们花大把大把的时间去解决问题,他们以为能靠蛮力来弥补思维上的惰性,其结果就是折腾出一堆粗糙无用的解决方案。”——《重来:更为简单有效的商业思维》

     “靠蛮力来弥补思维上的惰性” 说的太好了,我们是不是经常会遇到,一些需要自己重复去做的事情,有些完全能写个代码或者工具让计算机来处理,准确高效又不犯错误。但是“ 写代码需要消耗脑细胞啊。我留着脑细胞看看电影听听音乐它不香么,每天动动手做一些这些重复的工作也挺好的,说明我还是个勤快的人”,这种就是思想上的懒惰。大家是不是都有这种经历🤣。“每次一到放假,是不是都会带很多书回去,想着我要爱学习,带回去就会看,但是实际上大多数时候都是束之高阁,因为学习要思考,躺在家里睡觉、看电视,或者出去玩太舒服,有时候还会安慰甚至说服自己:我起码把书带回来了”,“要劳逸结合,放假了就该好好放松休息”,在《代码大全2》里说过:

     “人们容易混淆行动与进展,混淆忙碌与多产。有效编程中最重要的工作是思考,而人思考时通常不会看上去很忙。”——《代码大全2》

       有些时候把自己弄得很忙,这样可以麻痹自己很勤奋努力,看看我天天加班,认真吧,其实有可能是思维上的懒惰,不想找能够提高效率的方法。比如每次代码提交后,代码审查被指出的问题,我都会认认真真的记到OneNote里,思想上就会认为,我记下来了肯定以后就不会犯错误,就会吸取教训,我必须首先说服我自己重视问题,至于是否能修正以后不再犯,以后再说;再比如在写代码的过程中,有时候觉得别扭,那这肯定是有一些问题没想清楚,为什么要这样写或者要这样做,但是有时候就那样提交了,被问起来为什么这样又答不上来,有些问题在某一刻也问过自己,但是抱着侥幸的心里忽略了;再比如有时候拿到需求,没深刻理解就急忙写代码,思想上先给自己一个假象,我开始工作了,这样进度应该会很快就能做好交差,实际上有时候在错误的道路上走得很远,最后浪费很多时间,有时甚至需要重新开发和测试,这些都是很危险的想法。正如阿迪王(注:EdiWang,程序员,本博客系统作者)说过:

   “程序员这个职业,还是讲点道德,不要自欺欺人。偷工减料,欺上瞒下,实际就是豆腐渣工程,跟黑心棉,地沟油,涂蜡橙子一样可恶”,千万不能有“又不是不能用”,“看起来能运行就行”的危险想法,这就像你去餐馆吃饭,厨师做饭的时候心里想“看起来能吃就行” 一样。

     如果全社会各行各业都是这种“又不是不能用”,“看起来能运行就行”,“看起来能吃就行”的想法,对每个人都是危险的。

     最后一个原因是技术或者经验上的问题,比如对一些情况的准备不足、认识不充分、考虑不周全,缺乏对问题的深入理解,有些错误一而再再而三的出现,问题出现第一次的时候,很想认真去解决,但是由于认知的原因,很悲剧的只抓住了表面情况,就像八爪鱼一样,只看到了一个触角,以为这就是全部而没有深入了解原理,内部出现的问题,可能会表现出很多个外部错误。

有没有解决方法呢?

     前面说了那么多,那有没有解决方法或者突破口呢,我总结了一些解决方法,也是我自己在进行的。

     对于懒惰和自我麻痹,这两个其实是最大的问题,它不是技术上或者能力上的问题,或者说技术或者能力问题不是主导因素。 

     首先要“自我洗脑”,需要偶尔或者经常读一些“进步书籍”,比如这本书,虽然看完不一定功力能立马提升几个级别,但是起码能在自己松懈的时候提一个醒,给自己灌输一些正确的思想,提醒自己不要懒惰。回想当年考研报政治辅导班的情景,那些政治课老师讲课非常有煽动性,如其说是政治辅导,不如说是传销打鸡血,每当倦怠的时候,听一堂课就会让人觉得热血沸腾,内心小宇宙马上要爆发😂。同样这本书也有“洗脑“功效,比如:

     “如果代码都不写好,那你做这件工作的意义是什么呢?”

     “人生是你自己的,是你在拥有、经营和创造”

     “我们和很多沮丧的开发者交谈过,他们的担忧多种多样,一些人感觉自己的工作停滞不前,还有一些人认为自己的技术已经过时了,有人觉得自己没有得到应有的重视,有人觉得薪水过低,有人觉得团队已经一团糟”

      “对此,我们总是给出相同的答案。”

      “为什么你不考虑改变一下呢?” 

      “软件开发在任何职业列表中,绝对是你自己最能掌控的职业之一。我们的技能供不应求,我们的知识不限于地域,我们可以远程工作。我们收入颇丰,我们真的能做我们想做的任何事情”

      “但是,总有一些原因导致开发者拒绝改变,他们缩在那里,期盼着事情会自己变好。他们眼睁睁地看着自己的技能过时,却抱怨公司没有给予培训”

      “你有选择权!你的工作环境很糟糕?你的工作很无聊?尝试纠正它,不过不要一直试下去。正如Martin Fowler说的'你可以去改变组织,或者让自己换一个组织'”

      “如果你的技术过时了,安排时间(你自己的时间)学习一些看起来有趣的新东西。这是一种自我投资,只有为此而加班才是合适的”

     另一个是要加强“辩证法”,比如我很早就觉得世界上的喜怒哀乐都是平衡的,大喜容易大悲,现在过的多舒服,以后就可能多杯具。那为什么现在不辛苦一点,让以后能过的爽一点呢,当然这个比较玄学了(杠精会说“条条大路通罗马,但有的人就出生在罗马”,这不在讨论范围内🤣),这只是我自己的认知。现在舒服一下,急急忙忙不好好检查,代码提交了,到时候代码审查问题,会挨批评,万一没审查出来或者测试没测出来,东西给别人用了,出了大问题,造成了损失,可能就杯具了,搞不好可能要删库跑路😂。所以不能怕麻烦,立即,马上,认认真真,不放过一个细节,再检查验证一下,如果时间允许,先让自己冷静一下,明天再过来看看是否有问题,很奇怪,有时候代码当天写完,在晚上回家的路上,或者洗澡的时候,可能会觉得有一个小问题没考虑进去,亦或者有一种更好的方法。总之,如果有时间,不要着急,确保交出去的东西完善,各种case都要想清楚。在每次commit代码前,再问一下自己(在这本书里作者说一些IDE能自动修改保存时的提示语,比如可以在每次保存时,提示“当前的修改是否让代码变得更好”)。即使出了问题,起码前面是自己仔仔细细检查过各种case都想过了,而不是拍大腿感叹“妈的要是当时再认真多检查一遍就好了”。

     第三就是要提高责任意识,并不断强化 “不要写烂代码,把烂代码跟豆腐渣、地沟油、黑心棉联系起来,写烂代码就是不道德!” 的思想😂。有个“破窗理论”,这本书里也提到过:

     “在最初启发‘破窗理论’的实验中,一辆废弃的汽车完好无损地停了一个星期,但是一旦有一块玻璃被打破,这辆车在几个小时内就会被扒光并被翻个底朝天”

     “一扇破损的窗户,只要一段时间不去修理,建筑中的居民就会潜移默化地产生一种被遗弃的感觉——当权者不关心这幢建筑的感觉,然后其它的窗户也开始损坏,居民开始乱丢废物,墙上开始出现涂鸦,建筑开始出现严重的结构性损坏。在一段看上去很短的时间内,建筑的损坏程度就足以打消业主们想修好它的期望,被遗弃的感觉最终变成了现实”

     “不要搁置‘破窗’(糟糕的设计、错误的决定、低劣的代码)不去修理。每发现一个就赶紧修一个。如果没有足够的时间完全修好,那就把它钉起来,也许你可以注释掉那些糟糕的代码,显示一行‘尚未实现’的信息,或用假数据先替换一下。采取行动,预防进一步的损害发生,表明一切都在你的掌控中”

     “处于同样的原因,如果身处一个健康的团队,你们的项目代码如此完美——编写清晰、设计优良、简洁优雅,你就会倾向于格外地小心,不把他弄糟,就像那些消防员那样,即使屋内火势熊熊(截止时限、发行日期、销售演示等等),你也不想成为第一个弄乱它,造成附带损害的人。一定要告诉自己‘不要打破窗户。”

     “现在我们了解了一旦窗户开始破裂,运转良好的干净系统会迅速恶化。还有一些其他因素会导致软件腐烂,我们将在别处探讨,但与其他任何因素相比,漠视会加速腐烂的过程”。

      对于第三个问题,经验不足可能可以从以下三方面能够改善:

     首先是要靠自己多实践,多动手,多思考,见多识广,所谓的经验只不过是在各种挖坑填坑的过程中丰富起来的。

     其次可以借助一些外部的工具辅助自己,比如就在最近,我就在代码里犯了一个拼写错误,把一个label的text中的某个字写错了,直到提交后,准备截图写说明文档时才看出来。虽然领导没审查出来,虽然这完全不影响使用,但是认真的人看到了就会觉得你不认真,很马虎。拼写错误的原因是我用的某歌输入法,它干净清爽,但纠错能力或者说联想能力不强,那个字我用拼音打字出来它就是错的,没有正确联想到我要的那个字。然而我又不想用某狗输入法,虽然准确率更高,但是实在是不喜欢各种广告以及弹窗。像这种情况下,为了避免错误,我可能就要把某歌卸载了用某狗,虽然要忍受偶尔的广告弹窗,但是能减轻拼写错误的机率。另外,在写代码中,除了IDE能提供一些提示之外,还有一些插件,比如ReSharper能给你一些有益提示,这样能避免一些错误。

     最后就是锻炼心里承受能力,有些时候在平常可能没问题,但在一些条件受限的情况下,比如时间紧急、压力大、领导站在你旁边😁,再比如线上出现问题,要马上解决,不然会损失好几个亿,在这种压力情况下,要能不紧张不犯错很难。但要克服这种情况,有一点可以做的是,平时做好各种预案,要有Plan B(这些预案包括限流、熔断、备份...),这样在实战中看到一些情况,心里有底,知道这个问题产生的最坏的可能后果,然后安静平和的做好准备并及时通知上级,保护好现场后开始操作,操作之前做好备份,操作完之后做完校验,万一失败能回滚,在很大情况下能改善这种状况。

总结

     本文主要对「听过很多道理,却依然写不好代码」这一世纪难题进行了一些粗浅的分析和思考,并给出了一些不成熟的想法,以期能提高自身思想、技能水平,从而避免996,虽然稍微有点遗憾的是不能积福报。

     许多年之后,摸着自己的头发,中年程序员yy可能会回想起,他在灯下思考如何避免996进ICU,进而写出《为什么听过很多道理,却依然写不好代码?》一文的那个遥远的晚上(注:本句模仿《百年孤独》开头😂)。