about coding

[nobrick]

@hymRedemption 我看了最近的 PR 以后，觉得实现得非常好，但是也觉得在方法上可能存在一些问题，这里主要说说我自己的个人看法：

PR 和 git branch、commit 的粒度过大

一个 PR 或者 branch 里面包含了过多的不相关内容，不利于快速跟进代码变化，也给 code review 带来比较大的困难。而每个 commit 的粒度过大首先会导致实际 commit 的内容很可能与 commit message 的描述有较大差异，增加协作时的理解难度，其次会导致 commit 和 push 的频率很低，比如仅在提交 PR 时 commit，所有的讨论也只能在 PR 提交的时候才进行，这也非常不利于交流。

对于个人项目来说，随意使用 Git 甚至不用版本控制工具（使用 Time machine 来取代）都是完全合理的。但 VCS 对于多人协作来说，是很有必要的，给 merge 带来很大便利的 Git 更是如此：频繁的 Git 操作虽然在一定程度上增加了开发时间开销，尤其最初也许会不习惯，更加分散注意力，但逐渐习惯、熟练以后，其实会带来很大的好处，不仅仅是更有利于协作（疑问可以及时得到解答，潜在 issue 也许可以避免），其实也是一种自己管理代码的有效方式，比如我习惯随时执行 git diff，执行的频率差不多接近 TDD 的频率，可以比较好地回顾自己的代码变动，如果一直追求 better way to code，这可能是一种方法。

commit 的代码不见得就一定要保证完全正确的，我的理解它只是代表做了一件事情，哪怕仅仅是一个单纯的 migration 这样的小事。这样保证了 commit 的原子性，一个 commit 有独立的目的，不夹杂过多的“私货”，才能不致于把所有的代码变化全都 commit 到一个 branch 上面去，这样产品本身也可以按照功能快速迭代，而且随时比较 commit diff 也有利于提高代码质量。

测试过少，重构困难

Ruby 作为一个 duck typing 的语言，灵活度很高，但是在我看来也非常容易出错，尤其是在重构的时候，看起来利索无比的代码，可能一不小心就输出错误或者抛出异常了。所以测试是保持程序正确性、稳健性的重要手段，就我所知，是目前可以保证重构尽可能正确的最有效方法。

仅依赖于 seeds 在 dev 环境产生数据进行人工验证，首先在软件复杂度、业务逻辑不断上升的情况下，人工验证的成本也越来越高（虽然也很有必要），而且如果 seeds 本身没有模拟足够“真实”的数据，这种数据不一致带来差异也会带来一些问题（比如出现 exception，而且是在 dev 环境下无法利用测试检验）。

这个问题其实也不用多少了，看看 Ruby 的各个开源代码项目就知道了，即便 DHH 不赞成 TDD，他也说了 long live tests，Basecamp 的 repo 测试率也达到了 0.6 以上。

命名和组织结构不够规范

哲学家这么说：

There are only two hard things in Computer Science: cache invalidation and naming things.

所以命名确实是一个很困难的问题，我也经常遇到想不好该如何命名某个 object 、该怎么组织代码。但我确实觉得命名非常重要，都说好的代码是自明的，虽然做到这一点确实很难，但重视以后就可以更好地改进：比如我一开始不清楚电商系统的一些状态的命名，所以就多去参考一些相关的开源项目，学习他们的命名方式和代码结构。再比如，如果名称上面建立了两个对立的方法，那么他们的行为也应该尽可能地对立，不应该产生一些与直觉不符的行为。

我觉得其实这个问题也和前面两个问题有比较大的关联，如果快速提交小而美的 commit、PR，在多人协作的环境下，大家可以集思广益更好地商讨命名问题，我觉得这可能也是开源的思维方式：Rails 在 Github 上经常讨论一个方法的 signature 应该如何设计。当然咱们并不是做 API 和框架，并不需要那样细致，但至少一起考虑名称的合理性有利于代码的可读和维护；另一方面重新命名其实非常普遍，而且对 Ruby 来说并不像 Java 那样自动化，也完全可以算作一个重构了，因此测试对于重命名也很重要，也许会减少因为“仅仅重新改了方法名和几乎所有的引用但是仍然出现exception”的尴尬了。

[hymRedemption]

嗯，我确实应该注意这些问题。我可能原来的想法是不要将为完成好的代码提交上去，而且有时候在完成一个功能的时候会发现之前的实现有些问题，所以代码写着写着又去修复 bug 了，这样下来有时候一个 branch 可能完成的东西并不单一，就造成了比较大。
关于测试和命名也是一样的问题。命名想不到的时候，有时候有点随便凑个命名就行了的想法。而测试可能是相关内容并不熟悉，可能有时候写个测试还要去看大堆其他的资料，所以有时就不太愿意去写（特别是去设置测试时需要的状态的时候，发现所学的东西严重不足）。
不过现在我也发现，确实测试少了或者命名有问题，随着项目变大，给后面的开发确实带来不少问题。所以我这些问题慢慢去纠正。
谢谢你的建议！以后还是多交流，确实实践得太少了，很多不足的地方。

[nobrick]

好的，测试这个我记得有人说认为花在学习 RSpec 这样的框架的时间和学习 Ruby 本身的时间是差不多的。。另外主要也是一个习惯问题，我在以前写程序的时候也是这样，越是不写越是不愿意去写，因为觉得很麻烦，实际上在后来强迫自己去一点点尝试以后也发现测试越来越好写，而在程序规模变大以后也发现测试带来了太多好处。

一起慢慢成长改进吧~

Regards,

Ming

On Apr 16, 2016, at 9:42 PM, HS notifications@github.com wrote:

嗯，我确实应该注意这些问题。我可能原来的想法是不要将为完成好的代码提交上去，而且有时候在完成一个功能的时候会发现之前的实现有些问题，所以代码写着写着又去修复 bug 了，这样下来有时候一个 branch 可能完成的东西并不单一，就造成了比较大。
关于测试和命名也是一样的问题。命名想不到的时候，有时候有点随便凑个命名就行了的想法。而测试可能是相关内容并不熟悉，可能有时候写个测试还要去看大堆其他的资料，所以有时就不太愿意去写（特别是去设置测试时需要的状态的时候，发现所学的东西严重不足）。
不过现在我也发现，确实测试少了或者命名有问题，随着项目变大，给后面的开发确实带来不少问题。所以我这些问题慢慢去纠正。
谢谢你的建议！以后还是多交流，确实实践得太少了，很多不足的地方。

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub