Winner Club项目总结（三）

       这应该是这次项目的总后一篇总结文章了，Winner Club作为三月演武堂成立来完成的第一个商业项目，于7月28日正式交付，项目组人员也在当晚进行了总结。

       下面是会议总结的要点：

1. 学长之后可能就不再参与代码环节了。

       确实这次学长参与了项目很多重要代码部分。比如小桑学长主要负责后端环境的搭建和一些比较难的接口的开发。腾飞学长负责了一些关键组件的开发。这几天我从一些书中也了解到在客户、项目负责人与程序员之间的分工，项目负责人正常来说是不负责代码的开发的。不过有了第一次整体的流程和项目结构，我相信之后我们就可以步入正轨。

2. 时间评估

       一开始我与小桑学长定的后端接口时间就是一个星期，大体的开发速度基本上和我们规划的一致，差不多用了6天就完成了第一版接口的开发，虽然部分接口不完美并存在一定的bug，但是没有影响、耽误前端的使用。但是前端方面确实时间评估上都有些失算，不过前端的难度也确实挺大的，因为界面要不断的修改完善。

       但是时间上的评估还是要精算（花一定的时间去计划、计算），否则一直延期是很不好的一件事。定的什么时间完成，就应该在什么时间完成，为此我们还熬了一次夜。

3. 可交付的认知程度

       我们以前做一个项目可能大多采用螺旋的开发模式，尽量为客户出第一版，项目整体的流程跑通，可以有部分不致命的bug。但是这次学长对我们的要求是比较高的，特别是对于前端，可以说是一直在改，一直在美化。可交付的状态在我看来就是可以交付给甲方进行商用了，正常情况下前后端已经是不能再出现bug了。

       所以要对自己的任务和整体的进度情况有清晰的认识。

4. 不要总看自己那一块，多交流，看总体

       由于后端在后期都只由我一个人进行维护了，所以后端交流的部分比较少，主要是前期和学长交流了一些参数格式和方法规范，后端的总体后期也是我一个人把控了。小程序界面是3个人开发，他们的交流是远多于我的，因为他们的页面相互影响，可能需要其他人所做的组件等等，所以要不断交流，我能做的就是在空余时间多去关注他们的进度，看能否帮上什么忙。

       关于看总体，我觉得前端的各个人员的进度要保证一致，不能太快也不能太慢，因为大多页面之间互相影响，所以前端一定要保证进度的一致性，即看总体。

5. 需求文档看仔细

       这个问题前端、后端都有，一开始过文档还是有些草率，部分情况没有考虑清楚，就例如后端最严重的问题就是文件存储的设计，一开数据库在这方面没有设计好，导致后期影响了好多的表，而且目前更改过的还不好扩展。前端的肯定也会有，但是更改起来相较于后端会轻松一些。

       文档如果没有看仔细，可能会多些一些冗余功能或者少写一些必要功能，这其实都是小事，要避免对其他模块的影响，和方便后期的扩展，反正看需求是十分重要的一个阶段，这是毋庸置疑的。

6. 代码质量

       可能这里又会牵扯到好多小细节，例如规范、可扩展性、可维护性、集成程度、耦合程度、设计模式等等。由于这是第一由两个学长带着做，所以代码质量这一关还是拿捏的死死的。后端我是写第一个接口十分谨慎，写完之后让学长看规范逻辑等等，又改了好几次后终于才算合格，之后的接口都要按着这个规范来。

       前端就更可怕，学长后期甚至把某一模块的代码全部重写，就是因为质量。前端还要将代码组件化，意“即插即用”的设计思想。

       总之功能不是实现了即可，要考虑诸多因素，这也就是为何技术越深反倒开发某一模块的速度相对较满（不绝对），因为要考虑的因素多。

7. 不断评估自己

       在做项目的时候可以反映出来自己的真实水平，借此也可以看出自己的不足，协作开发的时候也可以看出自己与他人的差距。那后端来说，搭建环境这块我确实比较弱，我需要吸收这次学长搭建的环境，相比学长的学习能力，我也是自愧不如。

       所以，在做项目的同时，也要不断评估自己，对比他人来找到不足。

8. 自己再封装

       别人写的好的组件当然可以拿来用，自己也可以对其再封装，我觉得这也是对应着java的三大特性。当然在我看来也不是集成度越高越好，能最优化的方便自己和他人才是最好的封装。

9. 可以将github上的开源框架拉下来，修改、提PR。

       其实之前我还真的不知道可以这样子做，知道这次项目学习了git flow流程之后才恍然大悟。学长同时也说如果自己代码有合进去，这对之后的面试是非常加分的，这不仅是对自己实力的认可，也能反映出自己对代码的理解与思考。

       但是这一项对自身实力的要求还是非常的大的，所以还是要不断提升自己才行。

10. 多看好的代码

       这一点很早之前学长就教导我们要看好的代码，但是我们可能最多只能看个规范，因为大多数好的代码以前根本看不懂其中的设计思想。目前我认为我要做的就是先吸收两个学长在项目中所贡献的代码，先把自己的代码质量向两个学长靠近。

11. 前端的分工

       这一块虽然这次我没有参与前端的开发，但是我也能感受到前端不好分工。这次我和小桑学长在开发后端的时候，几乎在代码上是0冲突，因为后端基本上都是面向接口开发，一个接口一个人，不同开发人员之间不参与他人编写的接口，所以后端开发相对独立。

       但是前端这一块我感觉无论是按页面分工还是按功能分工，都很有可能会造成两个人、或多人参与一个页面的制作，所以这次前端开发造成的冲突就非常的多，一定程度上也影响了整体的进度。

       让我们来分析一下造成的原因无外乎就是大量的代码堆积到了一个页面中。解决这种冲突的有效方法我认为还是组件化开发，一个组件仅由一个人开发，页面只是一个容器，去引用这些组件。

       通俗的来说就是，把一个页面分成view合component，view就像一个无限长的排插，component就是一个个的电器，他们就像是一个个的component连接/插到了view上一样，view的代码量很少，便于维护，而component仅由一个人开发，避免了冲突。所以说还是这种即插即用的思想，极大的降低了耦合，减少了冲突的出现。

       有关前端的设计模式合代码结构还有待细细挖掘。

12. 遇到问题的解决思路

       我个人觉得我自己面临问题时解决流程还是比较清晰的，如果我自己的代码出了bug，首先看控制台输出定位代码，再思考逻辑。还没有解决就开始调试，一步步定位问题。还不行就把错误复制放到百度上查，如果最后还没有解决就得问其他人了。

       学长建议的解决思路和这个差不多，不过在百度上查之前应该再加上两个流程，一个是看官方文档，看看是不是方法要求参数没有看仔细，哪里的调用逻辑或是配置有误，如果还是没有帮助再去所使用框架的社区或是对应问题的相关社区搜寻答案，最后再在百度上搜索（主要还是因为百度上的答案太杂，真正有效的并不多）。

13. 后端api要先开发出来

       这个又和我以前的认知大相径庭。学长说接口要一开始和前端沟通好，例如商量要写什么接口，这些接口要有什么参数，要先把接口定好，并让前端review，之后可能就不会在接口上出现协商不一致的情况了。

       而我现在开发接口就是自己先写，前端发现缺什么接口和说参数我再补再改，现在看来确实很不规范。

       这也就是为什么造成项目delay的原因大多数情况下并不是因为个人自身的能力问题，而是一开始前后端协商不一致导致后期的大改。

14. 联调

       我认为联调不应该集中到一个时间点整体联调，联调应该放在平时，小规模的联调可以在平时就发现彼此之间的问题。如果所有模块都堆在一起集中联调，有bug基本上是100%的，而且还有可能因为某些前置bug导致某些隐藏的bug无法发现，进而导致下一次集体联调又出现bug。

15. 卓越的工程师

       一个卓越的工程师不仅是技能过硬，同时也要能够把控总体。我认为前端这次缺少的就是一个能够把控整体的人，缺少一个可以做领头羊的人。一个卓越的工程师在自己模块开发过程中，要不断联系项目组的其他成员，统计进度、做总结，及时发现问题、更改计划等等，简而言之就是开发组的组长。

16. 做一个靠谱的人

       这也是学长最后一直强调的事情——做一个靠谱的人。这可能要从多方面考虑，首先在项目进度上不能掉链子，自己的模块不能出问题影响整体。其次自己要对自己的代码负责，就像上面说的代码质量，不能做出结果就完事了，不仅自己要便于维护，以后也要让他人便于维护。如果自己的模块真的出问题了也要能快速反映想到问题所在并及时解决，这一点前端后端都要具备。

---

       最后，还是腾飞学长的那句话：以目标为导向，承诺即交付。

       不是面向需求开发，而是面向需求变更开发。（玉宝学长）