开发经验总结
主要从两个方面总结：开发者角度和PL/PM角度，随着技术发展很有可能会脱离大潮流，所以随时更新
常见开发流程
常见的开发流程：
- A：理解需求-写基础设计书-写详细设计书-编码-测试。
- B：理解需求-写基础设计书-编码-测试。
- C：理解需求-编码-测试-补设计书。
- D：理解需求-编码-测试。
- E：理解需求-编码
正规的开发流程A；有些开发者觉得麻烦，不想写详细设计书，所以就出现了B；C是在B的基础上开发周期短，着急出产品；D是在C的基础上人手不足，项目多，没时间补设计书；E是在D的基础上，客户同意先上线再慢慢更新版本修复bug。
这里解释一下上面提到的基础设计书和详细设计书：
基础设计书，就是要件定义，项目整体是什么样子的，各个页面包括那些部分，哪些是共同部分，具体操作以后会产生什么结果；实例：header+siderbar+footer+页面，除了页面之外都是共用部分，header中包括公司的商标，点击回到主页，和用户图标，点击弹出退出和设置的model，继续点击跳转至不同页面，实现退出或者是更改设置。
详细设计书，就是具体到项目基本文件树构成，都包括那些文件夹和哪些文件，每个文件都是做什么的，每个功能是怎么一步一步实现的，这么实现的原理依据是什么
开发者角度：
- 开发前装好开发环境，已存在的项目使用大家都在用的版本号，新项目安装最新的稳定版
- 清楚编码规范，代码风格，清楚代码管理仓库的使用，熟悉各组员的角色，方便配合工作
- 开始编程前，一定要明确且熟知项目中使用的主要框架、库及其他技术
- 清楚的获取需求，列出需求，细化需求，大致列好着手顺序。俗话说把问题清楚的列出来就解决了一半了。
- 有任何疑问疑虑及时跟相应人员沟通。
PL/PM角度
如果自己带一个小团队(PM一般是后端承担，因为后端技术方案通常会比前端复杂，需要考虑的事情更多，但万事无绝对，毕竟PL/PM不需要实际做开发)
- 每天晨会（每人两分钟左右）：成员依次介绍昨天做了什么，今天预定做什么，昨天几点下班打卡的，有什么困惑，近期有没有请假安排，以及其他需要说明的，晨会的目的主要是为了方便团队管理，还可以增进团队凝聚力
- 每周一次项目会议：每个人总结一周的工作，安排下周的工作，肯定成就，指出不足，可以适当聚餐
- 项目自动化（条件允许的话）：指的是前端开发完以后，将代码合并到develop分支以后，自动build发布到服务器上。 一般为PL/PM的工作，docker，jenkins，nginx，AWS的设定。如果有专门的运维最好。
- 要宽容，要能容人，不该计较的别计较，但是不能软弱。
- 对于团队而言，流程太重要了（团队中的任何一员都应该是可替代的） 流程其实没那么复杂，就是各司其责+节奏。我们都是“哆瑞咪发梭拉西多”中的一员，各自有各自的责任，然后组合在一起，按照一个节奏跑起来。把该做的事情与该跑的节奏定好。
- 不要炫技，老老实实写代码：尽可能简单的完成需求。画蛇添足不需要
- 一个模块开始前，应该先做调研，最好是跟着成功项目的脚步，比如有相同功能的某宝是如何实现该功能的。大多时候短暂的调研可以让你少走很多弯路
- BUG，只要是人写出来的代码就肯定有bug，充分分析产生bug的原因，解决bug，切记不可越修复bug越多。
- 注释，必须清楚写明注释，为了以后维护的方便，也为了其他人接手方便，注释写清楚了就能让你的搭档或者接手者少加班，少做一些无用功
- 代码结构要清晰：有按照功能划分的，有按照 UI 结构划分的。还有公用工具类，有数据管理，有主逻辑控制。不管用哪种思想，有序的代码结构，可以让每个人感觉很干净 代码结构表现出来的其实是——程序的一个模块\逻辑思想——让大家工作在不同的区域。
- 代码风格要统一，负责前端和后台的分别跟自己人商量出一个代码风格文档
- 测试，开发人员要做基本的单元测试，可以发现很多被忽略的bug。测试一般放在最后，如果项目时间紧迫可以先上线，再根据实际情况进行bug修复
- 制作项目日程表，比如一个项目6月底上线，1月初开始开发。简单日程表就是：1-2月前后端商量着分别制作自己的开发日程表，然后按照日程便进行页面1的开发，2-3月页面2的开发，3-4月页面3的开发，4-5月页面4的开发，5-6月单元测试。开发日程表只是一个大概，实际应该尽量往前赶，拖进行了的话就要加班
- 代码所有权
- 强代码所有权。 每个模块指定一个负责人。开发者只能更改自己拥有的模块，如果需要更改其他人的模块，就必须与模块所有者联系，让后者更改。你可以为其他模块写补丁，将其发送给模块所有者来加速此过程。
- 弱代码所有权。 每个模块指定一个负责人，但是开发者可以更改其他人的模块。模块所有者应对其拥有的模块负责，密切关注其他人所做的更改。礼貌的做法是，更改其他人的模块之前，首先与模块所有者进行讨论。
- 集体代码所有权。 模块不指定负责人，代码库由整个团队拥有，任何人都可以在任何地方进行更改。这种做法可以视为代码没有个人所有权，只有团队所有权。
现在大多数公司都要求所有人都可以修改源代码，也就是集体代码所有权的模式。这样的政策，很可能导致软件质量和员工敬业度的下降。如果你的目标是工程师既高效又以工作为荣的企业文化，那么强代码所有权模式是最佳选择。
其他
如何能评估比较准的工期呢？一个很简单的公式送给大家：
- 需求非常明确而且经常这样做：自己评估时间 * 1.5
- 需求不够清晰，有可能变，但是代码和技术方案熟悉：自己评估的时间 * 2
- 需求不够清晰，代码和技术方案也是新的，需要探索：自己评估的时间 * 2.5 or 3
PM 角色
发送日报，抄送业务方和老板，指明今天进度，被阻塞的问题和谁来解决，以及当前项目风险。 在日报里明确指出了很多后端相关但是没做或者不知道的工作，并给出解决方案。这种方式可以让业务方、 老板和项目组成员都及时明确风险点，并盯住对应问题处理人使其尽快完成，减少阻塞