星地协同生态环境走航系统——项目总结

生态环境走航系统——项目总结"/>

星地协同生态环境走航系统——项目总结

1. 需求一定要了解清楚的不能再清楚之后再去思考如何做这个项目

2. 写代码永远是最后一件事，要先把需求分析、方案设计、原型编写、项目框架搭建等做完善之后，再去分配任务进行开发

3. 站在项目经理的角度上来看，技术的广度大于技术的深度

4. 在任务安排时一定要分优先级，有主有次

5. 要会写文档，掌握常见文档的模板，如：项目方案、会议纪要、测试文档

6. 项目组的每一个成员都要清楚：

   1. 项目的最终实现成果是什么样的
   2. 到目前为止还有哪些功能模块没有做
   3. 没做的功能模块有哪些是由自己负责的
   4. 项目的整体数据流向，数据接口文档

7. 项目的每个模块都要有明确的责任人

8. 开发上：

   1. 严禁使用setTimeout解决异步问题，大多数时候使用promise解决异步问题是更好的选择

   2. 组件编写思想：写组件之前，要想明白这个组件的功能、输入与输出，并且标注出来，任何组件都要做好复用的情况。大部分的组件都是功能组件，而非某一个地方的固定组件

   3. 前后端并行开发时，一定规范开发文档，双方面向文档编程

   4. 前端vue务必使用ts，遇到问题就去解决，而不是逃避，没有规矩不成方圆，避免将typescript用成anyscript

   5. 所有的输入数据，都认为是可变的，组件内不能出现固定数据，如果该出确实需要固定数据，那么也应该出现在全局中，而不是组件里

   6. git提交之前检查一遍代码，非共用代码的修改无需提交（如本机ip等），并且删除不必要的console

   7. 前后端交互过程中，数据的ajax请求与接收、接收到的数据处理要通过两个文件进行处理，其优势如下：

      1. 可以使文件逻辑清晰
      2. 后端更改接口返回新的数据格式后，前端仅修改数据处理文件即可，无需修改使用了该数据的一个或多个组件、模块
      3. 有更良好的向后兼容性
      4. 后端发送过来的数据，很少是前端可以直接使用的，所以大部分接口都需要数据处理文件帮忙

   8. 自己的测试代码不要提交到git上

   9. 将项目的主要颜色存到全局变量中使用，或者编写多个css（less/sass）文件，用于项目的不同界面风格

   10. 提高程序调试效率的方法：多个问题一起处理，处理完成后一起调试，而非改一个地方就编译启动系统进行调试。

   11. 新增功能或修改功能时，遵循能加不改原则，能用增加函数或增加数据结构字段来解决的问题，一定不去修改原有代码与数据结构，这可以避免其他已完成模块出问题，所以在模块开发时就要考虑其向后兼容性，多思考亦能多便利。

   12. 系统打开初始化的过程中，非必要的模块和功能不要加进来，要保证系统打开时运行流畅。比如，系统进入后第一个页面是登录，那么在进入系统的过程中，只运行登录页面有关的功能，其他的功能一概不要运行。模块的初始化、数据请求、数据计算、数据渲染等操作都应在自己模块内操作，切勿放到项目整体初始化中。

   13. 良好的开发习惯：

       1. id是js用来定位唯一元素的，不要用来通过id为其添加样式，防止更改id导致样式消失等其它问题的出现

       2. id使用驼峰命名法命名，class使用横线命名法命名

       3. 编写样式时，同类放一起，样式之间回车隔断，少使用嵌套样式

          1. .equipment-not-connect {position: absolute;top: 54px;left: 0;display: flex;flex-flow: row nowrap;justify-content: center;align-items: center;z-index: 10;width: 100%;height: 484px;border: 1px solid #ccc;color: #ccc;background-color: #fff;font-size: 25px;> div {}
             }
             

       4. 编写js、ts或vue等文件时，需要为其文件在最上面添加标准注释：

          1. /** @Description: * @Author: ZY* @Date: 2020-12-28 15:13:48* @LastEditors: ZY* @LastEditTime: 2021-01-12 15:22:27*/
             

       5. 编写vue的组件时，script标签的lang设为ts，且vue对象使用defineComponent进行封装，在TS下，会给予组件正确的参数类型推断

9. 你不去找问题，那么问题就会来找你，作为项目经理，一定要对项目进行全面的思考，找出隐藏的风险，并尽早解决它，不可抱有侥幸心理，认为该问题不会出现，俗话说：麻绳专挑细处断，bug只找难处现（鄙人原创，哈哈哈）。解决一个问题的成本是随着项目的开发越来越高的，所以解决问题最好的时间就是在项目初期。

10. 交流上：

    1. 遵循对事不对人原则，不论是前端还是后端在数据上出现问题，在没找到问题根源之前，都不要妄下定论是谁的问题，讨论的意义在于解决问题，而不是推卸责任。比如，前端项目正常运行，正常开发的情况下，突然就报错了，但报错的位置并不是我现在开发的位置，此时不应该直接下定论是后端修改了数据或者修改了端口，也有可能是自己在开发时修改了内存中的数据结构导致的，所以此时的解决办法为与后端一起排查问题并解决掉。人都会失误，这是避免不了的。

    2. 功能模块构建时，要考虑的非常全面，要做到任何实际情况下都可以正常运行系统，而非理想情况下的正常运行。比如：显示硬件设备的监测数据模块，不仅要考虑设备连接成功时的数据显示功能，还要考虑：

       1. 设备异常断开与重连的情况下如何处理
       2. 任务数据中有的设备但真实没有连接的设备如何处理
       3. 数据中出现异常值如何处理
       4. 监测设备的监测指标没有数据如何处理
       5. 监测设备没有监测指标如何处理
       6. 所有设备全部没有连接如何处理
       7. 任务数据中没有监测设备如何处理
       8. 数据传入在数据初始化之前如何处理

11. 系统测试：

    1. 要做到未雨绸缪，在与甲方测试的时间之前，自己小组内要准备好测试程序，模拟测试环境进行测试，最大限度的减少在甲方测试时出错的概率与频率。而且时间不能定在去甲方测试前一天，因为我们不能保证测试一遍过，所以要留出时间来进行项目调整。
    2. 完全按照系统实际使用的环境去测试，比如：系统的前后端最终是安装在同一台电脑上使用的，那么测试时就应该把前后端均安装到一台电脑上去测试，而非两台电脑分别运行，且边测试边修改代码，这样是不对的，就应该前后端的系统都在同一台电脑上，后端发现问题在自己电脑上去修改，修改完成后打包一份放到测试机上进行运行。
    3. 小组内部分技术人员计划明天去甲方测试，那么在前一天需要将后端服务和最新的前端代码部署到部分不去测试的成员电脑上，避免发生后端人员出差去测试后，小组成员在公司因为没有后端数据服务而无法进行开发测试。

12. 能力提升：

    1. 文档编写能力提升：
       1. 《项目策划》
       2. 《项目方案》
       3. 《项目测试细则》
       4. 《项目使用说明》

13. 项目成员在工作时，明确自己一天的工作任务，合理安排时间，确定今天完成的任务一定今天完成，今天完不成的就要与项目经理商议任务的时间节点。

    1. 举例：员工甲负责着两个项目，项目A今天有一个任务，是早上安排的，承诺今天完成，但中午项目B也安排了一个任务，所以员工甲下午就忙着项目B的任务，就耽搁了项目A的任务，最终完成了项目B的任务，而没有完成A的项目。正确做法应该是，中午得到项目B的任务时，明确自己A项目还需多长时间，今天剩余时间是否能够完成项目B的任务，如果不能，则与项目B的项目经理协商任务完成时间，而非将项目A的优先级放到后面。如果项目B的任务优先级更高，那么应该与项目A的项目经理沟通，而非等到下班后给到项目A的项目经理的结论是今天忙了其他项目，所以这个任务没有完成。因为每个项目经理都是要把控项目进度的，对不同的情况要做出决策，如果项目A的任务也很着急，中午与项目A的项目经理沟通过后，项目A的项目经理或许就可以找到其他人员去做这件事，而不会导致项目组加班。

14. 与甲方沟通上：

    1. 擅长提取需求：**甲方的情绪是不可控的，而且提需求的方式也不会很专业，所以我们需要在甲方的言语和行动中提取出需求，然后与甲方确认需求。**不能等着甲方明确的给你提需求，这样的情况很少。
    2. 及时给到甲方项目进度反馈：大部分的甲方，都很关心项目的进展，所以及时给到甲方项目进度的反馈是一个很好的选择。

15. 项目部署：

    1. 在给甲方部署之前，要提前进行部署测试，将系统部署到一个空白的电脑上进行部署测试，提前发现问题并解决，确保给甲方的部署顺利完成。
    2. 在给甲方部署之前，需要提前编写好部署注意点，部署详细流程；需要准备好U盘、网线等硬件设施

16. 项目进度的把控上：

    1. 明确各个阶段的里程碑
    2. 明确每个阶段中的每个活动时间点之前要达到的状态，将未完成的项列出来，并一 一布置下去完成，时间点如：
       1. 调试：确定与甲方调试之前要达到的状态
       2. 部署：确定与甲方部署之前要达到的状态
       3. 交付：确定交付项目之前要达到的状态

17. 不推卸责任，对于一个项目来说，项目经理负最终责任，可以说，项目出任何事，项目经理都逃不了干系。项目经理如果将责任推卸给甲方，项目成员就敢把责任推卸给甲方，但甲方并不考虑这些，甲方只考虑项目时间到了之后项目成果是否符合技术要求的标准

18. 系统版本管理很重要，要保证任何时候都能拿出一个功能正常的系统，所以要做到系统一个版本一锁定。

19. 项目管理上：

    1. 养成固定的习惯：
       1. 每天晚上下班前半小时要做两件事，知悉项目进度，并让项目组成员明确明日工作内容：
          1. 检查小组成员project中今日任务的完成情况
          2. 把控项目进度，整理出小组明日的工作计划，并在project中分配下去
    2. 在做一个需求时，需要将其分解，分阶段完成，可以分为三步（三个时间点）：第一步完成基本功能，第二步完成主要功能，第三步完成所有功能。要先实现从0到1，用迭代的思想进行需求管理与开发。

20. 经验教训：防火胜于救火，提前将风险揪出来，联合多方力量将其解决掉，一定不要等到风险真实发生了再去补救。

21. 管理项目时，所有的活动和会议都要进行文字记录并留存。

22. 应该我们催着甲方去测试项目，而不是甲方催着我们赶进度，有时候当甲方来催我们的时候就已经晚了。

23. 有些任务是可以并行的，如果资源足够，任务并行比串行效率更高。比如开发企业查询功能模块，企查查平台需要使用企业认证的账号才能查询，但API与数据返回格式是确定的，所以说在没有企业认证的账号的前提下也是可以正常开发的，也是可以正常测试的，可以通过使用官方API返回的数据格式来测试。让不确定性只存在于企查查API的返回值那里，就是说要保证只要API返回结果正确，我们开发的模块就是可以正常工作。正确的处理逻辑为，通过API与返回数据格式进行模块开发与测试，在这期间与甲方沟通开通企业认证账号，开发测试完成后使用企业认证账号进行测试，测试通过后模块完成。

24. 开发上的bug易错点：

    • 通过循环进行worker计算时，onmessage中获得的计算结果与当前onmessage之外的变量可能不是同一次循环，所以不能在onmessage中使用外面的变量来与计算结果一同使用，切记onmessage是一个监听，并不是与当前worker进程绑定的。

25. 每个模块的职责一定要清晰，在项目启动时就执行启动的相关命令，不要将很多操作放到项目启动时，这样会导致项目启动慢，用户体验差。每个模块的数据要在使用时再去请求数据、渲染（特殊情况除外）。千万不要由于登录或者主页中后台执行着大量的数据接收与计算，导致登录界面或主界面的动态效果卡顿，这是不合理的。尤其是，不要在各个模块初始化时做过多的操作与请求，每个模块基本上所有的操作都是需要条件触发的，写到方法中，在恰当的时机调用即可。

26. 开发时，完成一个任务或解决一个缺陷就提交代码（提交前要先拉取最新版本，并消除出现的冲突），并注释清楚，这样便于出现问题时溯源问题，可清晰的在git上找到可疑提交。没必要规定每天早上拉取、晚上提交，然后提交的内容包括多个任务或缺陷，这样不利于版本回顾。

27. 如果项目较大，store一定要分解为多个文件来处理，防止将所有的数据都存到一个index.ts中。

28. 系统开发中，前后端程序中的本机IP尽可能做成127.0.0.1，防止开发环境、测试环境和部署环境的计算机IP不同而导致的频繁修改配置文件。

29. vue项目的目录中：

    1. components文件夹中放置全局公用的组件
    2. hooks文件夹中放置全局公用的方法体
    3. views文件夹中放置页面级的组件，并在各自文件下放置各自的组件
    4. api文件夹中放置所有的ajax请求，建议与view文件夹中的页面文件夹相对应的创建文件。

30. views文件夹中每个页面的文件夹都对应api文件中一个ts文件，二者一一对应，结构清晰且容易维护。如登录页面，在views文件夹中有一个login文件夹，里面都是登录页面的组件，在api文件中有一个login.ts与之对应，内容即登录页面所用的请求。

31. 不要为了用 vuex 而用 vuex。比如有一个很庞大的后台项目，几十个业务模块，几十种权限，但业务之间的耦合度是很低的，文章模块和评论模块几乎是两个独立的东西，所以根本没有必要使用 vuex 来存储data，每个页面里存放自己的 data 就行。当然有些数据还是需要用 vuex 来统一管理的，如登录token,用户信息，或者是一些全局个人偏好设置等，还是用vuex管理更加的方便，具体当然还是要结合自己的业务场景的。总之还是那句话，不要为了用vuex而用vuex！

32. 在开发时要控制项目的大小，包括每一个图片，都要经过压缩再使用；或者在发布之前将所有的图片进行统一压缩。

33. 在与客户沟通时，做的每一个决定，都要考虑这个决定做了之后这件事的责任会落到谁的身上，最好的结果是将问题落在做那个决定的原因上，不能将责任揽到自己身上。比如，由于另一个项目比当前项目着急，当前项目被推迟了，如果和甲方说人员减少导致的进度变慢，那么这个决定会将责任落在自己身上，是由于自己人员原因导致的，这样就很被动。其实可以实话实说，就说手上项目较多，有个比较紧急的需要处理，如果甲方说先做我这个，那么他就应该拿出状态来（做了很久合同还没签），把合同签了，那我加人加时间赶工给你做。或者说当前项目难度比想象中更大，下一个测试节点之前可能不能将全部的问题全部解决，能够解决大部分，这样的话也是将责任扔给了项目或甲方，是比较合理的状态。

34. 在项目开发过程中，单元测试是很有必要的，可以保证每个模块的功能完全，减少模块中的bug，并且能够及时纠正模块中的错误。任务分配时就需要以模块为单位进行分配，每个模块明确责任人，在该模块开发周期完成后，小组组织模块评审，模块负责人进行逻辑讲解并展示单测报告。

35. 带着问题去学习或阅读，这样的收获会更大。