• 哈哈,很有道理,非常对,这样更降低了难度,每次驱动一小步

    • 1、先写一个集成测试,验证它的结果可以得到内容,这个测试就通过了,也证明处理流程是有的。
    • 2、可以针对替换图片的逻辑加单元测试,驱动出来图片转存的逻辑;
    • 3、针对样式调整的逻辑加单元测试,驱动样式替换逻辑;
    • 4、就可以本地启动跑一下,验证拿到的最终处理数据是否正确 不正确,去调整对应的测试; 正确,就将返回结果当作最初的集成测试的验证数据,并让它通过;

    这个时候就做完了。🤓

  • @carlson 1、如果你的测试方法逻辑确实需要这么多的准备数据,那就要去准备呀,可以参考下这个: https://www.codingstyle.cn/topics/175#%E6%B5%8B%E8%AF%95%E4%BB%A3%E7%A0%81%E7%9A%84%E9%87%8D%E6%9E%84

    2、准备的数据太多,也有可能是你这个接口做的事情太多了,单一职责,命令和查询分离,你这个接口是创建一个异步任务,但它却返回了很多数据,它把命令和查询的操作都做了,这个数据是不是可以通过查询接口再去获取呢

  • @carlson 需要写的,但应该针对接口行为去写接口测试,而不是针对 dto mapper , dto mapper 只是其中的一个实现,你一个一个 set 也有可能写错,或者漏写的。

    比如:你要写一个添加用户信息接口,包含了用户名、邮箱、性别。。。

    1、你的输入是什么?相关用户信息的字段要传过来

    2、调用接口执行成功,httpStatus=200,返回用户 id

    3、接口执行成功,你需要校验什么?

    应该去验证数据库中是否已创建用户信息,存储的信息,是否和你输入中的内容(比如:用户名,邮箱...) 是否一致,是否正确

    就像下边这张图一样:

  • 0427 - TDD MarsRover - 复盘 at April 27, 2021

    收获: 锻炼直播勇气😹 感受: 又大胆了一点😎

  • 0317: 结对编程 - 复盘 at March 17, 2021

    收获

    • 任务卡的拆分 如果卡的粒度比较大,在卡里边再做拆分
    • 及时更新卡,要有节奏感,就像 TDD、重构一样,保持节奏感
    • vim f + 字母 F + 字母 向前,向后定位字母
    • git amend
    • git add origin xxx source
    • 出现问题,要看提示,不要猜 ,很多时候非得猜几下 才会去看提示😹
    • diff-so-fancy 配置
  • 重构爬虫项目的反思 at March 14, 2021

    如何识别自己是否坚守这些原则呢

    写了这篇文章之后,对如何判断自己是否坚守了原则,还是有一些疑惑。。。

    然后就去看了 Bob 大叔的《代码整洁之道 - 程序员的职业修养》这本书,在其中找到了压力这个章节其中 - 危机中的纪律,给了我很大的启示,也算是对这篇文章的进一步思考:

    危机中观察自己的反应

    观察自己在危机时刻中的反应,就可以了解自己的信念。如果在危机中依然遵循着你守持的纪律,就说明你确实相信那些纪律。反过来说,如果在危机中改变行为,就说明你并不真正相信常规行为中的原则。

    我们也可以依据它来验证我们是否坚守那些纪律:

    TDD

    如果在非危急时刻你会遵循测试驱动开发的纪律,但是在危机时刻你放弃了这种做法,就说明你并不真正相信 TDD 是有帮助的。

    整洁代码

    如果你平常时候你会注意保持代码整洁,但在危机时刻你却会产出混乱的代码,就说明你并不真正相信混乱会导致速度下降。

    结对编程

    如果在危机时刻你会结对编程,但平时却不结对,就说明你相信结对工作比不结对更有效率。

    时刻践行

    TDD、整洁代码、简单设计、结对编程、用正确的方式做事、以工程师思想去要求自己

    在所有工作中都遵守这些纪律。遵守这些纪律原则是避免陷入危机的最好途径。

    当困难降临时,也不要改变行动。如果你遵守的纪律原则是工作的最佳方式,那么即使是在深度危机中,也要坚决秉持这些纪律原则。

  • 0309:重构爬虫 - 复盘 at March 10, 2021

    感受

    直播一定不要在咖啡厅,要找个安静的地方,谨记!!!😹

    收获

    • 测试数据尽量应该在测试方法中体现,而不是放到提取方法中,以参数形式传过去

    • 不光是业务代码,工具方法也需要注意代码的整洁,方法逻辑处于同一层次

    • testcontainer 消除潜在时间浪费,跑测试时自动起 docker

    • gca 提交代码,可以查看修改并提交 ,代替之前的 git diff ,gc -m” feat: xxx”

    • 按正确的方式开发 ,中间有好几次就想,不用 docker-compose 直接创建一个呢 😓

  • 有新文章更新啦,之前点关注有点问题,可以再关注一下😀

  • 重构爬虫项目的反思 at March 08, 2021

    今天还是又一次犯了这个错误😓 ,发现了问题,就想快速修复它,着急想着上线,就想着在出错的地方进行快速修复,没有仔细考虑,没有想着分析问题根源并加测试修复它,如果这个地方改了,可能其他的地方也会有问题。。。

    还好被拉住了😹

    很多时候,事情都没有那么着急,都是自己在吓自己,催自己。

    想了想,应该是心理层面的压力(线上出 bug,谁写的代码?怎么测的?出事故拉,怎么写的代码。。。),让我放弃了思考。

    当然,毕竟好几年的这种无脑的应急反应,一时间还是很难改正,还得一次次的暂停自己,一次次的反思,来转变这种思维方式或者说是心理压力!

    继续努力👬

  • 重构爬虫项目的反思 at March 08, 2021

    一期加油哈,😀

  • 👍🏻,知识共享,以后大家都可以参考这个来做了😀

  • 是的😅 ,不是,isStarOn 相当于是做了一下封装,不暴露内部的细节

  • 0227:重构爬虫 - 复盘 at February 27, 2021

    收获

    • 尽量用重构手法去改代码,不要手动去改,给构造函数加参数,可以先创建一个构造函数去调用原来的构造函数,再做替换
    • 快速通过测试,写测试时,可以直接粘贴复制参考代码,先快速通过,再做重构
  • tell,don't ask 😀

  • 感受

    • 紧张感减少很多
    • 命名还需要更准确一些
    • 设计原则到嘴边忘了,还需要时常看看,加深印象

    收获

    • 对前端的 js 的不同对象的封装性认识加深 RateItems,RateItem,RateItemState 行为的封装
    • onclick 代表一个被动触发的行为,click 代表的是主动行为
    • service 不应该依赖视图的 class
    • 识别过长消息链坏味道,item.state.getState() 违反迪米特法则
    • tell,don't ask 原则 用命令代替查询 this.state.isStarOn() 替换 this.state.getStarState()===StarState.STAR_ON
  • 0217:重构爬虫 - 复盘 at February 17, 2021

    收获

    今天收获感觉特别大呀

    • git add -u 只提交修改的文件
    • 潜在浪费时间消除非常有意义,工程师思想
    • 意图驱动开发更有感触,想实现哪块逻辑,先把业务行为的方法先写出来,再去实现这个方法
    • 链式操作对象的写法
    • 测试工具 org.awaitility
    • 文档工具 notion 我来
  • 0217:重构爬虫 - 复盘 at February 17, 2021

    是的,mob 的方式效果更好😀 ,如果大家的环境都相对比较安静的话,可以都开着语音,这样有什么问题,可以直接说出来,而不是通过文字去表述,反馈更快速

  • 感受

    • 预估偏差,写 todo list 时,感觉很快就能实现,很多东西其实是没有想到的,只有去真正去写的时候,发现 todo list 粒度有些大了

    收获

    • 前端 js 对组件测试的编写格式 findClasses, not.toBe(true)
    • 响应式方式写法思路
    • todo list 的拆解,或者需求梳理,需要更专业一些,写得时候是可以感觉到的,然后做出调整,但时间已经远超之前的预估时间了
  • 0210:重构爬虫 5 - 复盘 at February 10, 2021

    这个点确实需要描述一下,不然会不知道在干什么

  • 0210:重构爬虫 5 - 复盘 at February 10, 2021

    感受

    • 卡在了测试上,测试一直不通过,很沮丧

    收获

    • 自己的表达能力相比前几次感觉更顺畅了,进步了一点😊

    建议

    • 感觉是不是之前两次直播结束,代码都还有点问题(测试没通过,忘跑集成测试保证对外输出),照着往下写,后边会造成更多问题
  • 程序员应该这样使用 chrome at February 09, 2021

    回头可以分享下这个效果哈,还没用过 😀

  • 0208:重构爬虫 4 - 复盘 at February 08, 2021

    感受

    • 没有写测试,代码就不可能整洁, spider 就是这样一个经历,太深刻

    收获

    • 写测试要灵活,测试数据不需要把所有的数据都造出来,把变动的造出来就可以
    • 小逻辑更要表达意图,不然之后谁也看不懂
  • 02:重构爬虫 3 - 复盘 at February 07, 2021

    感受

    重构过程不可控,会翻车

    收获

    1、重构 pull up 提取到父类可以直接提取为抽象方法

    2、合并方法,不要手动去挪动,先 inline,再 extract 方法

    3、intellij 文件比较

  • 线上结对直播报名 at February 06, 2021

    期待中😀

  • 01:重构爬虫 2 - 复盘 at February 06, 2021

    是的,昨天只是简单说下,背景介绍的不够清晰,下次需要再全面点,背景也可以写到通知里边