10 x 工作法

水深无声 2023-07-22 07:59 51阅读 0赞

# 10 x 工作法 #

1.  接到需要和开始工作的时候  以终为始的思想, 前面多思考,后面做的时候更加的轻松,自己的想法和产品与 项目经理的最终点是否一致,  为什么会出现不一致,因为我们的上下文的定义不一样,所有信息的差距很大,所以需要去沟通.
2.  DOD 的模式开发,需要的是列出开发的清单,
    
    1.  需求的清单,
    2.  功能的清单
    3.  编写代码的风格的检查
    4.  自己的单元测试  自测通过  日志是否打印完整
    5.  测试验收通过
    6.  文档填写完成
    7.  做到任何时候都可以部署的状态
3.  前后端一起开发的时候, 后端定义好数据格式后可以先使用mock api接口提供伪代码的数据出去. 方便调节测试
4.  做业务代码时,定义完成的标准, 比如:
    
    1.  1.  接口的响应速度
        2.  前后端的数据格式
        3.  特殊意外情况
        4.  可控范围
        5.  注意 异常的情况,接口的异常,捕获异常
        6.  全局观. 是重点,不然到处有暗坑
5.  默认所有的需要都不接,除非说清楚这些需求为什么要做,要有充足的理由和数据让我去做,,在探讨需求的时候要有足够的反驳的理由和一针见血的问题.
6.  在讨论业务时，我们用精益画布，可以在《精益创业实践》中找到
7.  在做底层工具人的时候,少设置自己的工作边界但是要提高自己的工作效率,比如:
    
    1.  1.  刚到一个项目组或者新入一个新公司,了解系统的全帽,,这个系统做是什么业务,模块之间是如何划分的.公司的中间件是用的什么,有么有公司自己的框架这个是需要去学习的,公司的技术栈
        2.  虽然不是项目负责人,但是不妨碍我去了解其他组的系统.业务,接口
        3.  虽然不是项目经理,但是不妨碍我去观察,项目经理是如何管理项目的
        4.  虽然不是产品经理,但是不妨碍我去观察,一个产品是如果设计出来的,一个产品的全链路流程 软件的全生命周期
        5.  看待问题的角度需要多种上下文的思考,  比如员工的上下文是单一的,老板的思考是全面的
        6.  扩大自己的上下文,不要把自己局限在程序员身上
        7.  扩大自己的能力圈 (前端,测试,运维,产品,需求架构,架构,运营)
        8.  了解团队的流程 业务 技术 团队的运作
8.  确定好工作的目标后,,在动手之前先把实施步骤推演一遍,在脑海中思考一遍
9.  我们的工作是否可以用数字或图形化来表达
10. 比如:我是做后端的,你们是否做到了,持续集成,持续交付,持续验证

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70 1][]

1.  任务的分解:
    
    1.  任务分解和敏捷开发的用user story应该是相似的,首先我们会定义大的feature,这个是大的产品经理关注的,然后我们基于feature分解成不同的user story,最后每个story，再分解成一个个具体的task,我们程序员就主要解决task
    2.  一个大的需求 进行一步一步的分解,到自己可执行的,可评估
    3.  难点是 : 如何把不熟悉的领域任务进行分解
    4.  检验每个任务项是否拆分到位，就是看你是否知道它应该怎么做了
    5.  金字塔原理就给出一个从中心论点到分论点，再到论据的模型，帮助我们将知识梳理出来. 可以看出来是如何进行分解的
2.  面向极限开发: 先写测试->后写业务代码 测试驱动业务开发
3.  把任务拆分到可测试的地步,才能正对性的写测试.
4.  什么是好的测试 A-TRIP
    
    1.  Automatic，自动化
    2.  Thorough，全面的
    3.  Repeatable，可重复的
    4.  Independent，独立的；
    5.  Professional，专业的
5.  产品给我们提出需求我们给他们的指标:  
    
    1.  背景
    2.  数据指标
    3.  价值 或者是做这个需求的意义
    4.  需求的分类 是用户需求还是开发需求
    5.  需求管理基本单位是什么样子的 x s xs xsmax 或者数字 1 2 3 4 5 6(还分的单位)
6.  丰田的5w沟通方法  定期复盘,找准问题的根基, 不断改善
    
    1.  One 任务是什么,下属:知道了
    2.  Two 你重复一下, 下属巴拉巴拉讲一遍，没错。还不行.
    3.  Three 你觉得这件事的目的是什么,下属讲清楚了准备走,又被拉出来了
    4.  这件事情会不会遇到什么问题,,哪些是你可以自己做决定的,哪些需要汇报的
    5.  等讲完成了,问问有没有好的建议
7.  项目中--à及时沟通,反馈,解决问题, 遇到困难要及时于领导汇报
8.  做有价值的事情最重要,这里面关键不只是做了什么,还有通过”不做”来节约时间和成本有价值的事情.
9.  NIH 综合征: 什么是NIH综合征:自己看不上别人做的东西,非要做一套自己的出来,原因是那个不是我写的.可能存在很多问题
10. 程序员的三大美德：懒惰、急躁和傲慢:  思想的上的勤奋,行动上的懒惰
11. 理解: 精益创业的理念,在往外的是持续验证
12. 改变先有的开发模式:面向对象的开发,了解需求->创建表->写业务->改需求->上线. 那么领域驱动开发是怎样的,我的是理解是这样的.
    
    1.  1.  1.  给出足够的理由来开发这个需求
            2.  了解上下文
            3.  考虑设计模式
            4.  大概的实现的过程
            5.  对先有系统的影响
            6.  创建表 (包含预留位)
            7.  (申请接口) 写单元测试案例
            8.  写伪代码
            9.  具体的代码和风格检测,算法的考虑,
            10. 自测,是否符合自定义的标准,
            11. 完善文档,
            12. 提测
            13. 测试验收测试,产品验收,准备做设计规范到一个可以随时上线的分支(完成CI ,Soner,代码风格检测,阿波罗等一系类的检查)
13. 测试是否正确,测试进行验收:测试是否符合的测试.验收测试是交付的时候,必经环节,只是每个团队的水平不一.
14. 测试用例中执行步骤:比如描述一个场景:Given..When..Then..
    
    1.  1.  Given 假设一个场景
        2.  When 具体的操作
        3.  Then 断言.验证结果
15. 防腐层: 你的领域层只依赖于你的领域对象，第三方发过来的内容先做一次转换，转换成你的领域对象。这种做法称为防腐层,这样不会受到第三方的改变而改变,有外部的应用一定要做防腐层
16. 用简单技术来解决问题,直到问题解决完成
17. 开发之初便考虑如何测试,并懂的写好测试
18. 在做改造遗留系统的时候,给出的建议:
    
    1.  1.  构建测试防护网的时候,新老系统一致
        2.  分成小块,逐步替换(可以进行灰度发布)
        3.  构建好领域模型
        4.  寻找行业中关于系统构建的最新理解
        5.  小步改造遗留系统,不要回到老路上
19. 想做一件事情一个理由就够了,不想做有一万个理由
20. 领域驱动设计确实是写出合适的代码结构的一项训练，程序员会不由自主地按照自己的习惯，也就是按照计算机运行逻辑去设计代码，这样的代码很容易陷入难以维护的坑。在开始动手写代码之前跟用户交流清楚，理解设计的概念、流程、使用场景、特殊情况，这些都很重要。另外我特别关注的一点是可变项和不变项的分离，因为我们的业务场景对可扩展性要求很高.
21. 重构的定义,有些人认为是重新写代码是重构,那其实是改代码,重构是微操作的实践
22. 拓展自己的**上下文**，看到真正的目标，更好地对**准靶子**，比如，多了解用户，才不至于做错了方向；站在公司的层面上，才知道哪个任务优先级更高；站在**行业的角度，而不局限于只在公司内成为高手**，等等。
23. 做到更加的高效:  去掉不必要的内容,减少浪费比如代码中的减少内存空间浪费,中间件的资源浪费,不做非必要的功能,花时间做好领域设计.花时间进行做自动化,把精力用在编码,工作上
24. 知识的广度和深度
25. ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70 2][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70]: /images/20230528/25007b6294fd4ada812278e70b46b750.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70 1]: /images/20230528/1bfd6a4730b84d3bb4698611ec9cbe12.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjExNDA5Nw_size_16_color_FFFFFF_t_70 2]: /images/20230528/c39b04ab1893413ebee8c472146c76ae.png