大型web项目研发的反思

亲爱的小伙伴们

不知道最近的技术分享有木有

让大家收获满满思考多多呢

但其实在实际的业务中

不仅仅需要技术的提高

好的团队合作开发模式也会事半功倍~

◆◆◆

今天就请出我们部门

去年刚刚升级的超级奶爸

——‘天奇爸爸’童鞋！

为大家带来敏捷开发方面的「小心得」

近一年内我们经历了两次大型web项目的研发。20个前端,30个后端开发了4个月，10多个测试人员测试了两个月，当然还没包括这个企业级产品和周围产品的联调测试。前端项目里面不包含库文件有353个文件夹、1218个文件、276163行代码。

两次项目开发中历经的重复、混乱、无序，让人抓狂的同时，不得不让我们开始思考软件开发中的一些方法论。

读了Martin大叔的博客和敏捷开发序言尤有感触，列举下来和大家一起反思。

持续发布

结合项目，个人认为持续地发布项目应该是持续地让大家看到一个当前的软件成果。看到成果后，团队沟通项目进度、让每个人意识到当前情况。主要有以下开发流程改进：

►持续发布、让更多人知道项目进度、每个人更有全局意识、主人翁意识（痛点：每个人只知道自己的小模块的进度，其他部分很少知情，协作能力比较差）

拥抱需求变更

我们平常开发的时候经常会听到软件开发人员吐槽需求又变了，甚至津津乐道程序员挥刀产品经理的新闻典故。在现今信息爆炸的社会，瀑布流的开发模式早已经步履维艰，拥抱变化、适应变化的敏捷开发模式才是正途。

►对产品的需求变更要做好心理和技术准备(痛点：项目里产品变更很令人讨厌，多次的需求变更后，代码一团糟、到处是补丁。我们要做好测试、不断重构、接纳和适应需求的频繁变更)

业务和开发要协同工作

我们项目开发过程中，开发人员很多对业务不了解，甚至到后期对自己做的功能也不能说出个一二三四。

►更多的要求懂业务人员的进入，开发人员和业务人员频繁沟通。不懂业务，怎么可能写出稳定、灵活、易于维护的代码呢？自己写代码的时候，心里都犯嘀咕，这样可不行。

►项目初期关键开发人员参与需求讨论环节，最终形成的PRD文档需要产品宣讲需求，使所有研发人员与产品理解一致。

信任每个人

敏捷开发里还有一个说法要面向人编程。在有些管理者的眼中，人就是一个螺丝钉、可以随意替换（泰勒管理法）。但是，许多历史和现在的事情告诉我们人的主观能动性特别大。好的装备到精神消极、涣散的人手里和到斗志昂扬的人手里有天壤之别。

►尊重每个人的想法、激励每个人发挥自己最大的主观能动性。

►鼓励团队成员完成研发任务，奖惩相对存在。

简洁为王

在物理研究历史中，有很多复杂的理论来描述天体、宇宙，最后牛顿三大定律、爱因斯坦质能方程式这些简洁的方案被证明才是正确的。数学之美中吴军博士说过他在google的领导信奉：ak47理论，好的东西大多是简洁的。

同样我们的项目里面，复杂的代码、逻辑最后被证明充满了bug、难以使用。

►我们写代码的时候，重构的时候，看到复杂的逻辑都需要三思，且选择适合的重构方案，过度重构增加研发复杂度。

定期反思改进

项目开发中，每个人都埋头写代码，到最后一沟通发现很多重复的地方不同人在重复实现。

►好的项目开发流程中，应该有一个人不停的了解每个人的进度、代码。在每个开发者之间建立沟通，及早发现重复代码、让项目有机集合。项目开发中好的想法、方案及时沟通普及、开始执行。

►项目初期或过程中对整体系统熟知，提取出公共组件进行封装使用。

综述

实践证明：写好测试、频繁重构、适应持续的需求变更是通向高质量软件的必由之路。

很多公司的软件开发历程表明：缺乏测试、缺乏重构、抵触变化的软件最后都是一团糟，不得不完全重写。

希望我们在开发过程中画好测试->开发->重构的开发圆，提炼出越来越高质量的代码、减少加班、提升代码知识含量。

好啦，今天的分享就到这里啦~

小伙伴们有任何小心得

也欢迎留言与我们讨论互动喔！

◆◆◆

请大家持续关注我们的公众号

我们会不断地分享更多有趣的干货~

笔芯~