Thinking

我还是挺喜欢吃快餐的，基本每周五中午都会固定吃一顿麦当劳巨无霸中号套餐，当然可乐一般不会喝。跟很多人一样，吃饭这事一直纠结着我。每天花心思和时间思考今天吃什么，然后排队等，或者面对琳琅满目的外卖无从下手。。。麦当劳挺好的，比肯德基好吃一点，但是没有汉堡王好吃，可是汉堡王贵啊，麦当劳还是比较亲民的。而且这些快餐绝对干净，吃完绝对不会拉肚子。你也不用思考到底要吃什么，反正就那些东西，从小吃到大。很多人说吃快餐不健康，呵呵，类比“不含糖”的味全果汁系列，其实没有比可乐好多少，而且这些快餐绝对没有地沟油。 午餐还好一点，晚餐是最难办的。不加班还好，可以回家自己做点吃，一旦加班可选择的余地就更少了。我一直希望能有一个互联网思维的晚餐解决方案。我也不用能有多好吃，也不用很多花样，固定几种就行，最重要的就是要方便，要快，健康，别太贵！有肉有菜即可。别让我做选择，不行我多花点钱买个清静。 这就是非常现实的问题，我相信不是我一个人有这个需求，这就是我们现在的生活。我以前从来没有想过如今的生活节奏是如此之快。快到没时间停下来思考，真正有时间停下来思考的时候，又没有时间做出改变了。。。 现在的人，面临太多选择，但是选择的成本太大了，更好的服务才是我们所追求的。 上大学的时候玩wow，那时候wow已经有点走下坡路了，国服更是如此。一个号从无到满级，到装备毕业，都有淘宝店铺出售，玩家只需要花钱就行了，甚至自己都不需要上号。慢慢的游戏也变味了，大家都是快餐，魔兽世界里没有人再跟你一起探险，他们只是买家和卖家。 连知识都能“听”来的时代，时间真的是越发宝贵了。就拿我来说，我自认自己的开发能力就是入门级别的。而且可悲的是，公司的工作不能压榨完我所有的精力。就是说，我从每天8小时工作收获而来的经验和知识不足已支撑我不断提升自己的能力。所以下班后，理所当然的要搞一些高端大气的东西。诚然，国内没多少公司需要招了解底层的程序员，甚至面试官自己都不知道所谓的底层到底是哪一层，这些东西当然也只能利用零散时间自学。所以就在工作的时间赶快把工作做完，尽量别出事故，没事不加班，下班赶紧走人。路上走快点，到家随便吃点，休息一下赶紧开搞。这里也有需要权衡的地方，我是很喜欢健身的，饭后的黄金时段到底干点啥呢？锻炼身体了就没时间搞技术了，但是身体也很重要啊。于是就养成了一个能跑就不走的习惯。半年前开始的，早上赶公交都是跑着去的，尽管那时候是夏天。。。这几个月发现，下午5点钟不吃点东西，很难坚持到吃晚饭，毕竟哥年轻，新陈代谢快嘛。于是最近几个月每天下午去旁边的85度C买面包吃，然后就瘦了4斤：）神奇不，神奇的地方就在于，我是跑着去跑着回来的。。。年后寻思着，写个日程表，把每个星期的事宜都按时间定下来，继续权衡健身和搞技术。 10000小时理论 VS 快餐 面对10000小时理论，是否有健康的快餐服务？这个快餐服务说的就是微信公众号和罗辑思维类型的知识服务。我现在对微信的公众号越来越失望了，干货变软的风向不变，搞技术的也确实不能指望看一篇文章就提升技术，除非你看完了又跟着写了段代码验证作者的想法。基本上，我已经放弃了从公众号学习技术了。公众号就是读读新闻的地方。与提供干货不同的罗辑思维是一个冲击认知的地方，得到APP也同样是一个听新闻的地方，保证你在理论道路上不会走的太弯。但是回过头来还是要靠自己的实践去验证理论学习成果。我认为所谓的10000小时理论所需要的时间会越来越短，因为知识服务的出现，各个领域的知识体系会慢慢变得得体、明确、清晰，你去学就好了。

马上就要过年了，回顾一下2016的成长。 简述 react全家桶太复杂，不能听任大厂任意吹逼，缺点也是技术选型的关键； spring boot隐藏的细节有点多，不看文档不知道的东西太多； checkstyle, findbugs和sonar都是好东西，帮助你写出bug free的代码； Intellij很好很强大，经常更新版本吧，惊喜不断； 使用依赖注入时，不要用field injection，应该配合lombok使用constructor injection； rabbimtq是用来处理CPU密集型的场景，不适合IO密集型的场景； GC的核心是如何做到异步的GC，以及自动调优，期待G1； java不适合做客户端应用，如android。GC严重影响使用，只能期待程序员好好写代码； 同理go不适合写android。引申，go不能做android开发的话，就不会持续的发展； 正确学习java的路径：语法>基础>集合>io>多线程>内存模型>GC>JIT>JVM。 先说前端 2016年的前端应该是前端开发的元年了。这一年发生了好多。。。我从来没想过做专职的前端开发，我不喜欢js这个语言，不喜欢css。但是我不排斥开发前端。毕竟作为最直接的交互界面，前端是很重要的。这一年有一段时间一直在搞前端，用了react全家桶。。。总感觉facebook很不负责任的说，大厂吹的很好听，但是一旦入坑就不是那么回事了。react的难点在于如何一开始构建一个框架，全家桶里的东东实在太多了。。。影响开发体验。不过框架搭起来就好了，模块化代码还是挺好的体验。但是我写前端的时间越长就越排斥前端。心中bgm是：哎，只要把xxx做成xxx就行了，可是好烦啊，不想搞啊，asfjoqwekfhnjr…..还是赶紧搞定去搞别的吧。。。还是喜欢写java。 java 曾几何时，我还是挺不喜欢java的。那时的我还是php神，嗯，PHP is the best language!现在不那么想了，java真的是能接触到的最优秀的语言，而且是最能提升自己对整个计算机系统理解能力的语言。java足够高层，可以对实现做抽象，同时java又足够底层，可以让你放手去实现底层的构建，这一切都需要你去深入到os、cpu、内存中去，去窥探那个奇妙的世界。几个月前开始订阅java社区开发的邮件，期间逐渐证实了我之前的一个猜想——java做了太多努力在跨平台上。跨平台绝对是黑科技！因为跨平台不仅仅跨的是操作系统，还在跨cpu。java要针对不同的os和cpu去订制实现，真的是订制！现代cpu想跑的快，硬件上只能多加core，软件上尽可能的在单个core上完成任务，每个core都有自己的寄存器，实现新的reorder、barrier，但是多线程编程一定要跨线程上下文，阻止reorder，合理的打开barrier。不同的os和cpu有各自不同的实现标准，然而java却要综合所有平台的特性，一再强调跨平台。如果一上来，没有把跨平台作为java 的首要特性，我相信java一定会发展的更好，不过话说回来，如果没有点噱头，估计java都活不下来。 我觉得2016年，我真的是跌跌撞撞地把java打通关了，我可没说我精通，但是精通是早晚的事，2017年差不多可以，2018年以后我就可以放开手脚研究os和硬件了。我发现学java最好的途径还是读specification和官方文档。thinking in java、effective java、JCIP都是很优秀的书，但是有一个问题，这个问题特别像是读技术博客。在博客中，博主对技术的阐述，只是自己的理解，等到读者再读的时候，那仅仅是读的博主的理解而已。这些优秀的技术书籍只能帮助你理解java，但是本质上那都是作者们自己的理解以及他们的宝贵经验。想要了解java真实的一面，还是要下狠功夫读晦涩的说明和相关论文。 一个理论 关于技术，今年我还得出了一个理论：对于客户提出的需求，如果程序员认为这个需求要超过3天才能完成，有三种可能： 需求不合理，不是说不能做，只是不合理，比如设计的功能不应该包含在该系统A当中，应该放在系统B上； 系统架构不正确； 程序员没能力。 这个理论是我从自身出发，并参考其他同事的日常工作得出的结论。需求肯定永远都是对的，只不过提需求的人多种多样，很有可能用户没有受过专业训练，用户其实并不理解自己真正想要的是什么。这种问题慢慢沟通，提供自己的建议就好。第二种可能是灾难性的，架构上缺乏思考，扩展性不够，程序员的锅啊。今后可能因为这个问题出现各种各样的bug，慢慢你就是救火队长了。第三种情况很微妙，很少人会承认自己的能力上限。特别是在工作中，有kpi考核呢。平常开玩笑的时候可以说说，你不行啊，你个弱鸡，你没能力啊。但是大家都是码农，有些事不必戳穿。 要做正确的事 我经常说：要做正确的事。不论是做人，还是做技术。做技术的没有不踩坑的，踩坑了不怕，就看你怎么走出来，怎么解决问题。经常说，哎呀，系统出bug了，要是想彻底修好应该从底层xxxx，但是这样太费时间了，还是先hotfix一下吧。。。我觉得这时候就是体现一个程序员能力的时候，这时候就应该分析清楚应该怎么解决这个问题，然后贯彻执行力，解决这个难题，只有不断的自己跟自己较劲，技术才能不断提升。有时候在修很恶心的bug 的时候，我也很想放弃，换个捷径走，但是我自己是知道的，这个时候恰恰是提升自己能力的时候。因为你在做你不熟悉的事，而做不熟悉的事是最能锻炼人的，你在突破你的瓶颈，冲出你的舒适区。 代码质量 Dijkstra曾经说过一句很有意思的话，大意是： 测试只能测试出测试出来的bug，但是不能测试出没有被测试出来的bug。 那怎么才能找到那些藏在代码中的没能被发现的bug呢？ 不断的看自己写的代码，不断看别人写的代码，这就是一个重构的过程，你总会发现之前想的不周到的地方，开发不是一蹴而就的。而是不断迭代不断重构的过程。程序员不应该把功能开发完之后就万事大吉了，后面随便测测就再也不看了。出了bug甩给别人那简直就是可耻了。。。 最后 自己还有很多不懂的地方，2016再见，2017加油！做一个快乐的傻缺技术男。。。

现在是北京时间凌晨00:47，实在是睡不着，起来写点东西吧。 最近迷上了听“罗辑思维”，经常写代码的时候也听。其实一开始我是没法在写代码的时候听这种东西的，因为会严重分心嘛。但是周围确实又太吵了，听歌又很容易听腻，所以有一天就放着罗辑思维写代码，效果还不错。当然了，我是全神贯注写代码的，很少听罗胖在说啥，只是偶尔停下来听一听，放松一下。其实，这时候我只是需要一个人在我旁边瞎逼逼就可以了：）正好罗胖的声音又是那种我特别喜欢的肉肉的、憨憨的声音，哈哈。 话说回来，罗辑思维这个栏目我很喜欢，喜欢的原因不仅仅是可以在我写代码的时候充当主动降噪的功能，而是可以听一个跟自己没有半点交集的人在跟你瞎逼逼。不能说罗胖说的都是对的，但是他确实在一定程度上改变我，而且是正在改变我！在我听罗辑思维之前，从来没想到这种知识分享可以做到这样的效果。经常看所谓的技术干货，使得我已经对所谓微信时代给我们带来的这些种种，早已失去了兴趣。每天利用零散时间看几个技术公众号就能提升技术？半年前这话我还信，现在的话，我觉得公众号还是用来扫盲比较好。 得到 说到罗辑思维，就得说说得到这个app，今晚睡不着觉，很大原因就是因为它！和他！——王煜全。 先说说得到这个app，这个app在我看来，就是一帮人在里面胡说八道，而且你还得花钱听他们胡说八道，越贵的栏目越“胡说八道”！此处没有半点黑的意思，而是绝对的粉啊！ 你平常所能接触到的人跟你的家庭有关、学校有关、工作有关。我作为一个普通人，我每天所能接触到的人不超过5个，我的圈子就是这么小。。。我的认知范围也就这么小。尽管每天我都会接触各种各样零零散散的信息，但这些信息实在是太碎片了，使得我看到的世界太不真实了。而得到给我了一个机会，可以接触各种各样的人，听听他们的想法，从而改变自己的认知。对和错真的没那么重要，他们是不是在那一本正经的胡说八道也不重要。重要的是，他们都是相对成功的人，他们会对各种问题有自己的态度，听听挺好。 我在得到上买的第一个就是王煜全的“前哨”。乱序听了大约一星期吧，直到今天才真正听到了震颤我灵魂的东西。今天所听的标题忘记了，内容可以理解为：为什么王煜全在美国投资却不去硅谷，真正的高科技创新到底是什么，硅谷的核心是什么。王煜全在前哨中多次提出，美国现在的主流创新是指一个牛逼的教授拿着显著的科研成果加上一个牛逼的CEO。这个牛逼的教授的科研成果领先世界，或者说是世界第一，可以投入生产应用。而这个牛逼的CEO是一个有信用背景的，就是说他／她多次创业成功。那些个vc就是照这样的项目投资。那所谓的科研成果指的是什么呢？可以是太阳能电池载体、可见光、光传输等等，那些在我们周围不怎么出现的，但是一定是有出路的，能标志未来的科研成果。这些科研成功一旦量产，垄断这个词已经不足以形容了。而一个有信用的CEO，多次创业之后，下次创业也更有可能成果。所以vc会主动找到他们，求他们分一杯羹。 那么问题来了， 为什么这些科研成果大多数没有流向硅谷？ 既然这些CEO这么屌，为什么我们没有听说过他们？ 到底什么才是高科技？ 为什么这些科研成果大多数没有流向硅谷？ 这个问题可以转化为硅谷有什么。从王煜全那里听来，大多数硅谷的公司依然是模式创新。确实，像facebook这种的，本身功能并不复杂，只是在模式上创新了。然后就需要迅速的扩张，时时刻刻保持警惕，保证自己在社交领域走在前面，因为毕竟除了积累的用户，其他也没啥优势。twitter其实也是如此，就如彼得蒂尔所说： “We wanted flying cars, instead we got 140 characters.” 他们是创新，但仅仅是模式创新，就算是docker这种技术创新，想尝试解决devops的问题，也会在后来引来新的对手kubernetes。 既然这些CEO这么屌，为什么我们没有听说过他们？ 因为他们不需要出名。相比较本科没毕业，辍学创业，几年后成为最年轻的亿万富翁的CEO，和多次创业，这次又跟某某著名教授合作创业的CEO，显然前者更能捕捉媒体的关注。 到底什么才是高科技？ 不言自明，那些教授的最新科研成果自然就是高科技。最近在用同事的bose qc25，主动降噪真是叼得一逼，只是因为自己不争气，从小就耳鸣，带着听一段时间就头好痛。然而我想说的是，bose的发明人，是一个博士,最初主动降噪是军用的，bose最终将其产品化。可能现在来看这已经不是啥高科技了，但是这就应该是世界前进的方向。好的产品应该帮助我们成为更好的人，过上更加舒适的生活。而不是打擦边球，去约炮、看热闹，或者促使你把时间消耗在毫无意义的事情上面。 由此我在想，我所从事的开发工作能算是高科技嘛？从王煜全的观点看，显然不是。像我这种的程序员，虽然有机会开发比较底层的系统，但仍然是面向业务的。淘宝再大也是一个CRM，你的模式再新颖，你所构建的产品也无非就是围绕CRUD组成的一个或多个系统。这么一想自己好失败啊。以为自己是个匠人，其实也不过如此。你可以说软件是高科技，但不能说每个软件都是一个高科技产品。

想写这篇文章好多天了，一直没得空，今天趁机补上。 事出有因，上周的时候，公司里一个前端项目在自动部署之后就挂了。很神奇，这个项目使用webpack-dev-server作为代理服务器，而我那天只是提交了一个代理路径的修改，从那以后这个url就不能正常被代理转发了，就算改回去也不行。但是我本地环境确是好的…首先我思考可能是devops那边做了配置切换，因为之前是出现过这种事的。但经过多次确认之后发现不是devops的问题…最后我把目光放在了package.json上。最终发现了问题。由于devops在使用docker部署的时候，会每次拉一份最新代码，然后copy过去，重新npm install。而package.json中，我是这么写的 “webpack-dev-server”: “^1.11.0” 。这里的**^**表示，选取小版本中最新版本。恰巧两周前webpack-dev-server发布了新版本，而其中涉及代理转发的部分没有向前兼容，也就是一个巨大的bug… 在知道问题之后，我开始尝试寻找解决办法，github上有人针对这个bug展开了很多探讨，但是并没有合适的workaround。我发现webpack-dev-server中的proxy是实现,依赖于另外一个proxy实现，而且这个proxy在实现过程中又引入了另外一个开源项目…我发现要实现这个代理的功能，我要克服重重障碍，仅仅因为源代码中在开发新版本时，没有考虑向前兼容。值得肯定的是，在原来的版本中，实现代理的功能十分轻松有效。 最近看了很多wangyin的文章，基本都刷过一遍。我现在对于编程的理解仿佛又深了一层。我以前一直认为编程是个手艺活，仿佛旧时代的匠人。甭管孬好，有身手艺在手，至少饿不着。我爷爷就是个手艺人、我爸也算半个。所以，一直以来我都把编程当作一项手艺活，认为自己是个匠人，但从来没想过成为艺术家。看了wangyin的文章，我开始相信编程其实是一项艺术。当你真正了解计算机是如何运行、网络如何传输、程序如何编译，你写的代码不再是简简单单的代码，你看到的不是某种语言的语法，而是真相。 软件是要被使用的 拿webpack-dev-server v1.15.0的这次bug说吧，尽管我可以在此基础上自己实现一个版本，但是我需要花费更多的精力，并且要独自维护。我并不是说这个bug有多么严重，我只是从这件事中得到了启发。有些程序员把代码写的极其复杂，难以理解，用到了很多有的没的新奇技术。他完全没有考虑调用者的感受。而且没有维护代码的意识，这是极其可怕的。交付可用软件是很重要的，以前我也干过那种不通知调用方直接改数据结构的下流事，实在惭愧… 对于新技术的评判和使用有待商榷。我也喜欢用新技术，但是不希望过度工程，把这项新技术强加到这个架构体系上去而不管是否合适，那就是耍流氓。我觉得如果对于新技术的使用存在一个平衡点，那就是简历驱动开发vs系统架构需要。需求永远走在前面。 代码是给人看的 以前我相信好代码需要注释，烂代码更需要注释。现在我不想信了。代码不像自然语言，代码有自己的表达特点，好的代码是有比自然语言更强的表达能力。所以要写能让人看得懂的代码，而不是依赖注释解释这些代码做了些什么。注释的作用应该放在，这段代码当初为什么要这么写。为将来接手的同事提供一个良好的上下文，而不是挖一个大大的坑。 代码不是一蹴而就的 很多程序员都知道这个道理，但是真正意识到这是一个问题的人却很少。我身边的程序员就是这样，他们写完代码测试通过了就大事告吉了，仿佛这段代码已经是完美了，直到下次出现bug之前事不会再看这段代码了。一蹴而就的代码往往经不起推敲，不用说完美，就连能不能正常工作都不敢保证。好的代码一定是自我批判、改造、再批判、再改造的过程。有些程序员会说能程序工作就已经很不容易了。但是我想说，如果仅仅是让程序能够工作，公司招个高职、专科毕业的一样能让它工作，为什么花那么多钱招你来呢？ 测试驱动不了开发 我以前认为开发完毕时，你只完成了一半的工作量。剩下的一半时间你需要测试程序的准确性。这里有一个自欺欺人的地方，你只能找到能够被检测出来的bug，而不能找到出没被检测出来的bug。我以前一直认为单元测试很重要，诚然，它有它存在的道理。但是对于一个新项目，或者说一个新需求，整个业务需求在不断变化，你不知道这个功能做到最后是什么样子的，但是我每次开发完了必须要自欺欺人的写单元测试。然后过了两天不到，这个接口需要或多或少的修改，你就要跟着把单元测试也跟着改掉。从此以后，你会发现你不仅需要维护这个接口，还要维护这个什么都做不了的单元测试。我开始相信单元测试这种东西是用在那些业务不会频繁变动的代码上。而对于频繁变动的代码，单元测试只会增加你的维护成本。 之前看到很多人鼓吹测试驱动开发，他们强调的观点是当你开发一个功能时，先写好单元测试，然后再写代码。或者至少想好怎么进行单元测试，然后再着手写代码，因为不能被单元测试的代码是有问题的，所以需要时刻关注是否能够写出可以被单元测试的代码。但我现在我很好奇他们所在的公司是个啥公司。。。我也想去这样写了代码就不会再更改的公司。 知其然，不如知其所以然 我在日常编程的工作生活中，尽量学习内部实现原理，尽管大多数时候我会忘记。。。但是有一些我却一辈子都不会忘。编程是一件十分有趣的工作，它之所以有趣，我认为是计算机给我带来的种种未知。我到现在不相信，在这世界少有人能精通计算机的方方面面，能把各种底层的实现细节说的一清二楚。如果真有这号人，我觉得他现在一定很无聊：） 学习ArrayList和LinkedList的区别可能是过于基础的，ConcurrentHashMap为何能够支持并发又不损耗性能可能也不难，jvm为什么要把内存分堆和栈，函数式编程到底有啥好，什么是cps，什么是coroutine，java中是否可以实现cps和coroutine，在命令行中启动一个spring boot项目的时候都发生了什么…等等这一切，不就是编程最有意思的地方吗。