居然一个多月没有发字了，其实也是确实碰到了人生中的一道真正难题，闭关思考了很久，如今似乎柳暗花明，所以继续出来活动。
一直有邮件订阅infoQ，它的《架构师》期刊陪伴了我很多年，从一开始几乎看不懂、到逐渐积累各方面知识和经验后的共鸣。虽然很多时候所在团队规模、水平、业务规模几乎达不到要引入复杂架构的标准，但总是会想，万一业务量上来了呢，万一团队规模上来了呢，我们总得做好一定的准备吧！架构一直在心中！
关于架构的定义，有很多种，但其最重要的特征——架构是演变的结果这一点基本是大家的共识。你可以画出牛逼哄哄的架构图，但架构不是“写”出来的。那些口口声声说能写一个架构的朋友就请先闪一边去，因为他其实想说的是框架。
当一个产品只需要给一个用户使用时，再好的技术用起来都没多大意义。有人问过一个问题，多少钱可以再造一个淘宝，有人回答10个亿，这个回答基本是从技术重现的成本角度，但最终用户数有几个，答案很可能是1。
团队两年前从B2C交易系统中分支出B2B交易系统同时迭代开发，B2B还衍生出多级B2B，当初在考虑是物理分离还是逻辑分离是也考虑了很久。从开发团队分工便捷性的角度，我们选择了物理分离即分成两套独立的系统开发。直到现在看起来，这样的一个选择没有什么不妥。但这是否是一个最佳选择，最佳的标准是什么。当时的团队情况，业务的发展方向与现在有何不同，通过产品、代码，我其实挺希望团队成员试着去总结一下的。
被直接灌输知识在软件开发领域似乎无效，实践出真知，人几乎都是要经历过一遍，才会对面对的事情有所认知，但如果不及时总结和反省，成长是很慢的。为此我甚至一直怀疑自己带团队的能力，程序员单纯的思维方式根本不够帮助团队成功，更遑论打造一个技术驱动或者产品驱动的公司。好的团队不需要leader，因为据说能自我驱动，据说在Facebook这样公司，连产品经理都很低调，一切听工程师的，听起来很爽啊。