实战型开发1/3--结果业务导向

在这里插入图片描述

假期难得一段时间把近期一些实战型开发的阅读，实践做一些小结；
风格方面就是包括不限于一些好的开发实践，nb的开发技术流程等，但是总体着力于实战型的开发；
在这里插入图片描述

三层视角

业务&团队视角：开发所要最终服务的，以及意义所在，这部分往往是用户或者老板的视角更加合适；
架构视角：架构，< clean architecture >, < design patterns >为代表的书所聊的事情
细节视角：细节代码，《clean code》为代表的书所聊的事情

在这里插入图片描述

“艺术家”+"产品经理”=“winner”开发者

“艺术家”的副作用

一些牛逼开发者经过多年修炼之后，会成为“艺术家”级别开发者，除了技艺层面的炉火纯青&日日精进，更是精神层面享受开发，更接近于艺术家雕琢自己作品时候的心境，可以不遗余力乐此不疲的为写出优雅的代码和结构奋力工作，加班熬夜那都不叫事，颈椎病脂肪肝那也是为艺术献身；
但是这个“艺术级”追求，入戏越深，则越容易带来副作用，就是太过执着于代码的优雅，而偏离程序所要服务的对象以及意义，程序是要带来服务和解决方案的，换做游戏的话，就是要快速高质量的过每个milestone最终交给玩家好玩的游戏。
这个“艺术家”这个“沉浸于艺术，而忽视产品”副作用是客观存在的，不可不察。

不识庐山真面目，只缘身在此山中

不识庐山真面目，只缘身在此山中，所以要讨论真正的开发能力，需要在开发之外来看事情，比如CEO视角，或者是上一级视角。

我自己个人在天刀端游上线之后，短暂了做了一段时间的后续项目的PM，这段时间的经历直接让我转换了视角，要看项目的人力，计划，成本，产出等等事情；仅仅是这个角色的转换（其实我当时也在做完计划之后写代码），就会带来巨大的不同，比如，我非常自然的能看到这个demo阶段代码的dirty问题，设计问题，效率问题都不是问题，根本不应该花任何时间去搞这些，能够在demo中展示出nb的画面和流畅的操作才是一切，开发团队的整理代码和设计方案的时间申请都被我礼貌但坚决的劝回去了。。。
仅仅是视角的转变，如果之前纯开发者的话，我会知道这样做是对的，但是心里会反感，做pm就是身心一致自然地觉得这样是对的，而且这个过程非常的自然。

所以当我站在产品经理视角看程序同事的方向性错误，感到非常可惜的，无数的hardwork敌不过一个看问题角度的转换，而这个角度的转换最容易的就是做一段时间产品经理(如果有这个条件的话），如果不行就尝试去站在产品经理的角度想问题以及获得产品经理的信息。

winner开发者

这里引用杰克韦尔奇在《赢》中的话：

这正是本书要谈的主题——赢。或许没有其他话题能让我有兴趣再写一本书了！
因为我认为赢不仅仅“好”，而且是真正的“伟大”。
在商业生活中，取得赢的结果是伟大的，因为当公司赢利的时候，人也取得了长足进步。对成功企业的每个员工来说，
他们在市场上有了更多的工作机会和创业机会，他们对未来更加充满自信，有钱送自己的孩子上大学，能得到更好的医疗服务，
买得起度假别墅，退休生活也有了更好的保障。企业的赢利还让他们有机会回报社会，除了纳税之外，
还有许多其他的方式——因为他们可以把更多的时间和资金奉献给慈善机构，比如到社区学校去当辅导员等。
赢的结果可以惠及周围所有的人——让世界变得更美好。

winner开发者才应该是我们的目标，技术修为不够的产品型开发者会在高端局中因装备不行操作不行各种拉胯，艺术家型开发者容易跑错路不参团沉迷于塔下强杀。。。
最后拿下高地的，还得是技术&大局观都到位的开发团队；

所以拥有“CEO视角”的艺术家级别开发者会比单纯的“艺术家”级别开发者完全高上一个段位。

“elon musk传”和“领域驱动设计”

这块个人近年来接触的比较好的就是：

强力CEO：elon musk传中对于musk推进多加公司创造nb事情的过程
面向业务的开发思路：领域驱动开发

在这里插入图片描述

elon musk的方式

汇集musk的行事循环：

有一个足够给力&革命性的愿景，e.g. 跨行星物种，去火星，给世界带来可持续能源，让电动车成为现实。。。
专业评估（包括第一性原理），对于其中不合理的地方直接进行强势挑战，倒逼10x生产力：spacex的成本，tesla各种不可能的交付日期。。。
各种极限挑战，乃至容忍10%的失败率，最终找到极限：对于成本各种结构的种种挑战，对于航天业中各种老的规定直接挑战等等；包括自己深入一线，睡在办公室，精神病级别的粗暴管理。。。
极限挑战下的团队组成以及工程细节和方法论：e.g.

- 确定需求
- 极力删除零件或过程
- 简化和优化
- 加快周期时间
- 自动化

这里神奇之处就是10x的生产力和技术突破，这点是由愿景&细节驱动，

愿景方面，贝索斯也有这样的愿景甚至更大的财力，但是在过程中所差的就是在工程细节能力&一线亲力亲为上
没有愿景只有财务表，就是播音：技术突破和10x生产力都是不合时宜

10x生产力是技术团队的终极问题

那么在musk这样的ceo的闭环中，技术团队应该关心的终极问题是什么呢？架构，接口，人力成本？生产力才是唯一的终极问题；
这个也应该是winner开发者的判断标准；

所以在看clean code, clean architecture等书中，感觉第一个问题就是没有从这个角度来抓，论证架构合理性也往往从后面的可扩展性入手，其实就是拥有clean code&architecture能力的团队，就是可以拥有更强的生产力，进而能够更好的帮助产品更好更快的实现出来，并且这种生产力可以长期持续。想要从头猛到尾，整体上clean code&architecture是唯一的选择，而且部分阶段中，也可以去违反clean code&architecture来获得局部优势；

方向大于速度：不同情况下的不同生产力需求&定义

那么生产力到底是指什么？尽快的写出好代码？堆人来加快开发算不算生产力？。。。
这个只能说不同情况下不同的需求和定义，开发一个肉鸽游戏和开发unix对于生产力以及各个阶段该做的事情都是完全不同的。
这里简单讲，就是我们对于产品所要达到目标的最该做的事情，这是一个方向性的选择，或者说是一个战术的选择问题；
e.g. 比如要做一个玩法演示视频，那么就直接可以商城购买资源&插件，做好玩法demo的“缝合”，里面各种hack，各种要丢弃的代码，性能各种差，直接就用最好的电脑来做视频录制即可，任何去拘泥于clean code/architecture的额外代价（这里开发内力后面会提及）都不要付出，这种极限速度和资源消耗就是生产力的体现；
e.g.，如果团队不用受中间milestone的影响，直接就可以长期计划走起，目标是“杰作”级别的游戏，那么就可以上来开始设计未来硬件的资源工具流&渲染管线等等，三个月内要出能够奠定未来三年开发的设计，这个也是生产力的体现；

根据不同的情况，阅读出场上的需求，进而做出相应的选择，超越clean code/architecture；

成年人全都要：开发的内力

从前面看，不论是winner开发者还是生产力的定义来看，似乎开发的素养内力的重要性开始下降，悲观型的人甚至可以认为锻炼这个素养用处不大（不如做出一个正确的选择）。
实际上，生产力选择和开发内力是不互相耽误的，电子竞技中战术重要还是操作重要，篮球运动中的战术重要还是基本功重要，都不应该是winner开发者要讨论的问题，winner开发者就是要两者双修。
开发内力强的开发者，就是可以看到一个问题，第一时间就反映出该有的设计，第一次就可以写出简洁的代码，根本不用在纸上反复推演，写完重构八遍，都是一遍过；快攻的时候，保持一个精准干净的开发，才是艺术家级别开发者该追求的事情；
这块尤其是刚刚入行的开发者应该保持专注的点，这个时候大部分把握方向的事情都是lead来做，你就可以专注于各种pattern和clean code基本功的锻炼。

sum

这里讨论了，winner开发者在进入细节和过程之前，首先要跳出抓住关键：生产力；
想办法提供产品所需要的10x生产力，确保对于开发方向（业务）的理解，围绕10x生产力来思考和推进（musk是一个非常值得学习的案例）。

在这里插入图片描述

领域驱动设计

musk为代表的生产力之后，就是进入到实现环节，那么第一步就是谈及业务和开发的结合，也就是领域驱动开发：

保持和业务的使用者（制作人，策划，美术）进行沟通
通过event storming等对于业务（domain）进行建模，确保战略设计正确性
然后在进入细节，确保战术设计正确性

这里关键点就是首先对业务进行梳理，并且程序员参与到战略设计部分（与策划美术一道）中去，对需求进行梳理，建模并映射到实现中；

这里开发中个人的一个主张就是：

程序团队自己来写一份相对详细的策划文档：以这个形式来保证对于业务的熟悉，这个虽然会花费一些时间，但是其重要性甚至高于程序中的comments，避免犯方向上的错误；

一些技战术

在这里插入图片描述

TTK（time to kill）

这个是23年开始在团队内部推动的一个开发概念，就是我们精准计算一个需求从提出，到策划/美术可用的第一个版本的提交时间；
借用游戏中TTK（击杀时长）的概念，作为团队的核心指标来推进；

尽可能短的开发时间对于团队开发有非常强的意义：

其实就是我们熟悉的指令流水线，当我们把交付拆成首个最快的首个版本，和后续polish版本时候，团队的整体吞吐就提升了

提升整个团队的运作效率，可以说是技术团队对于整个产品团队的最顶级的贡献了，所以我们就也作为核心指标来自我要求和优化；

然后会不会出现设计问题呢？其实不会反而会更好：

收尾标准：只要技术团队明确的知道自己是在干什么就可以了，整个任务的结束点是在设计和代码整理到位，以及文档写好之后才收尾即可；
架构影响TTK：追求TTK的时候，会把任务的提交点从一周缩短到1,2天，那么一些架构的不合理，很容易会拖慢TTK 40%甚至更多；换言之，在更短的时间下，大家对于架构的敏感度是更高了而不是更低了。