0

代码之外的功夫:AI时代不被取代的编程职业规划路径

这本书原名Programming Beyond Practices: Be More Than Just a Code Monkey,O’Reilly系列的封面插图是墨西哥蜘蛛猴,依然非常“富有内涵” 🙂

中译本起了一个非常有标题党之嫌的副标题,不过阅读之后还是觉得有几分道理。与传统的Design Patterns这样直接告诉你解决方案的技术教科书不同,这本书更像故事集,通过沉浸式的阅读体验引发深思,每每有种似曾相识的感觉。

第一章通过一个外包项目描述了用根据The Simplest Thing that Could Possibly Work原则搭建原型系统,以便快速验证需求并迭代,迅速完成项目交付且取得客户高度满意的故事。

我们习惯于考虑周全、枚举可达状态、力求交付更多,但是在探索项目创意的时候反而应该以目标为导向,用最小代价找到解决问题的最短路径,而克制住这些习以为常的工程习惯

Lean Startup的Minimum Viable Product就遵循了这个原则,相对于憋大招直到最后才将将满足客户的高风险,从简陋的滑板开始快速迭代才能真实掌握客户实际需要。

第六章讲了一个对用了10年对考勤管理遗留系统改造的故事。有系统改造经验的朋友一定知道,这样项目最大的挑战是要解决理想情况下的技术实现和公司工作风格和需求之间的矛盾。

一个组织的系统设计,会反映出组织本身的沟通结构。

——Melvin Conway

Conway的意思是,组织架构对于软件系统的性质和质量有深刻的影响。Eric Raymond说过,如果你有四个小组开发一个编译器,那你会得到一个四遍扫描的编译器……

下面这张图非常形象地说明了这个问题:

Amazon认为加强沟通是个糟糕的主意,在Bezos眼中如果两个披萨都不够吃,那么这个团队一定是需要继续拆分;Microsoft中Data Integration和App Integration团队互相笑称对方是呆瓜的场景历历在目,直至今天Azure上还是两个老死不相往来的托管服务;Google强调扁平与民主的工程师文化,使得政府项目以及中文搜索引擎举步维艰;Oracle就Google对Java API的使用,提出90亿美元的天价诉讼……

说正经的,数据建模和工作流设计密不可分,只有把它们放在一起考虑才能达到最好的效果。所以,按业务来划分团队,对自己模块的整个生命周期负责,就能够让团队自然的自治内聚、明确的业务边界减少和外部的沟通成本

第七章讲了一个权衡工作经济效益的故事。研发团队项目管理系统中,新的请求的流入速度比解决速度快4倍,如果算上测试团队汇报的缺陷,实际比例将近8:1。这个比例明显不合理,意味着大部分的请求处于遥遥无期的等待状态,研发团队积压的工作越来越多,如果不加以解决,日后维护起来会比现在更令人头疼。更糟糕的是,销售团队为了完成业绩,准备了更多的分类广告服务商需要对接。

经过认真分析,仅3/5的分类广告是由前3个服务商发布的,而后一半的服务商只发布了略多于15%的信息。为了平衡系统的质量与销售团队的想法,最终决定只支持8个主流的服务商,它们共发布了83.6%的信息;如果供应商整合的工作超过了一定上限,产品团队需要进行有效选择,以保留一定时间以确保其他由价值的研发工作。

在一个公司中,现金即是氧气,没有了销售额,一切很快就会变糟。思考这种事情并不令人愉快,但如果不保持警惕,就可能面临失业。同时,要开发更优秀、更有凝聚力的产品,需要平衡产品开发过程中所有相关人员的诉求,不能仅仅偏袒业务部门而忽略其他团队,避免待完成的任务被新任务挤压,让公司整个业务更加自然和可预期。出来混,无论是技术债还是业务债,迟早是要还的,用80/20取舍是个关键

如果上面的故事能让你手心出汗而不是一笑而过,那么这本《代码之外的功夫》一定值得细细品味。程序员是用技术解决人类社会常见问题的人,需要技术也需要艺术,只有两者有机结合,要被AI取代也就没那么容易了。

 



张 琪

发表评论

电子邮件地址不会被公开。 必填项已用*标注