Live Coding 第一期 - TDD hangman in Java by 李小波

线上活动 · hkliya · 于 发布 · 最后由 hkliya回复 · 1286 次阅读
1

游戏试玩
观看视频

分享的几个编程习惯:

  • 关掉不用的窗口:保持专注
  • 客户端驱动(意图式编程):先使用,后实现
  • 使用快捷键
  • 尽量少写:写的越少,错的越少
  • 频繁提交:保证工作区是干净的,脑子的负担会小很多

我从大家的反馈中学到了:

感谢「绝对零度」:
给 IntelliJ IDEA 安装 command line tool,然后可以用:idea . 打开项目。

感谢「不好意思,名字找不到了」:
下次可以尝试外接一个显示器,与大家实时互动。

如果觉得分享对你有用,欢迎酌情打赏。


「软件匠艺社区」旨在传播匠艺精神,通过分享好的「工作方式」和「习惯」以帮助程序员更加快乐高效地编程。
共收到 9 条回复
171
aaron · #1 ·

赞,livecoding,感觉是思维方式的整个变化,有了test的保证,重构就更加有信心了

171
aaron · #2 ·

git的缩写能不能分享下怎么做的?

1

#2楼 @aaron
在 .bashrc 里边配置别名就好了。

30
lvjian700 · #4 ·

赞,推荐的习惯有种不谋而合的感觉。

171
aaron · #5 ·

@hkliya 还有个问题想问下,TDD在界面类的coding中该怎么应用?例如像昨天的live coding中的例子,本身是个业务问题,所以在写testcases 很好办,例如可以判断函数的返回值,这样的来验证业务逻辑。但是在例如构建页面的时候?这些testcase该怎么写?例如在IOS开发中,我写一个UITableView,里边有10个Cell。那么在TDD的时候,我要怎么验证呢?验证Controller的返回值?再例如前端开发中,我写了一个table的组件,这些怎么用TDD来实现呢?

171
aaron · #6 ·

不知道我说的是不是明白

1

#5楼 @aaron 我明白你的意思。每个平台都有自己的「UI 自动化测试工具」,比如 iOS 你可以用 Appium。
UI 测试是最接近用户行为的,最能给我们信心,但它执行的速度却比 UT 要慢得多,因为你要启动应用,要登录,要点击跳转到待测试的页面。所以我们会减少 UI 测试的数量。
比如 Hangman 这个游戏,假如我的 UI 用 Android 来实现,我可以把之前写的东西直接移植过去,再用 Appium 或者 Robolectric 之类的工具,写几个简单的测试用例,只保证事件绑定上就行了,因为我的逻辑都已经在 UT 里测试过了嘛。

总结一下:代码逻辑在哪里,就在哪里测试。

79

『使用快捷键』
这让我想起以前和扎西结对时,他教我——用重构的方式写代码,又酷又快还不容易错

1
hkliya · #9 ·

#8楼 @hxfirefox 就是这个意思,能让 IDE 做的尽量不手敲。

需要 登录 后回复方可回复, 如果你还没有账号你可以 注册 一个帐号。