扫描器需求——产品的核心目标
今天晚上讨论下个季度扫描器的需求。
0x01 要重构么？
重构前提
- 扫描器可读性较差，当初理解的时候看了一两天理解了大致的流程。之后在写功能的过程中，又在一些地方卡住了。
- 另一方面，是代码耦合性太高了，程序运行依靠redis、celery、管理平台的任务功能、插件下载平台，和其他东西耦合性过高，无法单独抽出来，在第三方服务器或者外部服务器部署。
- 想要向业界开源，拆分模块化和降低耦合性又是必须的。
- 同时扫描器的主要流量来源——镜像流量即将流量翻倍，提高效率压缩性能又是必须的。
不确定的需求
但是在定KPI之前，准备开始写重构相关，整理需求和设计，开始第一步，必要性，又否定了一些东西。
- 可读性较差，但是目前开发人员较少，掌握了就行，没必要面对很多人，让大多数人都读懂。要开发与接触的人员钻研一下就OK了。
- 这点是好的
- 关于提高性能，看了一下上一版扫描器的详细设计文档，其实需求都一样，提高性能与扩展性。其框架，我没有经验和把握做到设计重构确保性能更优越、框架更完善、代码更简洁。
渐渐有了这种想法，是上个季度，想要重构镜像流量的去重程序。经过一番设计，发现上一版的设计其实挺完备的。而重构再与其他部门的合作，开发过程拖沓，寄希望于其他部门的优化，但是看情况等不到了，等于重复造轮子，还不敢肯定新的轮子更有解决问题的能力，做出来的是单车变摩托还是摩托变单车。
讨论
最终寻求讨论。讨论当下扫描器重构的需求与设计。需求是拆分模块化。但是又发现拆分模块化的作用是开源面向业界，同时提高可读性，并没有实质性地提高产出。
而提高性能，又不敢肯定能否提高、提高多少。
吃一堑长一智
还是上个季度，经过某些坑，发现重构也并不一定就是好的，所以开始前先做了必要性的探索。
经过一些坑，总会学会点东西。D拿的也还有价值。
0X02 产品的核心目标
漫漫讨论
经过几人坐下来漫漫讨论，从扫描器的重构必要性（此时的重构理解为推倒重来，而不是调整），到管理平台的重构必要性。
如果只是几个问题，能够花费一些精力解决的问题，同时代码中存在冗杂、代码由不同开发人员编写风格不一，着重解决当下的问题，也不失为一种更好的方法。
重构完的代码，并不一定比现在的好。
回归到产品的核心目标
扫描器的核心目标是什么？或者说什么是最牛逼的扫描器？
扫更多的漏洞，准确率更高，漏报率误报率更低，性能更强。对于插件开发者，支持更多。
而当下提出的需求，比如测试人员编写插件的赋能，只能算锦上添花，并不是雪中送炭，并不能实打实地实现扫描器的核心目标。这种事情，最好等到扫描器的已经很完备了再做。说实话，就是有点花里胡哨。
什么是你心目中最牛逼的扫描器
什么是你心目中最牛逼的扫描器？在头脑昏昏的最后，leader问出了这样的问题。是的，什么是最牛逼的扫描器，现在做的是走向那条路的需求么？
现在做的更像是收集别人提出来的需求，模糊地排出优先级，优先级中更多的掺杂了个人的兴趣，以及需求的难以程度。
一个产品角色，应该像一个将军，有明确的目标，攻这座城，就专心攻城，不是在他人的言语中，再选择扎营种田，畜牧养禽。
0X03 产品分析——思路拆分
说起来一点就通，但身在此山看不到。
一个产品，要做的是什么？
划分出几个想要实现的点。
对于每个点，怎么衡量？
对的，怎么衡量一个点，就针对衡量的标准，怎么去提升这些标准，再往下细分。
过程——暂时留白
最后根据人力以及优先级，从中挑选重要的点、痛点来做。
0x04 额外感悟
心血
额外说一点，这应该当做自己的产品，投入其中，自己想要的是个什么样的东西，而不是别人想要的是什么样的东西，帮助别人完成他们的需求。
猪、鸡和鹦鹉的故事
在一片神奇的丛林里,生活着许多动物,其中有猪、鸡和鹦鹉。丛林里最近掀起一股创业的风潮,这些动物也受到感染,每天搞头脑风暴,琢磨如何创业。最后它们决定合伙开一家欧式早餐店,供应面包、牛奶、煎蛋、培根等。
具体分工如下。
猪:提供猪肉,做熏肉。
鸡:提供鸡蛋,做煎蛋。
鹦鹉:提供咨询,每天阅读大量博客,给其他团队成员提供建议,例如业界最新趋势、最新术语、Saas, N-层架构、创业明星当年的轶事,等等。
这次对三个动物的负担是一样的么?它们又该各占多少股份?一旦创业失败,猪、鸡和鹦鹉各自会失去什么?
在一个团队中,不同的成员来自五湖四海,为了一个共同的目标,走到一起来了(至少表面上是这样)。在一起吃饭时,大家意气风发,群情激奋,但是不同的人对于团队的承诺是不一样的。
有些人是猪-他们或者辞掉了工作,投入到创业中;或者这门软件工程课是他们的必修课,他们一定要拿到高分,才能提高自己的绩点(GPA) ,申请到好学校。对他们来说,要想项目成功,就要拿出自己身上的肉,背水一战;一旦失败,自己的老本也赔进去了。他们的投入级别是-全身心投入(Committed) 。
有些人是鸡-他们能做重要的贡献,但是项目一旦失败,他们的损失并不大,他们的生活还可以继续下去。比如,有些人平时自己上班,周末来给项目帮忙;或者是选修软件工程课;或者他们已经保研,只要这门课混及格就行。他们的投人级别是一参与( Involved )
有些人是鹦鹉-他们有漂亮的羽毛,能说会道,人脉广,能提出很多建议,很多点子。但是他们不执行,除了一些人云亦云的观点和关于架构的空谈之外,并没有其他投入。一旦项目失败,他们就会飞到另一个项目中去。他们的投入级别是—围观(Bystander)。
这是今天看重构时发现的一本书 《构建之法》中的说法
负责项目的，更像是猪，负责抗雷。参与的，是下蛋的，从中学习、投入，有别的项目的保障。提需求的，是鹦鹉吧。做与不做，都不会影响，有时候还会导错方向。
