科学分析方案文档优劣猫会喵，狗会叫，鸡会做什么？机会是留给有准备的人的。先说一点（？），当我们的需求或者项目出名，别人需要学习而你需要给一波装逼的时候，丢个图文并茂的设计文档。肯定比丢一个代码仓库更让人佩服吧？还是老实说，回去rankreview的时候，怎么设计一个复杂的需求，都想不起来了，还得画流程图贴代码贴效果……（嘘！）先说控制。对于个人成长的意义，前面我们提到了前端最大的优势——所见即所得。要说这个入门门槛确实不低，比起client的编译，动不动就抽根烟（目前我们client编译需要一个小时，一包烟就抽完了）。服务器的部署需要上云端，前端的试错成本太低。这是一个巨大的优势，尤其是在试水的时候。如果把一个模块的开发比作一道考题，我观察到有的同学（当然也包括我自己）写几行就切屏看情况，但是就像是先写完再推标准答案一样线同。我得到的是一个非常零散的想法。长此以往，没有经过一些“服务端”的锤炼，对于更大的模块或者复杂的场景，很难在脑海中形成比较清晰的反应。技术方案可以在一定程度上起到逼迫大家写前思考的作用，弥补这部分的练习。时间长了，好像发现自己可以在脑海中推导出整个代码的运行状态，这样bug率自然就降低了，也更容易做出一些前瞻性的设计。当然，我最初的想法是给以后维护代码或者需求或者解决方案的人留下一个好的设计文档，让他们知道原来的开发者是怎么想和设计的。以及哪些隐藏的问题可以从文档中得到解答，让开发者的精神负担更低。但是最近一段时间的思考和询问，让我觉得有必要把上面的问题说出来。但是是否需要先写文档再继续开发，我觉得要看具体的落地场景。试错俗话说，小船容易掉头。相信大家一定有过这样的经历：比如我们需要写一个精致的多模块、业务重的组件。一开始模块划分很合理，状态传递也有条不紊。然后QA提出了一个错误。X条件下，X元素的位置没有对齐，所以需要给某个子组件添加透传链接，或者子组件需要一直开回调到顶层等等。或者你设计了一个完美的组件，然后PM说，我需要在X条件下在X坐标处增加一个X元素位置，在接下来的一个月增加Y,Z,α,δ……的当然，这还不错，更坑爹的是可能开发到最后才发现，嗯？？为什么我不把这些成分提取到一层，让他负责XXX，然后把XXX集中在XXX里面呢？------算了，来不及了，等下一次重构吧，下一个需求就是重构，重构那么多东西成本太高，PM不会答应，就这样吧。我有更好的idea，但是受时间和工期的限制没法动用，只能在网上体会被迫打patch的感觉。相信我，这可不是什么好感觉。打开甲壳虫看onlinebranch，序列号都快四位数了？该解决方案可以很好地避免这一切。比如在解决的过程中发现了这个问题，可能不是在模块设计阶段，后面会往更好的方向设计，或者换几张图就可以了。.因为我们还没有进入Coding阶段，一般不会有大规模调整的风险。即便有，如果在项目前期称之为“风险”，到了项目后期就会变成“事故”。当然，文档不是万能的。我相信这个世界上没有一劳永逸的事情。但我相信这样可以避免大部分这些问题，而且能减少多少会随着代码控制的提高而增加。如何做到这一点将在下面描述。回顾沟通成本和内存成本随着业务复杂度的增加，单打独斗的项目会越来越少，更多的项目会需要大家合作（后端合作也是合作-no），而且很多时候会随着时间的推移，加入进来，共同发展。这时候有文档介绍给新生，至少能省我70%的舌头。（尤其是我们作为开发者口才不是很好的时候，没人愿意整天跟新同学解释。）一开始，把所有的东西都写在文档里，短期内的确会提高交流，但是随着开发进度的不断加深，中途，当大家的记忆开始逐渐衰退的时候，一开始写的计划的唤醒记忆的效果就会逐渐凸显出来。代码之外的额外信息（我认为目前最重要的部分）从代码中，大部分时候我们只能看到他做了什么，但“不该做什么”其实是非常重要的信息。比如有时候你看代码的时候可能会想，为什么不在这里做一个缓存呢？为什么不在这里添加回调？这就是为什么……不该做什么不能通过代码本身来传达，但如果在场景中进行了讨论，它就会被记录下来。这部分疑惑可以很好的解答。并且还可以在方案中说明自己设计的动机，不仅是what而且是how，以加深参与学生的理解，减轻本学生的心理负担。这样可以防止你设计的很漂亮的模块被前来应援的同学胡乱加个跨组件回调，然后被后来入职的可爱新同学滥用，变成狗屎山。写这个的时候，只有天知道我在干什么。现在，天知道一个套路文件解决方案（当然这是我的套路——一家之言）其实这也是一个文件，还可以show我的性格和风格比较洒脱，（你以为我在瞎写？其实我在瞎写，瞎写没有负担。jpg）scheme文档通常包含一些必要的信息。只要信息到位，章节标题我想你可以为所欲为。简单来说就是：我想做什么，我该怎么做，我为什么要做这个（我为什么不做那个？）当然，我更关心的是：你有没有什么陷阱需要标记。那我们就来说说这几个部分应该怎么展开。我应该怎么办？在这个阶段，我想称之为需求分析。随着我们水平的提高，承接模糊需求的能力也需要提高。明确新阶段的产品需求，产品：“copythis”，这种需求肯定让我回头。（其实我恨不起来，都是因为于哥）。但是很多时候，对于一些复杂的场景，产品本身是hold不住的，会提前联系一些技术同学进行预研。我们需要将产品不明确的需求转化为清晰的需求，进而转化为技术描述的需求。小枫走之前，经常问我一些问题，大部分都是这样的。当然，我觉得我锻炼得很好。比如“copythis”这个需求，我们可以通过进一步的提问来获取更多的细节（其实我想了想也没做好，我说的大部分是你可以做调度，但是在事实上我也不知道。)，到诸如“你想复制他的布局机制吗，因为这个机制有这样的优点和缺点，我们可以这样做，你觉得呢？”这时候，我们的等级就会上升。也可以更好的让我们有更多的机会去接触产品设计，让技术更多的融入到产品中。这个过程一方面是帮助产品明确自己要什么，另一方面是帮助你降低后续的风险点。在拆解了技术点，明确了产品的需求之后，我们需要将产品需求转化为可以用技术来描述的需求。并且优先考虑，一些需要取舍的场景可能需要这样。以奢侈品的筛选需求为例，大概可以分解成几块。产品要通用筛选组件（基本能力）。产品想用这种通用能力做很多事情。希望能做好配置，提供解决产品各种奇葩需求的能力。.（明确要做的技术点）我怎么做，我为什么要做？（上）一般来说，写项目文件有两种情况。我基本上有一个比较清晰的想法，我需要证明它的可行性。我是谁，我在哪里，我为什么要接受这份工作？你怎么做这件事？不知道！对于第一个，我觉得我在思考这个问题的时候已经有了一个大概的思路，接下来就是在纸上推演，避免落地后翻车。这个暂时不展开，以后再说。对于一个无从下手的计划，我应该如何制定第二个解决方案？我觉得应该有这样一个板块：【方案思路】怎么说呢，我在写方案之前肯定是没有任何想法的，但是随着这个板块的讨论，我的思路会逐渐清晰，我充分明白我应该做什么！（其实这一步我没经历过，后续的技术需求可以这样搞。）梳理核心环节，大部分研究需求都会涉及到一个“如何打通XX”的问题，而大多数这些要求可以概括为一个或多个。核心环节，则围绕着如何保证核心环节的顺畅运行展开。所以对于这种需求，第一件事：先画流程图。以我之前做过的停留天数为例——需求是停留天数，停留天数是怎么计算的？这组链接是什么。如果要进行多端适配，那么每一端的链路集如何打通呢？组件设计方案不一定有这么突出的流程图，可能更注重模块划分。例如，一个更复杂的页面有20个组件。说是相互独立却有着微妙的联系，但即便如此，也不是没有核心环节，可能需要细化。（这一点在郎君多次希望zzui能提供一些组件时就可以很好地体现出来，我们不能告诉郎君我的需求是什么，而是需要细化，我需要zzui提供什么样的组件提供？组件，它需要什么样的能力，什么样的API给我使用。）里面可能还有一些经验判断。如果你不确定，我想你可以把它扔出去讨论。举个例子，比如筛选组件，核心在于——多个组件之间的联动和数据分析。比如停留时长，核心在于——计算出来的数据应该在什么时候发送，数据如何保存。当然，这也伴随着多端兼容问题筛选组件的核心链接细化过程。核心环节确定后，还需要进一步细化。如何细化？-通过问自己。和一个大佬聊天的时候，听到他讲了一些信息论的东西。给我印象最深的是：“信息就是不确定性的减少”。这意味着什么？比如我现在有一个比较复杂的需求，还需要服务端同学的一些能力。我需要看看手头的资料，然后整理一下，问问自己这样做有什么问题。（主要是目前时间和思路不够）比如前期：需要用到一些奇怪的知识点吗？比如webRTC，webSocket之类的，不知道？该怎么办？，在解决方案中标出我不会（再学习）比如使用第三方库或解决方案，如何使用？不知道。得去看看如何连接到服务器？不知道，要问服务器端的兄弟或者让他们给文档。然后我问了上面第一轮的问题，第二轮继续问自己我和服务器的连接是否稳定？如果连接断开，网络断开怎么办？服务器和RTC是否稳定？？类似这种问题，当然第二点好像不需要我太在意，但是我觉得还是问比较稳妥。万一你问服务器端的同学这个问题，可能他们没想到，但是你提醒他们以后风险是-1，那你可以换个方向问问会不会出意外在前端需要处理什么？服务器端会不会有什么意外需要我去处理？这些问题将引导我们进行更完整、更强大的设计。还有一些一般性的问题。如何设计此解决方案的API。如何让别人使用，访问成本更低？如果计划太复杂，这个计划会行不通吗？我应该放弃这个想法吗？类似的，简单来说就是不断挑自己方案的过程，用一轮又一轮的坏case来恶心自己，看自己的方案能不能撑得住。就我之前久留的经历来说，我很害怕一步一个脚印看到一步一个脚印的实现。一遍又一遍地写却遇到各种问题，代码又是一遍又一遍的改，然后我根本不在乎代码是怎么组织的，只想快点完成这个任务。经过一轮又一轮的“反省”，我们会发现一系列不确定的事情正在逐渐减少。以前，这些我们不了解的点，在项目的中后期都会作为风险出现，而这个项目可能会比较稳定。许多。我倾向于以问答的形式保留这些问题，以确保它们可以得到回答。当然，我正在参加最后的质量检查会议。当然，并不是所有的问题都能得到解答。如果解决不了，那就只能找leader或者扔出去讨论了。最终，所有的疑问都得到了解答，还是有一个临时的方案，将其替换掉，不至于惹出麻烦。那么这个计划几乎是离不开的。那我觉得就进入下一个阶段，模块设计。我要做什么，我为什么要这样做？（下）同一个标题被使用了两次，因为这两个部分经常混合在一起或者至少是有联系的，所以大多数时候它们是一起写的。至少那是我似乎一起写的。比如我可以直接按照方案思路形成一个完整的模块划分方案。模块划分到底是什么？思考部分的前半部分其实是挖掘需求的全貌，减少不确定性，提升技术。这里的模块划分更倾向于代码组织，以保证良好的设计和可行的实现方式。比如在思考的部分，我们发现要做的事情是A，B，CDEFGH。这就需要把这些事情都做完，基本上这个大需求就稳定了。但是在地面上，肯定不可能把功能集塞进一个文件就完事了吧？其实我们需要逻辑上的划分。我们把每个模块都看成是分配一个worker，然后我们需要把前面的ABCDEDF分配给这些人。怎么分呢？这非常有艺术性，根据每个项目的具体情况，侧重点有很大差异。这个只能具体情况具体分析。比如对于奢侈品来说，大部分的能力都是通用的，那么奢侈品的组件就需要尽可能的通用。但是游戏的需求可能会越来越灵活，进程越多，他需要的组件就越灵活，等等。并且要保证一些指标，比如现在说的加载速度优化。（之前设计筛选的时候没有考虑到这一点）模块划分需要多细？其实把一些主要的大块拆开维护一下就够了。我们的需求并没有那么离谱。还记得我几个月前提到的组合API吗？拆开挂钩，同学们！从纸上谈兵到运筹帷幄，其实说了这么多，也是纸上谈兵。对于之前踩过的坑，我觉得可以提供一些思路。QuickUnfold首先，写入方案不是线性的。并不是说等idea完全完成了再去写plan，因为前面说的试错，其实plan上的翻身成本还是挺低的。先列出一堆问题，然后一个一个解决，记下来。其实计划写了一半。高效沟通图片>>文字我们都知道视觉传达比文字更容易理解，所以多引入图片，少引入直接代码，可以帮助别人理解你的解决方案，好的图片也可以更好的组织自己的语言。这也是为什么我觉得用Fei写文档会更好，因为dashen的绘图体验真的很差。太糟糕了！这里其实有题外话。以前画画的时候觉得很有负担。例如，流程图必须以圆角矩形开始和结束，以及菱形判断节点，不管怎样，我觉得关键点应该是抓住了核心：传达信息，只要你想传达的信息传达到位，图片其实丑不丑也没关系。而且在没有紧身的情况下画图真的很快。我原本以为我上一个示例文档中的3张图需要几十分钟才能画完，但我在10分钟内画完了所有3张图。如果不是正式场合，我想大家可以随便画这种不标准的图，只要意思到位即可。没有必要有那么多的负担。色彩的运用（意境）如果画画时有什么重点，可以利用色彩的变化来解决这个问题。（当然，我觉得这个可以作为排名评价的一种手段？？）我觉得效果还是挺明显的，但是这里有一点，颜色要相对少一些。因为都是优秀的=没有一个是优秀的。回收验证完成，方案制定完成后，方案不扔。我觉得我们应该在合适的时候打开计划，看看我们当时是怎么想的。一开始我讲的故事的答案？您也可以在开发过程中验证自己的程序设计水平。设计模块是否如期落地？差别有多大？为什么？Selectivewritingscheme/reuse不需要为每个需求都写一个scheme。我觉得没必要1、2天写一些小需求。解决方案应该是对应的，当你拿不到需求的时候，需要写文档，知道应该分模块什么模块，怎么写。当PM反复迭代设计文档的内容时，我们应该基于文档进行维护，而不是重写。这样在重组的过程中也可以更清楚的了解这套需求是如何工作的，并且在反复修改方案的过程中，也可以知道在重组的过程中如何重组项目未来。（找优化点进行优化，能不能更自动化。。。）总结--设计阶段--明确产品需求，背景和原因。我们究竟需要做什么来满足这个要求。梳理一下核心环节，这套实现的核心环节流程是什么。让我们细化链接的每个节点，特别是我们需要如何实现这个节点。--项目组织阶段--将各个节点的抽象逻辑提炼到模块图中。我们如何组织这个节点。解决方案不是一蹴而就的，可能是随着你的开发一起写的。开发完成后，回去拿方案验证落地效果，有没有偏离方案，再去修改方案。这是一个存根文档。当此需求有迭代或功能添加时，此文档是您下一个计划的起点。PS：如果过程中遇到各种意想不到的问题，或者一些不寻常的坑，记得做笔记。不仅如何，而且为什么，什么样的需求需要文档？比如：这个需求需要长期维护，有一定的复杂性，他不容易直接从代码中看到整个需求的全貌。这个东西需要提供给第三方。这个东西需要所有端的配合，依赖于业务端技术之外的其他关联，比如中端搜索。就这些啦~有什么问题可以一起讨论。我只是在这里给出我的一些想法。我不能要求每个人都写文档。我提出了一些问题并提出了这个解决方案。希望大家在遇到上述问题时，可以使用解决方案文档中的解决方案来解决。一项艰苦的工作！希望大家放轻松~~
