项目全周期管理心得

有感于在项目中花费的较多的时间在沟通上，所以觉得有必要在团队的内部形成约定俗成的一些规范，已减少项目中不必要的沟通及其他方方面面带来的问题。
我将项目规范设置了3个重要等级，分别为A，该等级相对重要，属于个人认为必须要执行的规范，B等级属于有助于项目推进的规范，C等级属于个人比较困惑，难以权衡的规范。

项目资料

在项目的开始，比较中的项目资料有项目需求文档、数据库表结构设计文档、系统生产、测试项目账户密码、第三方或客户对接人员联系方式表。
项目开始，我们往往并不是就立即开始编码，而是阅读需求设计文档、设计表结构，随着做过的项目越多，越觉得表结构设计的重要性，好的表结构设计能够从一开始就规避掉很多的问题，在需求文档初稿出现的阶段，表结构设计就应该开始设计了，在表结构设计中，我们有很多的表在各个项目中都是重复的，我们可以一开始就准备好。
表结构的设计我们可以使用各种表结构设计工具，数据库表结构的同步需要通过表结构设计工具进行同步，避免手动生成数据库表，对于这类需要操作需要通过专人来处理，这个人可以是项目经理，可以是DBA工程师。
表结构的设计中，最好所有的表都要设计主键，具体原因说不上来，但是在数据库同步的时候有主键真的是很方便；我们需要准备好清库脚本，数据库初始化脚本，方便我们进行系统的部署、迁移。
对于需求设计文档，建议是项目组所有成员及项目测试人员都要获取到第一手的资料，这类的文档一般都是以word文档的形式留存的，所以无法是用git进行版本的管理，我们需要在每次发布的文档中添加版本号码，由专人（项目经理，项目经理助手）第一时间以邮件的形式发送给项目组成员。最近发现了Office365真的很不错，对于管理Office文档，真心时再好不过，之前试过有道云笔记，石墨文档，但是存在的问题就是无法做到无缝的对接，其实对于文档的管理，在项目中最主要的就是文件的共享于文档的版本管理，Office文档的管理做的最好的当然还是Office了。
在项目的开发过程中，可能是一个非常混乱的过程，我经历的几个项目中，因为项目的复杂度、项目的规模、项目的周期等因素导致的项目个环境多次变换，系统账号多次变换，这些问题在项目组成员的休假或离职时会带来一定的混乱，所以我们需要这样的文档，来实时的记录这些信息的变化，这个工作最好交由项目经理助理来管理，可以以markdown的形式保存，通过git进行管理。
与客户进行对接的信息也需要进行管理，需要有专门的文档管理这些客户关系，某些时候实施或是开发需要到现场进行系统的演示、部署、调试，或多或少的需要与客户打交道，清楚的了解客户关系，能让我们在客户现场避免一些不必要的麻烦。

项目开发

在项目开发之前，我们需要确认下项目的基础框架，一般这些框架会由公司的主要开发人员搭建好，项目的各个模块最好分配，使用何种技术栈，在使用的技术栈方面，不是使用最新潮的就是最好的，但是大多数情况下，最新潮的确实是最好的，尤其是前端领域，像vue、react 之类的框架，API的变化比较的大，如果一直使用旧的版本，可能出了问题，在网上也只能找到一些旧的答案，当然凡事没有绝对，在一个项目中如果存在网站，建议还是使用bootstrap或是手写js、样式比较好，因为网站你要考虑到用户会比较的分散，用户分散，那么兼容性就不好处理，从效率的角度来讲，使用兼容性良好的UI样式框架比较合适。
从后端的角度来讲，接口提供的方式是通过http还是web service ，也是一个问题，目前大部分的多端的解决方案都是使用http，因为使用http可以一套接口多个客户端使用，用户的状态鉴定使用token的方式，所有客户端都以统一的模式进行开发。
项目的代码结构也是非常重要的，好的项目结构，并且严格的按照项目结构规范进行开发，有利于自身变成素养的培养，也有利于项目的继任者快速接手，有人可能不是很喜欢java的超长命名，但是我认为这是个很好的习惯，我们常常说编程语言，既然是语言，那么就应该使用来交流的，编程语言除了要与机器进行交流，还应该是人与人交流的桥梁。合理的命名能让我们更好的理解代码。
在项目中我们常常会进行封装，在前端常见的封装常见于工具函数、UI组件，当然有时候我们也会做一些基于业务的封装，主要是为了避免不必要的重复工作，减少代码量，后端在封装上面可以说是做到了登峰造极，spring封装了一层，spring-boot封装了一层，最后我们很多时候是在给予封装框架的API开发。
我个人建议的是在项目开始时进行最低限度的封装，对于项目周期长，复杂度高的项目是这样的，前端可以手动创建webpack项目，或是使用一些不是封装的特别厉害的CLI工具初始化项目，后端的话还是建议使用SSM框架，这样做的好处是有很大的优化空间，能够及时的方便的更新项目依赖，对于短期简单的项目，没必要这样做，怎么速度快怎么来。当然要是够厉害完全可以自己搭建基础框架，自己造个spring或是vue。
存储过程用还是不用？大厂都不提倡使用存储过程，因为大厂的系统的数据相对来说比较的敏感，因为不差钱，各个环节都有专业的人操作着，数据库会由专门的人管理，但是我在现实工作中，就遇到用存储过程写业务的领导，领导的解释是，业务写在存储过程中的好处就是系统无需重启，就能进行业务的调整，想象确实有道理，抛开风险来说，这确实是一个很不错的优点，说缺点的话就是存储过程的版本管理不是很方便。但是我们可以将一下系统框架相关的数据库操作写在项目当中，业务相关的写在数据库当中。

项目测试

测试时很重要的一环，建议测试环境要与生产环境保证高度的一致，可以采用docker来统一部署及测试环境，注意建议只在项目复杂程度较高的情况下使用dockers进行部署，如果只是个简单的项目，完全没有必要是用docker进行部署，总之怎么合适怎么来？
项目测试不仅仅是测试部门的事情，因为测试大致可以分为黑盒测试和白盒测试，黑盒测试需要测试部门人员对系统的业务进行深入的了解，开发人员需在开发完成后，进行初步的测试，需求、开发、测试最好能够相互间进行业务的交流，对于快速推进测试工作有一定的帮助。
在开发的全过程中，测试都应该是参与的，在项目推进的不同阶段，测试的目标也是不同的，在前后端分离的测试模式下，测试可以将测试的内容拆分为对页面的测试，对接口的测试，对业务逻辑的测试。
对页面的测试，主要集中在对于页面的美观性是否与设计稿一致，页面的交互是否存在问题，不管是移动端还是web端，都需要对兼容性进行测试，对于兼容性的测试越早越好；对于接口的测试，在项目初期是对后端开发人员完成的接口进行一个确认，后端的开发人员再次之前已经完成了自我测试，在确认前端页面与后端接口独立测试时没有问题后，则开始对业务进行测试，这一测试过程可能是最长的，主要原因在于沟通，业务是客户制定的，所以这一阶段，需要需求沟通人员及时的告知项目组成员系统业务状况。

项目部署

很多时候我们会发现，在进行生产环境的部署与迁移时会遇到各种各样的问题，为什么会遇到这样或是那样的问题，我总结了以下几点：
生产环境部署前各项准备工作没做好，服务器、数据库等没到位（没有及时的与客户沟通服务器事宜，服务器时自建还是购买云服务器，数据库使用正版还是盗版等问题）
测试环境与生产环境不一致（开发环境使用的时SQL server数据库，生产环境使用的时MySQL数据库）
生产环境为公用环境（生产环境已经在使用了，上面部署了其他的系统，可能导致的问题时，一些系统运行环境与开发环境不一致，导致较多的问题）
项目的部署需要遵照一定的规范，从部署位置，部署账号，是否有容灾措施等方方面面考虑，对于需要长期运维的项目，文档与备份，最为重要，因为项目的运维周期较长，人员的轮换，数据量的增大都是我们需要面对的问题。

项目交付

项目交付，剔出商务这个环节，那么我们需要着重研究的是如何降低运维成本，运维的成本主要体现在人上，这是项目运维的最大成本，那么怎样才能替代人呢，这个只能靠用户，如果用户具备了解决问题的能力，那么运维的成本自然会一定程度的降低，很多时候系统操作手册都被看做是系统交付的材料。

最后安利下自己的小程序，一款程序员刷题小程序。