前言
我们做程序员的有时候总会想着是不是有一些捷径能够快速成长，希望自己突然某一天就得到了九阳神功之类的东西，突然顿悟就成为技术大牛了，我以前也经常这样想，但是不幸的是，过了这么多年，我仍然没有找到这个捷径-_-（小说果然都特么是骗人的）。不过摸爬滚打这么久，捷径没找到，倒是让我找到了一条笨路，所以我这里想告诉大家的是一种笨方法去成长。
什么是主R
大家其实都知道，在做项目的时候，是成长最快的时候，那么如何在项目中将这个成长发展到淋漓尽致，这个是我想说的一个核心点。
我们一般称呼一个项目的整个负责人为主R，那么我就如何做好主R说一下我的理解。 简单来说，项目分为如下几个阶段：
需求分析 -> 方案设计 -> 开发 -> 联调 -> 测试 -> 上线 -> 后评估
成为一名合格的主R，其实就是要把整个项目生命周期的每件事儿都做好就行了，有一定经验的小朋友肯定会吐槽了，你妹的说着简单，做起来可没这么清晰了。所以这里我针对每个阶段要做的事儿都做一下说明，其实总结起来核心就一句话：在不同的时间点，满足不同的人对不同的事儿的诉求。
需求分析阶段
需求分析阶段，我们要搞定的人是谁？是业务方和pm，这个阶段我们需要弄清楚业务方的真正诉求的来龙去脉（即做这个事儿的背景），要搞清楚pm的产品是否真的能满足业务方的诉求，同时我们还要多问一句，做完这个事儿， 我们如何评估做这个事儿的效果，这个事儿是不是真的有意义或者有做的价值。这个阶段我们一定要把需求揉碎了看，想清楚每个细节点，跟pm和业务方确认清楚这个是不是真正是他们想要的，只有大方向理解一致了，最后的结果才不会出现太大偏差。我见过很多在需求分析阶段没有做好（rd理解的和pm理解的完全不是一个东西）而导致做出来一个四不像东西最终返工的例子，所以在这个阶段一定要多沟通，把要做的事儿确定好。有的程序员会觉得，我就是一个需求实现人员，我有必要了解那么深的业务么？我有必要去关心产品出的方案是不是合理么？这里我想多说两句的是，你有这个必要，并且非常有必要，我们是程序员，但是我们并不仅仅是一个代码翻译器，如果连你的业务都不理透了，你何谈架构，如何能拍着胸脯说我设计的就是朝着未来更正确的方向去走呢。我一直以为，程序员其实是应该比pm更了解业务的，并且应该不断的能协助pm提出一些更有价值的东西的。
方案设计阶段
方案设计阶段，这个阶段我们要搞定的人是和我们配合的前端，后端人员，我们需要对比现有系统，一步步想出实现需求的各个要素，过程中可能会不断的找pm确认一些细节点，直到整个方案出来为止， 如果觉得方案不太尽如人意，或者思路不太清晰，可以找你的leader协助给你一些指导性的建议。 确认好方案之后，我们需要搞定几个时间点，前端，后端开发何时开始，何时联调，何时提测，qa的排期及上线时间，提前要出这几个时间点是很重要的，避免出现多方开发完了，结果有某一方说还没排期的尴尬情况发生。
开发阶段
开发阶段，这个阶段每个开发都很熟悉，那么这个阶段我们要搞定的人是谁呢，是我们自己以及配合我们做项目的各个业务方开发。我们需要在几个时间点去确认项目各个业务方的开发是否按部就班的进行着，一般是项目三分之一的时间点，需要跟进一下各个业务方进度是否如期进行，项目一半时间的时候再次沟通是否正常，项目联调前一天再次确认是否能如期进入下个阶段。如果在这个过程中哪个环节进度不佳，要及时沟通原因，这个时候就需要自己多去了解一下对方的一些实现方式之类的，一起协商一下解决方案以保证项目如期进行（这个沟通过程很重要，是自己不断成长的最主要因素，因为不断跟各方沟通，你会不断了解对方的一些思维方式及实现方式，不要怕因为自己不会就不去沟通，不去问，我们要做的是只要自己不懂的 ，就要多问，直到搞懂了。慢慢的你就会发现你懂的越来越多，自己的认知边界也越来越广，跟各方配合起来也越来越得心应手）。这个时候会有人问，如果我很多时间都耗费在了协助其他人解决问题上，那我自己的时间是不是有可能delay呢？对于这个问题我是这么看的，每个人的成长都是由不会到会的过程的，在你初次跟别人配合的时候，可能确实很难，并且想搞清楚问题在哪，如何解决确实会花费大量的时间，那么我们要做的就是在前期时间预估上给自己多预留一些buffer，一般我会让经验不足的人预留出20%的时间buffer以应对这样的事儿发生，虽然前期会很难，但是当你每次都这么协助别人处理好各种问题的时候，你对各个不同环节的理解就越来越深（前端，其他业务方的业务等等），并且很有意思的一件事儿是，在协助别人处理问题的时候，有时候你会发现别人的设计或者代码风格很nice，这个时候你会能从他们身上学到很多不一样的思路，这就相当于变相的学习了其他人的优秀代码一样，这对自己的代码能力的提升也是巨大的。所以我是很希望大家能把这个过程做到极致，多参与一些优秀的设计等，为自己未来能做出更好的系统打下坚实的基础。慢慢的，自己的能力提升之后，你的效率都是随之会提升很快的。这个过程中还有一个问题是开发人员比较困惑的，在做一个需求的时候，要不要把改这块代码涉及到的主线逻辑，以及所有其他支线细节都抠一遍，因为也是一个比较花时间的操作。我的看法和刚才说的答案一样，还是有这个必要的，每个需求做的时候，把所有主线及支线逻辑都梳理一遍，会进一步加深自己对自己系统的理解，同时有时候会突然发现系统里哪个地方是不是有什么问题，能刚好在梳理的时候及时发现并处理。其实改bug也是如此，我们常说，改bug是理解系统最快的方式，就是因为改bug的时候我们应该把调用方的整个主线支线都梳理清楚，而不是简单的改完这一行代码就完事，那对自己的成长并没有任何益处。
联调阶段
联调阶段，这个阶段要搞定的是联调的前端后端人员，当联调出现问题的时候，一定要主动协调各方解决问题，从协调的过程中，你会了解到不同人的做事儿方式，也会了解到你自己系统的边界能力以及可能以后会出现的问题，这些都是比较宝贵的经验，长久积累下去，会形成质变的。在这个过程中，有时候会碰到一些边界不太清晰的问题，会出现一些你做或者我做都两可的事儿，这个时候，沟通的双方最好将利害关系讲清楚，首先以肯定的态度认可这个事儿是双方都可以做的，然后看对方做的话代价及成本多高，综合考量之后，再协商出一个合理的结果，有时候适当的牺牲自己的一些时间去承担这个事儿得到的可能是长远的一个收获。 在这个阶段我们重点关注的时间点是联调的进度是否符合预期，必要时候需要采用每日站会的形式花五分钟让大家都知道现在的问题以及需要解决的问题。那么这个阶段要搞定的几个时间点就是联调过半及提测前一天。
测试阶段
测试阶段，我们需要提前将测试用例进行评审，指出测试用例中不满足要求的地方，以保证测试的覆盖程度，这同样是对自己的一个考验，需要你考虑清楚整个系统做完之后，哪些地方是边界，哪些是重点要测试帮你把关的地方，哪些细枝末节测试可能没有考虑到。在这个阶段，需要我们更主动的跟QA同学做配合，以保证项目的一个质量。同时这个阶段需要我们卡的一个时间点就是上线前一天，因为可能需要我们在上线前将上线前要做的事儿提前做了。
上线阶段
上线阶段，我们需要按照我们的上线步骤（不仅仅是自己的，是相关所有前后端的上线步骤），一步步发布上线，同时观察线上服务日志看是否有问题，上线之后，可以在隔离的环境对结果进行一些正确性校验，以保证上线的功能是没问题的。
上线后评估阶段
上线后评估阶段，这个阶段需要我们看到上线前的一个效果，同时也要观察上线后的效果对比，不断的跟进，看是否达到我们做这个事儿的预期，如果没有，那么就需要反思是什么原因导致没有按预期出发。这个过程是对我们做的事儿的一个检验过程，以及是一个对自己肯定的过程，在不断做正确的事儿的前提下，也能极大的提升自己的信心以及对自己所做的系统的信心。
总结
总的来说，在上面所列出的这些步骤里，每一个步骤都做到极致的人，他的见识，对系统的理解，对边界的判断，对时间的预估，对人的理解都会处于一个一直上升的过程，那么当积累到一定程度之后，质变只是一个必然的结果了，成长为一个合格的程序员也是一个水到渠成的过程了。
上面啰嗦了这么多，最后我这里给总结一个比较便于大家实施的表格，由于本身是一个顺序的过程，所以不会出现并发的问题，一个个阶段屡着走就行。
image.png
最后预祝大家都能“快速”成长为大侠~
网友评论