【成长】DCC插件开发心得

Das丶May

已于 2024-05-18 00:21:54 修改

阅读量885

点赞数 19

分类专栏：胡思乱想文章标签：敏捷流程

于 2024-03-19 21:13:00 首次发布

本文链接：https://blog.csdn.net/m0_55476160/article/details/136667406

版权

胡思乱想专栏收录该内容

3 篇文章 0 订阅

订阅专栏

全文3000字，预计阅读10分钟。

一、需求制定

有生产的过程，就一定会有提效的需求。
但问题是，能够同时懂需求且做开发的人才太少了。并且，这样的人才，懂两个人的活儿，却只做着一个人的工作，公司应该给两个人的工资、还是给一个人的工资呢？大部分情况下，这样的人才会要两个人的工资。公司是不愿意的。
所以我见到的用人标准是：
急活儿 -> 高级技术美术单挑
长线插件 -> 学过图形学的程序员合作

我其实会有点犹豫：这篇文章算不算一篇“工具向技术美术”的开发心得？我真的觉得不是。应该叫“工具向程序员”的开发心得。但是呢，后者看起来不三不四的……留下前者的tag方便检索吧。（鞠躬）

需求就是插件的生命。没有美术需求，这个做插件的部门也就没有存在的必要了。

能提出需求的人一般是能明确痛点的资深美术师。年轻的美术不知道调效果的关键是什么，更不知道痛点，也就更难提出需求了。资深与初级的生产效率差距能有5倍。资深的产出被打回重做的概率更小，交付的美感更好。资深美术师占项目组的10%左右。

对于年轻的美术，有些人不愿意学习新插件，感受不出用不用插件的区别；有些人尝试了新插件，但新的东西往往不稳定，比如出现bug，比如卡顿，比如闪退，这些不稳定因素会劝退、会磨灭他们的信任；少部分人热情迎接，觉得可以按自己的需求定制化插件，真实爽歪歪，bug什么的他可以忍。
而在我的用户中，它们的比例大约是50%，40%，10%。
没人用就更没需求，就生产力更提不上去。领导肯定不乐意呀，于是就强制性要求美术们用插件。终于，这个比例大约提到了10%，80%，10%。唉……路漫漫……

接需求的时候，要尤其注意评估需求的价值——实现这个需求，能否真正让美术提高生产效率？能提高多少？投入产出比值得做吗？

爱美之心人皆有之，美术提需求，真的蛮喜欢界面美化类需求。确实，赏心悦目的界面能提高工作动力。但领导眼里的“真正提效”，这些小动力就是九牛一毛。

不过这也是一个切入点。做插件的同学如果有经验，不花大力气就能做出比别人更舒服的交互，其实也是一种职业竞争力。

上面我说到，提需求和做插件的是两拨人。
这可能会带来误解：美术有idea。要想实现一个idea，可以表达出不同的需求，不同的需求对应不同的工作量。美术不理解程序的工作量如何，他随机提了一个需求。程序员不理解美术的idea，只能按照这个需求硬着头皮做。
结果就是工时的浪费，甚至是做不出来。这一点是需要积累经验的地方。

有时候，美术能提出idea，但说不清需求（具体想要什么）。

做插件的部门是不可能有产品经理的。程序员本身就是产品经理。

这种时候就比较恶心了。试着把需求做出来，美术觉得不符合他的idea。这时候要驳斥需求吗? 因为做不到而驳斥需求，一方面，我上面说了，需求就是生命，驳斥需求约等于自残，另一方面，驳斥需求会给人一种不值得信任的感觉，美术和领导他们都会有这种感想，将来如果有新需求，他们潜意识里觉得你不值得信任，就会闭口不谈了，这个插件要完。但是呢，如果不驳斥的话，谁知道这功能做到什么时候是个头？谁能保证这个抽象的idea就一定能带来提效？很多时候，美术自己也不知道实现这个idea能否带来提效，以及能提多少效。呕心沥血做出一个没用的功能，这个锅是美术背还是程序员背还是领导背？

这个问题我暂时找到了答案：不要驳斥。尤其是经过领导认可的idea。
因为，在真正对口的效果做出来之前，很少人能预判出什么样子才是真正的有用。但是呢，如果尝试出了一个不对口的效果，好歹美术能反馈说：“哦，这个效果，我不太喜欢”。有反馈就是有进步，而不一定说是要出对口的效果才是进步。

二、开发与迭代

做插件和做工程还是有区别的。我觉得做工程是创造一个世界，做插件是在已有的世界里造个房子。

首先是，插件肯定做不大。它只是一个辅助主体软件的东西，没有服务器，代码量少，能跑就行。

所以维护这样的产品，对于程序员来说，成长不是很大。感觉就像小作坊。平时还是早点下班回家逛开源社区比较好。

其次，插件受制于DCC软件暴露的SDK。SDK没暴露这个功能的接口，咱就拿不到数据；SDK吐出一些乱七八糟的数据，咱就得绞劲脑汁地去洗，去筛。SDK就是一个黑盒，你完全不知道里面装的是宝藏还是屎。

在这里插入图片描述

所以开发插件要尽量少地依赖SDK。能自己存的数据，就别老是从SDK里拿。

插件开发的方法论与敏捷开发高度重合——以用户的需求进化为核心。
美术今天想要这个。周会上大佬们评估一下能不能做，能做，分优先级和划进迭代周期。以最快的速度做一半出来先。无视性能开销，无视交互体验，无视边界值测试。
快快速速地打个包，让美术试用，美术觉得爽了，这个功能就可以留下来了。
后续呢？
因为TAPD上还有大把单子没做完，程序员们需要先把其它单子做了。
那那那，性能不优化了吗？交互体验呢？——别的单子还没做完呢！

这样的好处是迭代超快。坏处是突发的bug很多，突然插进当前迭代周期的单子很多，性能就更没有时间优化了。当然，这些归属于程序员的开发节奏，由Topic Owner决定，属于“家事”。

但问题在于，在我们搁置性能问题和体验问题时，用户苦不堪言，我们的用户的信任正在被消磨掉。

问题的解决方法是良好的版本惯例和发布流程。不稳定的feature只开放给少数同学使用，减小bug影响的规模和急插bug单的数量。

我一开始做插件的时候非常纠结，因为我上一段实习养成的习惯是：尽量在一开始就把架构设计好。这就导致了我的产出很慢，于是美术的使用反馈就来得迟，迭代得慢，无形中会有工时浪费。

后来我学到了一门新学问：重构。
我应该根据当前的需求决定写下的新代码，而在能力范围内预判将来可能的其它情况。预判不了就不预判。
等到下一个需求提出时，我肯定会回顾旧代码。如果旧代码中存在“坏味道”，我就需要一边重构一边实现新功能。
这样的方法交付更快、迭代更快、且代码依旧能保持健康。