以前没得选，现在，我想做CTO！
共 2595字，需浏览 6分钟
· 2022-05-26
👆点击“博文视点Broadview”，获取更多书讯
作为一名程序员，出于各种原因，我一直以为自己没得选。
因为不能承认自己能力差，要先混过试用期；
因为产品经理天天在耳边催；
因为得赶上线时间；
因为马虎、粗心；
……
此外，
面对着以诡异方式运行的系统
面对着“屎山”一样的代码
我选择给“屎山”加上盖子，在“屎山”上添加自己创造的“粪球”！
什么是“粪球”，我相信你早知道！
毕竟“屎山”就是由我们交付的“粪球”堆积而成的。
缺陷是“粪球”。
没测试过的函数是“粪球”。
没有好好写的函数是“粪球”。
不必要的耦合是“粪球”。
在GUI里出现的SQL语句是“粪球”。
业务规则里面出现的数据库Schema都是“粪球”。
……
简单来说，当违反编写软件应该遵守的纪律时，都有交付“粪球”的风险。
我不想交付“粪球”。
因为我不喜欢，CTO也不喜欢；
产品经理不喜欢，用户也不喜欢；
没有人喜欢“粪球”与“屎山”。
可是，该如何提交高质量的代码？避免提交“粪球”？
我带着疑问找到了我的CTO。
CTO如何看“屎山”“粪球”
听完我的叙述，CTO脸上露出了诡异的笑容，
他告诉过我，他年轻时也提交过“粪球”！
后来，他发现了软件开发的“屠龙术”；
从那以后，他仿佛开挂一般，
从普通程序员升职到一线大厂架构师，
又从架构师最终成为CTO。
如果想像他一样一路升职加薪，
出任CTO，迎娶白富美，走向人生巅峰；
以下几个秘诀必须牢记。
Software是个复合词，意思是“灵活的产品”。
软件存在的全部理由是为了让人们能够快速和容易地改变机器行为。如果软件难以被改变，软件就没有了存在的理由。
然而，今天软件行业的最大问题可能还是不够灵活。人们极度关注设计、架构，就是为了提高系统的灵活性、可维护性。
但是，无论创建了多少个微服务，无论最初的设计和架构是多好的结构，如果不遵守保证灵活性、可维护性的测试纪律和重构纪律，代码就会迅速退化，系统将变得越来越难以维护。
如果想在客户、产品经理提出变更要求时，开发团队能够明确、迅速地回应，及时给出策略，并说明变更范围与所需费用的比例关系。
因此，CTO必须强化适应能力，必须保证系统的设计和架构能够随着需求的变更而变化，当需求变更时，这些变更不会被现存架构或现有系统的僵化和脆弱所阻碍。
早在敏捷流行之前，大多数软件专家就已明白，运行良好的项目会经历有规律的部署和发布节奏。
在千年之交，敏捷的出现再次证明了对快速节奏的需求。Scrum建议冲刺时间为30天，XP建议迭代时间为三周。两者都迅速将节奏加快到以两周为单位。
如今，每天部署多次的情况并不少见，开发团队有效地将开发周期减少到接近零。
这就要求在每个冲刺结束时，软件在技术上已经准备完毕，随时可以发布。
“技术上准备好发布”并不意味着企业已想要发布。虽然软件在技术上已做好准备，但可能还没覆盖企业认可的完整能力或适合其客户和用户的功能集。
“技术上准备好发布”仅仅意味着如果企业决定发布它，开发团队（包括QA）不会有异议，该软件可以工作，已经测试过，文档齐备，并且已经准备好部署。
因此，CTO不仅要将“时刻准备着”作为信仰，更要将其内化成一种态度，一种生活方式，它是一种不断提供增量价值的承诺。
软件项目经常会出现生产力随时间下降的情况。这是一种严重机制失调的表征，它是由忽视测试纪律和重构纪律造成的。
这导致了纠缠不清、脆弱和僵化的代码不断增加，开发过程和开发出来的产物逐渐失控。
系统中的代码越是脆弱和僵硬，保持代码整洁就越困难。
随着代码脆弱性增加，人们对变化的恐惧也在增加。开发人员变得越来越不愿意清理混乱的代码，因为他们担心这么做会导致更多缺陷产生，甚至引发系统崩溃，就像下面这样。
这个过程在头几个月会导致生产力加速损失，在接下来的每个月都会导致团队的生产力渐渐向零靠拢。
有的CTO试图通过为项目增加人力来对抗生产力下降。但这种策略往往会失败，因为新加入团队的程序员对变化的恐惧并不比一直在那里的程序员少。他们很快就学会仿效老成员的行为，于是问题将长期存在。
CTO必须保证上述情况不会发生，从而让开发团队持续拥有较高的生产力。实现此目标的前提就是不打折扣地遵守纪律，保持软件结构不退化。
最后，CTO告诉我，以上几点完全来自《匠艺整洁之道》这本书——鲍勃大叔的封山之作。CTO就是从这里发现了软件开发的“屠龙术”，从此走上了正确的技术人成长路径，避免了35岁失业的魔咒。
鲍勃大叔在这本书里面沉淀了自己几十年的经验、教训，提炼出了程序员应该遵守的纪律、标准和职业操守。
纪律是最基础的一层，关注实用性、技术性和规范性。
标准是中间层次，概括了世界对程序员这行的期望。
操守在最高层，阐述了编程职业的道德准则。
鲍勃大叔用这本书全面剖析了尚处于青春期的技术行业，希望：
展现自己几十年上下求索得出的从个体到集体的匠艺思考，打破技术人头上的“紧箍咒”，让技术人为自己的工作感到骄傲和自豪。
总结自己几十年来在代码编写、敏捷开发方面经验，指导程序员写出优秀的代码、创建出色的系统，成为真正的“匠师”！
从最优秀、最有经验、最有战斗力的人身上找到改进自己的方法，找回编码的激情，激起提升手艺的欲望，无所畏惧地追求完美！
本书是为程序员和管程序员的人写的。但在另一种意义上，本书是为整个人类社会写的。
因为软件工程师可能是我们这个时代最接近工匠的一个职业，“代码是写给人看的，不是写给机器看的，只是计算机可以执行而已”。唯有不停磨炼匠艺，纠正“35岁转管理”这样的行业浮躁心态，才能走向真正的工匠精神之路。
这部大师著作上市后
高居图书榜第一
下单即减50，快快扫码抢购吧！
如果喜欢本文 欢迎 在看丨留言丨分享至朋友圈 三连 热文推荐
▼点击阅读原文，了解本书详情~