上一周的工作对我很有启发，本来想在周会上分享给大家的，可是后来谈我们的新年目标“敏捷”去了，由于时间关系也没有再多谈一周感悟了。
简单的说这周工作中的思考来自于和团队成员的几次争论，我是站在实用的观点，对方站在技术的层面，总结出来有三点：
1. 不要让技术指导业务
这里的业务不仅是指商业上的业务逻辑，也包含常理的意思。技术人员在讨论问题的时候往往容易陷入一个比较荒唐（ridiculous）的思路：先想技术的实现，然后再想业务逻辑。
这里有两个例子：
a). 某业务讨论会上，在场有DEV和QA。我们对某种屏幕跳转方面的逻辑不是很清楚，而且需求说明（FRD）上又没有指出，于是大家都在说自己的观点。某QAMM说话：我觉得应该是从A屏直接跳到B屏，当时用户完成了某种操作之后。。这里的record还没有创建。。那么肯定要先到B屏才能完成record的创建工作。。。我不得不站出来打断，等等，你是在分析业务逻辑，不要把技术的层面加进去，这会形成混沌（chaos）。你作为QA你的业务层面比DEV高，你就只站在用户的角度去分析这里的用户体验应该怎么样，然后我们DEV再来分析技术上的实现问题，技术上不能实现再说，而你不要帮我们分析技术的可行性，尤其是当你在分析业务的时候。
Comments: 从本例中，思考的方式比结果更重要，思考的方式不对即使结果对了，这样的成功也是无法复制的，而且会对未来的设计更大的架构带来隐患。
b). 技术上的DEV之间的讨论。对整形数组进行排序，排序规则自便，只要求客户和我们排序方式一样即可。比较两个整形之间的大小我们通常用>, < , == 之类的运算符，这也符合常理。可是某DEV认为，现在已经有现成的比较字符串的ASCII码进行排序，何不如把整形转成字符串然后用ASCII码进行排序。争论了半天，终将其说服：用整形大小排序比较符合常理，而且设计实现非常简单，并不会耽误我们很多时间。如果为了节省这么一点时间或者因为偷懒而用现成的string算法来排序，诚然是可以的，因为只要求客户和我们排序方式一样，但是会令人感到奇怪，这个非常荒唐。而且从技术角度来讲，这样的算法效率性能并不好。
Comments: 设计方案是给人看的，除非是遇到技术瓶颈不得已用非常猥琐的办法做之外，尽量用符合人之常情的做法，因为技术本身就是对业务的抽象实现。
先想技术的实现，然后再想业务逻辑。这种本末倒置的思考方式是被必杀的。当然也有例外，比如业务逻辑用现在的技术实现不了，或者用的代价太大，那么可以反过来通过思考技术实现来引导出来一个大家可以接受的业务逻辑替代方案，然后跟客户交涉：您的“业务逻辑实现”（注意是业务逻辑实现，不是业务逻辑）稍微改动那么一点点，可以加快项目的进程，从而让您省钱。
2. 设计模式不如实用模式
DEV之间讨论技术方案：一种方案是用三个参数的函数，另外一种是用两个参数的函数。其中都要有个描述排序规则的函数地址作为参数，第一个方案通过第三个参数描述是倒序还是正序，第二个方案则需要写两个函数来实现正序或者倒序。据某DEV说，第二种方案根据设计模式来（未证实），实现正序倒序与排序原函数分离。我要大家扪心自问一下：到底是哪种方案方便？第一种对于每种类型或者每个对象只用描述大小关系即可，而第二种设计模式主张的，需要描述正序或倒序。第二种方案每遇到一个排序需求就得写两个函数来实现倒序顺序，而且大量重复代码，只是返回值不一样。那要是作为一个公共方法，遇到一个大型的系统，那不写死了。
这里不是否定设计模式，而是希望灵活运用设计模式，毕竟在商业软件开发中要注重成本。同样的道理，用最简单代码实现的最优算法不一定好，团队其他成员都无法理解，给后期维护带来隐患。中国别的不多，就是人多，用if else堆来实现逻辑大有人在，虽然很丑，但是很实用。
Comments：马谡：书上说的居高临下，势如破竹，我要在山上扎寨。王平：丞相嘱咐过，万万不可啊，人家围山切断水源放火烧山，后果不堪设想。应该依山傍水，当道扎营。请主将三思。马谡：滚。。书中自有黄金屋，书上再找不到比这更好的设计模式了。。。魏军大喜果然围山并放火，蜀军大败，痛失街亭。诸葛亮不得不挥泪斩马谡，战略上退回汉中。
3. 最难的是承认错误
DEV之间讨论技术方案：某DEV想从数据库里面取出数据，放在一个内存的临时空间，然后遍历这个临时空间，再放到我们的目标临时空间。我认为很奇怪，为什么要放中间一个临时空间而不直接取出数据放到目标临时空间呢？他认为他可以用3行for循环代码简单的实现，而直接放要hardcode太丑了。。我说你这样影响性能，特别是在移动设备上，而且你的方案需要在前期hardcode 20行的数组来实现也很丑，最主要的是这个思路太荒唐了。不服，怎么都不服，于是叫来主管做评判。。评判很快出结果，于是某DEV推翻了以前的作品重来。。翌日，跑过来跟我说，改动之后性能果然提高了很多，而且代码更精简。。。
技术人员都有个心理：在技术上不服输，坚持自己的观点。这点挺好，但是如果在事实摆明的情况下依然坚决捍卫自己的代码，那就是不明智了。其实犯错很简单，因为是人只要活在这个世界都要犯错；不犯错也很简单，在自己容易犯错的地方多注意点，多检查几遍；最难的是当自己的错误被别人指出来后，勇敢并大气地承认错误，并推翻自己之前的方案重新来过。
Comments： Engineer protect his idea and the code which has been written, I respect his idea and his code, but I respect the right logic more.
嗯，技术是死的，人是活的。
