10x程序员工作法
郑晔
火币网首席架构师,前ThoughtWorks首席咨询师 ,TGO鲲鹏会会员
立即订阅
7982 人已学习
课程目录
已完结 56 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 程序员解决的问题,大多不是程序问题
免费
思考框架 (1讲)
01 | 10x程序员是如何思考的?
以终为始 (11讲)
02 | 以终为始:如何让你的努力不白费?
03 | DoD的价值:你完成了工作,为什么他们还不满意?
04 | 接到需求任务,你要先做哪件事?
05 | 持续集成:集成本身就是写代码的一个环节
06 | 精益创业:产品经理不靠谱,你该怎么办?
07 | 解决了很多技术问题,为什么你依然在“坑”里?
08 | 为什么说做事之前要先进行推演?
09 | 你的工作可以用数字衡量吗?
10 | 迭代0: 启动开发之前,你应该准备什么?
答疑解惑 | 如何管理你的上级?
划重点 | 关于“以终为始”,你要记住的9句话
任务分解 (11讲)
11 | 向埃隆·马斯克学习任务分解
12 | 测试也是程序员的事吗?
13 | 先写测试,就是测试驱动开发吗?
14 | 大师级程序员的工作秘笈
15 | 一起练习:手把手带你分解任务
16 | 为什么你的测试不够好?
17 | 程序员也可以“砍”需求吗?
18 | 需求管理:太多人给你安排任务,怎么办?
19 | 如何用最小的代价做产品?
答疑解惑 | 如何分解一个你不了解的技术任务?
划重点 | 关于“任务分解”,你要重点掌握哪些事?
沟通反馈 (12讲)
20 | 为什么世界和你的理解不一样
21 | 你的代码为谁而写?
22 | 轻量级沟通:你总是在开会吗?
23 | 可视化:一种更为直观的沟通方式
24 | 快速反馈:为什么你们公司总是做不好持续集成?
25 | 开发中的问题一再出现,应该怎么办?
26 | 作为程序员,你也应该聆听用户声音
用户故事 | 站在前人的肩膀上,领取属于你的高效工作秘籍
27 | 尽早暴露问题: 为什么被指责的总是你?
28 | 结构化:写文档也是一种学习方式
答疑解惑 | 持续集成,一条贯穿诸多实践的主线
划重点 | 一次关于“沟通反馈”主题内容的复盘
自动化 (12讲)
加餐 | 你真的了解重构吗?
29 | “懒惰”应该是所有程序员的骄傲
30 | 一个好的项目自动化应该是什么样子的?
31 | 程序员怎么学习运维知识?
32 | 持续交付:有持续集成就够了吗?
33 | 如何做好验收测试?
34 | 你的代码是怎么变混乱的?
35 | 总是在说MVC分层架构,但你真的理解分层吗?
36 | 为什么总有人觉得5万块钱可以做一个淘宝?
37 | 先做好DDD再谈微服务吧,那只是一种部署形式
答疑解惑 | 持续集成、持续交付,然后呢?
划重点 | “自动化”主题的重点内容回顾汇总
综合运用 (7讲)
38 | 新入职一家公司,怎么快速进入工作状态?
39 | 面对遗留系统,你应该这样做
40 | 我们应该如何保持竞争力?
答疑解惑 | 如何在实际工作中推行新观念?
划重点 | “综合运用”主题内容的全盘回顾
总复习 | 重新审视“最佳实践”
总复习 | 重新来“看书”
结束语 (1讲)
结束语 | 少做事,才能更有效地工作
10x程序员工作法
登录|注册

答疑解惑 | 持续集成,一条贯穿诸多实践的主线

郑晔 2019-03-11
“沟通反馈”模块又告一段落了,在这个模块中,我们把自己与真实世界的距离又拉近了一步。
一方面,我们强调主动沟通,把自身的信息更有效地传达出去;另一方面,我们也重视反馈,让真实世界的信息,更多地回到我们身边。同学们分享了很多经验,也提出了不少的问题。
在今天的答疑中,我选择了几个非常好的问题,从不同的角度丰富一下之前讲解的内容。

问题 1:单元测试做不好,是否会影响到 CI 的效果?

同学提到
如果单元测试做的不到位,或者不满足 A-TRIP,是不是执行 CI 的效果就会弱很多?
这是一个非常好的问题,问到了各种实践之间的关联。我们在前面用了两讲的篇幅介绍了持续集成这个实践,为什么要做持续集成以及如何做好持续集成。
在自动化模块,我们还会在这个基础之上继续延伸,介绍持续交付,这些内容是从操作的层面上进行介绍,都是对单一实践的描述。
利用这次答疑的机会,我再补充一个维度,谈谈实践之间的关联。
持续集成的价值在于,它是一条主线,可以将诸多实践贯穿起来。也就是说,想要真正意义上做好持续集成,需要把周边的很多实践都要做好。
我们具体地说一下这些实践。但请记住我们说过的,做好持续集成的关键是,快速反馈。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(6)

  • 西西弗与卡夫卡
    老板参加复盘这趴中的安全检查有意思。就像急救流程准则中的第一条,确认环境安全,其次才是进行急救。
    团队中就出现过,复盘过了一段时间,有成员私底下反馈说复盘没有效果。如果当时就能反馈就好了。
    除了复盘,我觉得会议之后也要有检查,让大家投票,会议是否达成目的,会议是否有效,会议是否需要改进,应该如何改善。
    及时寻求有效反馈,是持续改进的要点

    作者回复: 回顾会议一般是定期举行,比如,两周一次,行动项就放在桌面上检查。如果不能做到定期回顾,那倒真的需要安排专门的检查,但那样做就重了。

    2019-03-11
    2
  • WL
    想请教一下老师之前讲测试驱动开发,写测试用例的时候都没有写代码和方法,那怎么写测试,没有方法可以调用,这是怎么处理的
    2019-03-12
    1
    1
  • 捞鱼的搬砖奇
    上面没写完就提交。。。
    代码上持续集成相对好些。首先是拆解任务,把没个任务分成最小的颗粒,每每完成一个就可提交。这里难题是任务分解,如何合理的拆碎任务需要一定时间的锻炼。这个时候可以借鉴行业的最佳实践如果是技术上的可以看看成熟的解决方案等等。深入的学习。

    作者回复: 当你开始把知识贯穿起来,知识之间就了有了更多的连接。

    2019-03-11
    1
  • 捞鱼的搬砖奇
    我觉得程序员自己的学习和提交代码是类似的。前者贯穿不停的学习,后者惯着高频度的提交。
    二者的不同在于学习到了某一阶段,需要换个思路。比如某些时候把发横向学习变为纵向学习,而某些时候有需要把纵向学习改为横向学习。如今的时代信息爆炸,有价值的东西多,噪音也多。两者参杂在一起,难以区别。即便是除去了噪音在一堆信息里找出适合自己的或者自己迫切需要的不是个容易的事情。
    2019-03-11
    1
  • 陈斯佳
    暴露问题是改进的前提。提早暴露问题也能让团队成员能够更好的配合你的工作,使得主要业务进程不会被耽误
    2019-06-06
  • 246小言
    里面提到了用主分支的开发模式,公司里用的是develop的开发模式,对于这种情况,怎么看呢?老师

    作者回复: 主分支模式强调的是一条主干,是 master 还是 develop 并不重要。

    2019-03-31
收起评论
6
返回
顶部