今年没写几篇博客，在图形技术方面的长进也不大。但今年感觉自己写代码开始入门了，以前可能都不算会写代码。
今年也是这么多年来写代码最多的一年，Github为证，今年提了3.6k commit，平均一天10个。
今年写的比较多的是Unity/C#，Python和Typescript/React。但无关语言，感觉自己最大的收获是技术文化和方法论的总结，从软件工程师的角度。作为技术美术感觉技术到头了怎么办？还有很多软件工程/游戏玩法/产品设计的坑可以挖。
美术Pipeline
之前作为技术美术，从两三年前开始接触CI/CD的概念，但并没有太多实操的经验，只有在今年才开始逐渐加深认识。一方面是Code Review的团队文化，另一方面得益于Blender环境。由于开发的是Blender管线，而它是开源多端兼容，也就很容易嵌入到Docker/Github Action的工作流程中，实现大量的自动化测试。最后是数据仓库领域的影响。
以前总听国外的技术美术团队谈到Code Review的重要性，但在国内并没有太接触过，即使在育碧也只有部分进入引擎的工具代码会经历Review，而自己工作室的工具很多并没有这方面的意识。最近一年才感觉到这种方式能够避免一些bug，能够保证架构的整洁干净，能够强制best practice，能够指导新人。当然这一切建立在能够对代码有标准的基础上，有时候并不是一个技术问题，而是一个审美品位的问题。当然，这部分的感悟其实不全是写美术pipeline工具时的，更多是写前端时的。
当然以前经常用pytest，但是给max/maya/houdini写测试太痛苦了，并没有一个CI环境可以跑这种东西。用了blender以后终于真的可以给插件写测试了。当然用pytest跑blender插件的测试有点坑的，以后有机会细说。好处是直接在Pull Request阶段能够用Pre-submit Check直接减少regression，提高开发效率。并且先写测试/测试驱动可以直接指导开发，反正测试过了就是功能对了。但与之相反的是感悟是一些交互性很强的功能，自动测试的成本效率可能不如人工测试，不能适足而履。
ETL是一种数据仓库（或者说大数据）的技术，quote “将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程”，E T L = Extract，Transform，Load。数据仓库的内容量级可能接近甚至超过美术资产，而从美术管线生产的资产，如blend文件，贴图模型等等，真正进到引擎/生产环境，从数据仓库角度看就是一个ETL流程。于是很多数仓的调度运维技术就跟美术生产管线接上了，于是美术资产也可以CI进入引擎/生产环境。比如笔者接触了Prefect，这种中间件可以很方便扩展到分布式，应付更大规模的资产。
原型制作
笔者之前确实还做过挺多原型的，并没直接用在生产中。但今年感觉做原型是个很重要的事情。
首先，实现一个Feature并不是一蹴而就的，在实现之前有很多地方可能想不清楚。最好的方法是先花20%的时间完成80%的效果，把它整合到系统中，然后反过来看哪里实现的可能有问题，在之后的设计中避免问题再次发生。这就是做原型的力量。
其次，有很多Feature并不是设计师/美术师/策划能想到的，需要给他们展示可行性，让他们了解局限性再推进设计，能够决定产品的不仅是策划，作为工程师能够融入开发流程也是关键的一点。
最后，做产品/做游戏大都是相通的，一个核心玩法/解决痛点+若干次要玩法/解决爽点。但怎么找到玩法，不仅仅是要一个想法，更重要的是快速迭代快速验证，快速制作程序原型就很有帮助，毕竟很多3D交互是纸面上无法呈现的。这也有助于避免程序开发的无用功。
Get your hands dirty！先做原型再做系统设计不是绕远而是捷径。
技术的生命周期
有几本影响笔者比较深的书：《跨越鸿沟》，《创新者的窘境》，《科学革命的结构》，前两本是今年读的。
技术/科学/产品的生命周期和生物一样，都是遵循逻辑斯蒂曲线的。从密度上看是一个正态分布钟形函数，从分布上看是一个S形曲线。
技术/科学/产品之间的竞争也就如同生物之间的竞争，有物种灭绝，有生态位，有食物链。适者生存，而并没有银弹。霸王龙有它的烦恼，草履虫也有它的生存之道。
技术能够改变生态位，但是更重要的合适，合适的才是最好的，它不一定是最强大的。
以上，作为年终总结，
最后，祝各位读者新年诸事顺遂！