Please enable JavaScript.

Coggle requires JavaScript to display documents.

工作总结 (综合 (版本管理 (重效率 (会议的效率，很重要，不然浪费大家的时间，让大家反感会议（其实会议是让大家很好的沟通方式，要利用好）…

- - - - 项目开始后要定好每个里程碑的内容，整体的大概时间
    - - 每个里程碑里面的完成目标要划分好阶段，划分的越细对时间和完成度的把控上越精准
    - - 各部门的精确排期，让阶段目标能够更好的，准时的完成
      - 出现delay的情况要帮助delay的同事，找到原因
        
        评估排期不足
        
        能力不足
        
        设计思路有问题
        
        开发过程中遇到别的困难
        
        特别注意，不要以Delay就去责备同事，要学会帮助一起分析原因
    - - 在执行过程中要定好规则，一旦定下，就要身体力行
        
        单号的标注
        
        提交的审核
        
        操作的顺序
        
        版本的标签
        
        问题的同步
        
        事务的推进速度
        
        奖惩机制
        
        考核机制（考核是用来给大多数人加薪的，不是给大家的负担）
        
        团队的合作责任制
    - - 身体力行，规则一旦制定，就要强制的执行下去
      - 发现问题要及时改正，及时调整方向
    - - 工作讲究的时效率，每天8小时5-6小时有效时间即可
        
        工作的效率高低并不是以时间长短来定的
        
        推荐使用番茄计时法进行训练学习
        
        工作效率最低的就是来回打断，每次大脑重启进入状态会耗费大量时间和精力
        
        番茄工作学习法，除了提高本人的工作效率，同事在面前的时钟可以给前来打断的人给予提示，还有多久我才结束这段番茄时间，如果不是非常非常重要的事情，请过多久以后来找我
      - 代码的效率，不但代码执行有效率，开发和框架上的搭建也要准中效率的设计
      - 流程的效率，在沟通和推进上一定要有效率
      - 会议的效率，很重要，不然浪费大家的时间，让大家反感会议（其实会议是让大家很好的沟通方式，要利用好）
        
        确定好会议内容
        
        会议的倡导者提前充分准备好会议资料和内容
        
        开会时严格控制讨论范围，以免发散过大导致时间过长
        
        是本会议的内容表达清楚，传达到位即可结束会议，如有问题，记录即可，不必讨论
        
        记录的问题首先由各提出者相处一个或多个解决方案，感兴趣者也可提出解决方案，收集完成后整理发送给参会人员，提前思考，提前准备，待准备充分，后投票表决出1-2个可行方案，最后再开会研究对其结果。
        
        每次会议时间不要超过30分钟，超过30分钟即使有问题的会议
        
        会议场次不易过多，如果会议过多，证明各部门配合沟通是有问题的，应该及时解决
    - - 加班并不会提高效率，反而会降低质量
      - 如果采用番茄工作法，人的精力消耗是很大的，如果在加班会让大家吃不消
      - 加班会带来很多恶果，员工的身体，员工的心理，员工的家庭等
      - 加班过多会影响员工私人时间，降低大家的生活幸福感，对于一些职业会让其减少充电学习时间，不利于公司的长久发展和员工的个人长久发展。
- - - - 由于TRedi是集群分布式数据库，数据的访问延迟会有200ms左右甚至更高，所以在系统开发是要考虑到并发时的数据拥堵
      - 对数据库的操作最好分异步操作
      - 对高并发可以考虑时间换速度，使用逻辑分针处理消息避免线程拥堵
    - - 功能尽量做到
        
        1 可复用化
        
        2 简单化
        
        3 可组合化
        
        4 灵活化
        
        5 可配置化
      - 功能与功能的耦合度要尽量的低
      - 功能的设计思路一定要清晰，如果对应人员开发经验或者设计经验不足，应该由经验足的人搭好框架，再有执行程序去填充
    - - 总结但不指责
      - 归纳通用性
      - 可通过规定或者要求规避的要制定规则并执行下去
        
        比如：迭代器的使用大家统一规范。
        实现功能前先写伪代码然后填充等等
    - - 机器人的开发：开发一个复用性强，使用难度低的机器人对服务器的压力测试和功能测试有很大的帮助。
        
        比如：有的功能需要上人数操作才能测出问题
      - 单元测试：例如Golang实现单元测试，以减少人工成本
      - 性能测试
        
        对服务器的消息处理性能测试
        
        对事物成功率统计
        
        对网络流量进行测试
        
        对IO操作进行测试
        
        不应该测试mysql和redis的性能，应该测试的时DBServer的处理能力和缓存能力
        
        对乱发包的处理测试
        
        对消息处理的耗时检测
        
        对模块执行的耗时监测
        
        对CPU使用的监测
        
        使用工具监测函数模块对CPU的占用情况
        
        intel Vtune
        
        VS自带工具
        
        对CPU毛刺的分析
        
        对CPU长时间占用的分析
        
        对CPU高消耗的分析
        
        对内存消耗的监测
        
        使用工具监测是否有内存泄漏
        
        分析统计每个功能和配置表加载后的内存消耗
        
        监测内存创建释放的情况
      - 代码
        
        代码的规范
        
        基本的命名规范
        
        语法的使用规范
        
        一些特殊操作易错操作的规范
        
        大家不熟悉的代码使用方式的适当规范
        
        代码质量的检测
        
        使用代码工具进行检测
        
        TScan
        
        CppCheck
        
        sonarqube
        
        人工代码review
      - 测试用例
        
        除了QA部门和策划给的测试用例，程序应该学会写测试用例
        
        增加程序的项目重心
        
        增加程序的策划能力
        
        程序能想到白盒才能测出的用例
    - - 版本的开发排期
        
        对功能的开发时长控制
        
        对版本产量的控制
        
        对版本优化的控制
      - 产生的bug
        
        对bug的分级
        
        对bug的响应时间
        
        对bug的个数统计
        
        对bug数变化的分析
        
        bug解决后的总结和分析
  - - - 代码更清晰
      - 但由于底层的字典序，加载模块会出现依赖模块先后加载的问题