foo(input, output)，函数内部有一个buffer是1024，如果要测试覆盖所有代码，我的测试size一定要大于1024，光在测试里面构造出一个大于1024的input就会很奇怪，因为这个细节已经被foo封装掉了。所以通过编写测试，你要调整自己的封装，就是把bufferSize暴露出来，这样你的测试的输入的size才有意义：foo(bufferSize, input, output)；那么测试的行为就很好理解了。
]]>如果你测试写Assert.IsEmpty(foo)，那么你首先可一先让foo是null，而不是返回一个empty的东西。这个容易理解，但是却显得没有任何推理。其实IsEmpty逻辑上蕴含了IsNotNull了。如果你在实现Assert.IsEmpty的里面先调用一下Assert.IsNotNull，那么先判断的就是null而不是empty，而foo返回null就很顺理成章了。
]]>1，日期输入框没有对日期格式进行验证，分析：为什么要用一个一般输入框呢？就不能有一个日期输入控件吗？
2，数据库字段可以为空，但是代码的Domain层没有考虑那个字段为空的情况，分析：这个为什么不能通过类似Haskell的Maybe类型系统来解决呢？为什么我们要把Nullable的这个知识分布在数据库，ORM，Domain层呢？我们应该可以通过某些方法把它们集中到一个权威的地方。
3，很多bug很难重现，分析：为什么数据库不设计成只能加记录不能删记录呢？（一种funtional的数据库设计？）就好像财务记账一样，不用橡皮擦，这样我们就能够回到任何一个系统状态。那么重现bug就是小菜一碟了。
4，为什么输入的地方总是缺乏格式验证？分析：为什么就不能把验证集中表现到domain对象哪里，然后用到表现层？就像RoR一样。
从上面的例子可以看出，很多bug都不仅仅能归咎于疏忽或者流程，而是我们现在的应用架构的缺陷导致的。你修复bug的时候不能只见树木不见森林。
]]>所以html标准是一个UnscalableSolutions，它之所以设计成这样是为了减少html解释器实现的复杂性。而把复杂性推给了生成html的代码。而开发人员就是生活在各种UnscalableSolutions或者平台之中的。这就是开发Scalable Application的其中一个难度。
]]>为什么有的代码很难单元测试？
配置可以单元测试吗？
什么东西才需要单元测试？
什么是组件编程？
什么是Convention over configuration?它们两者有什么区别？
为什么Web Container是一个白痴的想法？
首先，配置和编程就其形式而言没有根本区别，你可以用数据形式编程，也可以用代码形式配置，配置跟代码是一回事，配置活动和编程活动是一回事。但似乎配置和编程还是有根本的区别呀？区别就是，配置完全就是为了正确地链接它外部的系统或者组件或者模块（随便你叫什么），所以纯粹的配置是不能被单元测试的，因为要验证它的正确性，必须把它链接的所有东西作为一个“单元”来进行验证，仅仅验证配置本身是没有任何意义的，譬如你验证一个链接字符串有什么意义呢？你要看系统是否能够连到数据库，才是真正的验证。当然连接字符串是否符合一个schma，那是可以验证的，可以成为链接字符串的“单元测试”？
我们再看看编程或者代码，理想状况下，你写的那个“单元”，很可能是跟其他部分没有依赖的，譬如你要写一个堆栈的抽象数据类型，那么它可能跟这个系统99.9%的东西都答不上边，这时，你谈论配置是没有意义的，“堆栈”的正确性完全是它自己作为一个整体是否正确，而这种东西是可以被单元测试的。而这种理想状况只是在系统被设计得很模块化的时候才会出现，往往你写的一个“单元”，有它自己的一些逻辑，但同时又混进了一些“配置”的东西在里面。你的系统设计得越不模块化，你混进的“配置”噪声就越多，就导致你的每一个“单元”越难被单元测试。
组件编程就是希望达到一种模块化，组件是代码，组件的链接是配置。很多人的观念是编程是耗费时间的，配置是不大耗费时间的，所以配置都是好的，但如果配置巨复杂，你的开发效率也会很低下，这就是Java什么狗屁都要配置的恶果。不必要地加入配置，就不必要地加大了配置验证的工作量。Web Container这类主意，把页面不必要地依赖了一个本来不需要依赖的东西——容器，那么你就不必要地又要加入配置了，还有就是配置的验证，你要不停地redploy，reboot这个容器。
DHH所谓的Convention over configuration究竟是啥意思？两者为什么有区别？Convention，就是把配置隐含到每个组件里面了，也就是你不需要你个显式的“配置单元”或者配置文件了，你只要把每个组件作对，那么它就自然整合到大的系统里面了，而如果这种隐含是直观的（譬如ActiveRecord），那么作为开发人员就基本上不需要考虑太多配置了。另一方面，如果你要显式地配置，那么你就有很多可能会出错，同时增加了很多不必要的工作量。同时显式配置必定包括了三个部分，配置本身，被链接的两端。而隐式配置只有两个部分，要相对简单。
]]>Node>>
file: File
toString: ^file.name
但这只是组合，不是抽象，问题就在于你要同时去折腾Node和File两个概念，尤其在递归的结构里面，更加麻烦，而真正的抽象就是建立一个DirectoryNode抽象
DirectoryNode>>
subDirs
roots
...
这样DirectoryNode的使用者就完全不需要理会File这个类了，或者说DirectoryNode遮蔽了File，这才是抽象，因为我们用一个东西遮蔽着另一个东西，系统至少不需要对付两个概念。提供了更好的模块化，因为文件相关的东西全部被封装到DirectoryNode里面。
一般人做抽象常犯的错误就是错把confusion当成abstraction，抽象一定是要砍掉东西的，不是往上加东西的。
]]>就是把所有的概念，方法等等东西以条目形式一古脑地放在一个白板上（这是侦探常用的破案方法），然后一些东西逐渐开始显现出联系，原来分散的东西开始扎堆，随着你的知识的增长，你开始把这些凌乱的东西理出头绪来。
白板还可以帮助你标出那些眼下要注意的东西，譬如你这段时间准备重点加强某些方面，那么你可以把那些东西扎堆。
这个白板我会命名为XYZ Puzzle，就像一个拼图或者谜题一样。你可以用Google Notes或者一些Sticky Notes的工具，甚至像Michael Scofield一样把Stikcy Notes贴到墙上。
]]>