前几天吃了自己的生日蛋糕，28了呀。离那个我觉得应该有事业的30+，又近了一些。最近我在想工作和事业区别，何为工作，何为事业？以前是没有多大感触，现在越来越觉得工作它仅仅是能让你有一份收入，让你不受饥寒。而事业是在你获得到物质收入的同时，还有精神的充实感。事业的价值远高于工作，所以尽量让自己用一份能够为之奋斗的事业吧。
今天在上班的公车上，我听完了极客时间上“左耳听风”这个课程，一共107个章节，真是收益颇多呀。很难想象有人能够把技术规划讲的这么全面，这么深刻。总的来说这是一个“授人以渔”的课程，它在尝试教会你去学习，然后在学习中提升自己，而不是直接把成果放在你的面前。就像它在文章中说的那样，一个走别人的路上山的人和一个自己开路上山的人，差距不是一点点。如果现在的你，有一些职业上的困惑，或是有一些对于自己将来的迷茫，那么我推荐你去看一看这个课程，这是一个工作二十年的软件开发者的总结。
回到今天要说的话，总结一下自己工作七年以来，所信奉的“至理名言”。七年的工作经历中，这个“名言”的集合里，有一些一直在，有一些是后来加入的，当然也有一些随着工作的经历被剔除掉了。
- You do not know what you do not know
你不知道那些你不知道的
这句话是在“左耳听风”的文章中看到的。当时看到这句话的时候，脑子里着实风暴了一把。
三年前，我在一个公司任研发岗位。当时手上的任务是开发一个系统，它能够集成多个不同类型的数据库的数据，来统一为上层提供数据服务，总的数据量在三亿左右。当然该系统必须满足高性能、高可用。历经一年的折腾以后，这款被我们命名成“虚拟数据中心”的产品问世了。
好吧，现在来说说它的几项“如果当时知道”。
- 如果当时知道有Maven，就不用那么辛苦的去网上各种download jar包了，也不用费劲的手动编译、打包...
- 如果当时知道有Git以及GitFlow， 我们就不会揪心于各种代码冲突导致的开发障碍了，有一个合适的版本管理工作流，是多么重要呀。
- 如果当时知道有Dubbo，我们就不用采用java rmi这种原始的rpc方案了。是的，java原生序列化效率真的不高。
- 如果当时知道有Dubbo，我们就不用手动写轮询调用，手动捕获异常重试以及统计权重了。是的，真的很累，而且很难跟踪bug。
- 如果当时知道有spring-boot，我们就不会纠结于各种jar的版本适配问题以及各种繁重的xml配置了。当时想想真的是cry了。
- 如果当时知道有中间件，我们就会知道，这个系统其实就是类似于一个数据库中间件的产品。
一年的时间，我们重复造了一个巨大的轮子。
而这个“巨轮”的产生根源就在于这句话，“你不知道那些你不知道的”。是的，所以搜索引擎也无能为力，因为你根本不知道应该搜什么样子的关键字。
学习的过程，是一个渐渐知道的过程，也是一个渐渐无知的过程。作为一名程序员，一名工程师，你的知识面很重要。至少你得知道个关键字，是吧。
博观而约取，厚积而薄发
很幸运，现在的我们处于信息爆炸的时代，你可以通过搜索引擎找到任何你想要的知识。基于大数据的分析，它甚至会主动的出现在你的面前。
很遗憾，现在的我们处于信息爆炸的时代，充斥在你身边的很多可能都是没有价值的信息，甚至是错误信息。当你无法鉴别真伪，而选择来者不拒的时候，悲剧就发生了。
当然，初期的你会因为获取到这些知识而满足，它给你带来了一种虚幻的成就感和满足感。接着你会因为信息的多而杂乱感觉到焦虑，你无法通过这些碎片来组装自己的知识图。当遇到需要实践到项目的时候，你破碎的知识体系只会让你无所适从。
我明明学习那么拼命，不是吗?
想象一下，我们所接触到的技术博客是作者的总结归纳，一篇千字的文章会涉及到整本书，甚至数本书的知识。你看完了文章，觉得自己掌握那些书，掌握了那项技术。这就像是高中语文考试题中总结中心思想，而你通过看完所有课文的中心思想总结，觉得自己完成了整个高中语文课程。
一个实际例子，半年前我喜欢通过订阅微信的技术公众号来学习，数了下，一共有27个技术订阅号，收藏的文章在数百篇之多。这些文章占满了我的所有碎片时间，每天上班路上、下班路上、吃饭、休息。经过这样大约三个月的时间，我却感觉自己越学心里越没底。有一些文章讲解的框架是四五年前的老版本，有一些文章明明说的是相同的技术，却在论述着不同的观点，更有甚者所记录的完全是没有亲身实践过的技术。以上种种，真是让人奔溃。
博观而约取，我们要学会去辨别哪些是对我们有利的信息。来者不拒的话，只会让自己疲于奔命，而最后一无所获。
好的学习，要有好的来源，如官方的文档、有沉淀的书籍以及身边的大牛。
架构，其实就是平衡的艺术
没有最好的架构，只有最适合自身业务的架构。我们在选择一个新的架构或者引入新的技术的时候，必然会失去一些东西。比如redis cache对于读性能的优化很好，我们选择引入它，那么就会面临一些其他的问题，如系统可用性变低，系统复杂度变高，数据的实时性变差等等。而最后是否还是需要引入它，那么就需要你做好此中的权衡了。简单来说，权衡就在于收益是否大于支出，是的，就像你花钱买东西一样，你只要觉得东西的价值足够大，你才会选择花钱。
那么如果去计算这个收益得失呢？
很可惜，没有准确答案。比如当你的业务只是一个MIS系统的时候，那么肯定没有必要引入如缓存之类的高性能组件，因为你的业务场景就决定了这个不是一个高并发的场景。当然这是一个比较好决策的实例。而对于其他的，就要依靠你的经验，你对于业务的理解程度，以及对于人员、成本等一些外在因素的考量。
好的架构师，好比一个精打细算的小商贩，要计算着每单的支出与收入。
而好的架构，也是在基于实际的业务，计算着各个技术点的成本与收益，然后找到一个平衡点。
技术的价值来源于业务
这句话是我在Qcon技术分享上看到的。我相信这个应该是不少人的痛点吧。是的，无论你研究了多么底层的技术，学习了多么新的框架，你可能都需要回头看看，看看它们是否能够服务于了业务。
我想理想的开发场景应该是这样的：
七八个人的小团队，正着手于公司新业务的从零出发，他们有着身为工程师的荣誉感，有着身为程序员的修养，更有着一致的目的。于是在拼搏若干月后，他们完成了第一个版本的发布。系统流入市场后，受到了很多用户的正面评价，于是一传十，十传百，便汇集了更多的用户。一段时间以后，一些业务的不足点浮出水面，系统也在高并发下出现了延迟不可用的情况。团队于是开始了第二版的开发，针对切实的用户痛点进行需求整改，针对系统的延迟进行优化以及重架构。然后第二版发布，再第三版，再第四、第五...
是呀，让业务去推动着技术的进步，这是一件多么美好的事情呀。
我们不怕开发过程的辛苦-加班、熬夜、无休。我们希望自己的技术能够去服务于一些人，去优化一些事，如果从中还能再得到一些正面的反馈，那真是极好的。
我相信，这才是技术的价值。
