本文发表在 rolia.net 枫下论坛顺便说一下一个 coder 应该有的最最基本能力：基本逻辑推理，归纳，抽象
有了基本逻辑推理能力，你至少能写好一个 method。
有了归纳能力，你能写好一组 methods （该在哪里实现的东西就在哪里实现），进而能设计合理的 class，做到符合 single responsibility principle.
抽象能力需要一点点天赋 + 很多实践经验。顺便说一句，这个技能 coder 需要，BA 更需要，虽然抽象的最终目标可能不同。
如何把用户需求抽象出来？一般书上都会举一些 employee, manager 之类的例子，大学教程里面会用 animal，cat，dog lol....
那些例子没有一个是错的，但是很多人很多年以后，”抽象业务需求“ 还是停留在拟人或拟物的思想境界...
看到过 jr dev 纠结于 book.Save() 是不是个好的 design -- book 能 save 它自己么？
看到过 jr dev 纠结于 fish 到底什么时候 implement 吃或被吃的 interface? hmm, 吃，或被吃，真的是个问题。
...
其实说破了很简单，你需要从业务需求的角度来做抽象设计，你的 fish class，根据你的客户是 1 餐馆， 2 fishing club，3 kids who play your fishing game，是完全不同的。
一旦跳出了拟人拟物的套子，很多问题就迎刃而解了，你多半不会纠结于 book.Save() vs bookManager.Save(book) 了。
完全理解需求，明白如何抽象，good。但和能设计出可扩展的抽象，还是有一点点距离的。
关键点在于，你是否能够预测需求的变化趋势 ---- 这个需要实际经验来弥补了。
返回来说 coding.
完全理解需求，明白如何抽象 --- 你的 class diagram 看上去简单，漂亮 ---- 连 BA 猛一看，都会说，这有什么难的，这不就是我的业务需求么（呵呵，几乎是的，这里省略 100 字，有时间再说）。把 code 写得难懂，猴子都会，写简单了，才能算是 coder。
-----------------------
同时，你的 code 要至少能 unit testable。
TDD 之所以重要，是帮助你验证你的 design 符合 single responsibility principle.
一个 method 里面做了太多事儿，你很难写出一个简单，漂亮的 unit test for it.
一个 class 里面做了太多事儿，你很难写出一个简单，漂亮的 unit test for it.
一个 method 里面有太多的 dependencies，你很难写出一个简单，漂亮的 unit test for it.
一个 class 里面有太多的 dependencies，你很难写出一个简单，漂亮的 unit test for it.
所以你觉得你设计的 class diagram 简单漂亮之后，写 unit test。如果你纠结于一个 unit test 很难写 ----- 多半你得改进你的设计。
unit testable 之后 ---- 真的所有的 method 都要有 unit tests 么？
真的。
真的么？
真的。
真的么？
好吧，你自己看着办吧。
很多人（比如我自己）的理由是，我写了那么多 unit tests，业务需求一变，30% 就废了，我的 design 很好，业务需求变了，我的 design 很容易适应，但 30% unit test 得老老实实重写，真的要么？真的真的要么？
真的。
如果一个需求会导致 30% 的 unit tests 重写 ---- 没准儿你的 product owner， scrum master, QA manager, DEV manager, VP... 得有个心理准备... lol...
会有 （之三）么？更多精彩文章及讨论，请光临枫下论坛 rolia.net
有了基本逻辑推理能力，你至少能写好一个 method。
有了归纳能力，你能写好一组 methods （该在哪里实现的东西就在哪里实现），进而能设计合理的 class，做到符合 single responsibility principle.
抽象能力需要一点点天赋 + 很多实践经验。顺便说一句，这个技能 coder 需要，BA 更需要，虽然抽象的最终目标可能不同。
如何把用户需求抽象出来？一般书上都会举一些 employee, manager 之类的例子，大学教程里面会用 animal，cat，dog lol....
那些例子没有一个是错的，但是很多人很多年以后，”抽象业务需求“ 还是停留在拟人或拟物的思想境界...
看到过 jr dev 纠结于 book.Save() 是不是个好的 design -- book 能 save 它自己么？
看到过 jr dev 纠结于 fish 到底什么时候 implement 吃或被吃的 interface? hmm, 吃，或被吃，真的是个问题。
...
其实说破了很简单，你需要从业务需求的角度来做抽象设计，你的 fish class，根据你的客户是 1 餐馆， 2 fishing club，3 kids who play your fishing game，是完全不同的。
一旦跳出了拟人拟物的套子，很多问题就迎刃而解了，你多半不会纠结于 book.Save() vs bookManager.Save(book) 了。
完全理解需求，明白如何抽象，good。但和能设计出可扩展的抽象，还是有一点点距离的。
关键点在于，你是否能够预测需求的变化趋势 ---- 这个需要实际经验来弥补了。
返回来说 coding.
完全理解需求，明白如何抽象 --- 你的 class diagram 看上去简单，漂亮 ---- 连 BA 猛一看，都会说，这有什么难的，这不就是我的业务需求么（呵呵，几乎是的，这里省略 100 字，有时间再说）。把 code 写得难懂，猴子都会，写简单了，才能算是 coder。
-----------------------
同时，你的 code 要至少能 unit testable。
TDD 之所以重要，是帮助你验证你的 design 符合 single responsibility principle.
一个 method 里面做了太多事儿，你很难写出一个简单，漂亮的 unit test for it.
一个 class 里面做了太多事儿，你很难写出一个简单，漂亮的 unit test for it.
一个 method 里面有太多的 dependencies，你很难写出一个简单，漂亮的 unit test for it.
一个 class 里面有太多的 dependencies，你很难写出一个简单，漂亮的 unit test for it.
所以你觉得你设计的 class diagram 简单漂亮之后，写 unit test。如果你纠结于一个 unit test 很难写 ----- 多半你得改进你的设计。
unit testable 之后 ---- 真的所有的 method 都要有 unit tests 么？
真的。
真的么？
真的。
真的么？
好吧，你自己看着办吧。
很多人（比如我自己）的理由是，我写了那么多 unit tests，业务需求一变，30% 就废了，我的 design 很好，业务需求变了，我的 design 很容易适应，但 30% unit test 得老老实实重写，真的要么？真的真的要么？
真的。
如果一个需求会导致 30% 的 unit tests 重写 ---- 没准儿你的 product owner， scrum master, QA manager, DEV manager, VP... 得有个心理准备... lol...
会有 （之三）么？更多精彩文章及讨论，请光临枫下论坛 rolia.net