前言
不知不觉，从2015年离开百度，已经折腾创业快3年，创业并没有成功，但是让我学习到了很多很多东西。
第一年创业是公司产品的失败，第二年创业时公司的产品是成功的，商业模式也是成功的（区别于共享单车，共享电单车是具备完整的盈利性的），但是公司未有完整的财务风险控制机制，所以目前进入了一个和小蓝酷骑一样的资金困局。
我并不是一个有明确目标的人，但闲着总是很难受，喜欢有事情做，并且想着把事情做好，在工作上有中等程度的强迫症。
在2017年底的时候，我已经意思到『明确目标』这个问题，并且开始思考，恰好最近又听完罗胖的2017的跨年演讲，提到并解释一个概念"人生算法"，更为清晰的帮助我去思考自身的『核心算法』，基于工作经历和自身特质，我明确了我2018年的一些计划。
这边总结来源于受到唐巧2017年终总结的影响，觉得写年终总结是一个很好的习惯，就像我的领导曾经跟我说的一句话：写点什么，是极好的，会让你慎重，并且促进你思考。
2017年我总结出自己的几个关键字，主要分成技术（互联网技术栈、服务器崩、物联网、信息的选择能力）、产品（合格的产品思维、规律和时间的重要性）2部分。
互联网技术栈
工作7年，前4年其实一直在向别人学习，尤其是在百度工作时，让我有了一定的技术格局（思考的基础是什么），让我能知道什么是好的技术（一个解决方案的出现原由以及迭代变迁历史是很重要的），什么是适合公司当下的解决方案（迭代是无穷的，当下的迭代重点是解决什么问题，未来的路是什么）。
我在客户端开发上已经有了4年的经验，从功能机应用的开发到智能机App的开发，前后做过2个百万日活的App产品（百度糯米和返利网）的核心研发工作，并且在之后3年创业里，一直在负责公司客户端开发的事情，为公司的客户端开发提供优秀的解决方案。
2015年-2016年的创业，自己和身边的人写服务器，用过2种框架Node/Express、Python/Flask结合MongDB。写客户端，写Web前端（Bootstrap + SemanticUI + AngularJS），技术环境艰苦，我有过1年时间的独自行走和决断，创业时间紧迫，往往并没有太多的时间给你去思考，也没有太多的资源和良好的技术环境给你去学习成长，技术栈也很宽，所以都是在自己摸黑走路，并不知道自己的方案是不是优秀的，往往倾向于稳定且高开发效率的解决方案去根据需求开发出产品，但一直以来我心里总是想着：我用过的很多技术，解决方案，其实不一定是最好的，甚至不是对的，所以我心里一直惦记着要去和一流大公司的服务器/前端一一印证一下这些技术的对错以及优劣。
到了2016-2017年的创业，前期我的定位是一个互联网产品经理的角色，公司的技术由另外一个人负责，他带来了他上一级家公司的部分技术团队。当时我对我自己的定位是，这一次看看别人是如何做的（主要对比服务器和前端Web开发），去对比之前一年的我自己选择的创业技术。虽然定位的是产品经理的工作，但是其实更多的是在做一个解决方案和综合协调的工作，老板制定方向，我来思考怎么做才是最好最优的，并且协调各种资源执行下去。
2017年我还从无到有的创建出公司在共享电单车产品上的物联网解决方案，目标简单明确：稳定且安全，毕竟是一个全新的智能电动车产品，用户是要开在马路上的，每次都能开锁成功和安全是2个最重要的因素。物联网的完整解决方案涉及到终端、服务器、App，是一个跨度比较大的系统方案。
完成物联网终端的方案设计和开发后，我把移动互联网端的App的借车还车的整体方案总共迭代了3个大版本，在App端使用了2G蓝牙双通道进行同时开锁，目标是让用户开锁的等待时间降低且成功率提高，并且服务器的处理消耗最优（因为每次借车还车都是一次并发），经过3个大版本方案的迭代，目前公司借车的成功率已经达到了96.8%（如果强制用户打开蓝牙还会在提高1-2个百分点），时间控制在3s内，且能统计好分析每次车辆操作失败的原因。
后来整个产品系统搭建出来，物联网解决方案的确定，产品联调完毕上线，开始运营。
一开始公司车辆的通讯日志因为数据量很大，都是分表存储在公司MySQL中的。在我们产品上线后基于车辆出现了各种问题，每次都让技术部去查问题，流程、沟通、技术部内部查询问题的方式，让这些事情变得非常非常复杂且低效，因为整个事情涉及到了公司内部的运营、客服、技术，公司外部单位的线下合伙人、3个终端设备供应商。我看到了问题，思考了解决方案，加上我自己当时又对技术手痒（有点时间没写代码了），然后就独自一人连续疯狂加班了4天，搭建了基于MongDB的一个具备基础大数据处理能力的日志服务器，对日志信息进行结构化处理，且基于结构化的信息进行车辆的报警监控处理，最重要的为公司客服、终端设备厂商提供了一个Web产品，可以从用户或者车辆纬度去完整的查看到车辆身上发生了什么事情。这个Web产品的出现，让公司最复杂的部分变得清晰且确定，大幅度降低了公司内部以及外部的各个部门的沟通工作，提高了公司各个部门的工作效率，公司客服可以做到从听到问题到给出回复只需要5分钟（期间我多次对公司客服进行了车辆系统的培训）。
随着投放车辆的越来越多，到了2017年9月份，服务器开始崩，为何我用崩这次字，是因为每次出现问题时我的心情是沉重的。我本身具备的特点是对别人处理不了的问题非常感兴趣，想弄懂发生了什么，看看自己能不能解决，于是我开始和公司的技术一起查看服务器崩的原因，当然了，得先花时间去了解他们这一年用的技术。服务器崩的经验我已经完整的写出来，感兴趣的可以见下面的关键字——服务器崩。
11月份，服务器的问题彻底解决，然后我开始结合目前公司的技术进行总结和反思回顾，我在网上看了很多的服务器资料，从Dubbo，RocketMq，PolarDB，Docker，Java Spring Boot，微服务，HBase，Flueme，Kafka等都或多或少的看了。我继续看这些资料是因为我看到了目前公司服务器的如果用户量再暴增100倍时，有一些服务是依然是支撑艰难的，所以根据这个去看网上对于某些问题的解决方案，这样我更能直观的理解这些开源技术所蕴含的意义。并且我还从另外的纬度去印证我的想法，就是经常去听极客时间的技术大牛的直播（百度，易观，链家等）。慢慢的这样走下来，我感觉到我自己的思考还是存在很多缺陷，比如我意识到对于一个大型系统，微服务架构的好处，但是我确遗漏了他的高维护量，至少对于小公司而言是不适合的。
对技术一直保持谦逊，才能不停步，往往才能收获到更多。
12月份时因为要和中移动合作做一个项目，我并不满意公司现有的Web前端，然后又恰好看了架构师大会上阿里系的菜鸟网络的大前端负责人的演讲，所以开始研究大前端这个概念，最终我选用了阿里的Ant Design这样一个大前端技术栈（React，Dva等技术栈）来做新的Web产品，为何我并没有选择自己熟悉的AngularJS这套技术栈，是因为其实我在谋求一个更大的技术栈，阿里的Ant Design恰好满足了我的所有需求。
所以我第一个关键词是『互联网技术栈』，我工作7年，从语言角度上，我做过2年的C/C++客户端开发，做过3年的IOS客户端开发，2年的服务器和Web开发，设计并完成了共享电单车的物联网方案，2017年在公司服务器崩时，我又基于我的认知，主导完成了公司服务器的技术优化和升级工作，在这里我非常感谢公司的技术团队，可以在出现问题时信任我的方案并且坚持做下去。
我在2016年时，除了对我的客户端开发技术，其实对我的服务器和前端开发技术是没有底的，因为我并没有解决过大用户量和并发的问题，也没有和大公司的技术去印证过。但是在2017年，我基于我的认知解决了很多服务器的问题，看到了其他大公司的技术，逐渐印证了我的技术思维曲线是没有问题的，并且是可以解决复杂问题的。
在我1人独行时，我非常需要感谢Github，Stackoverflow，InfoQ，Segmentfault这些好的技术网站，我很久之前和我媳妇说过一句话，互联网的世界是开放的，和其他行业不一样，没有敝帚自珍的行为。我媳妇本身是非常喜欢这样的理念，后来在她的工作中也一样把互联网的开放理念带到了她的办公室，所以他们办公室的人总是觉得我媳妇很不错，和其他教师不太一样，其实我们俩都不是会社交的人，我们只是在别人问我们的时候，努力认真的回答。
在2017年底，我终于可以说，我是一个合格的全栈开发工程师，我可以承担百万日活用户App的架构和开发，也可以开发出用户体验友好的Web前端，也可以开发出支持百万日活且支持并发的服务器（注：目前公司的服务器支撑大几百万日活是有问题的，因为并没有引入更多的好的技术解决方案，但是我知道了做一个百万千万日活服务器时需要怎么做，思考什么问题）。
这就是我的2017年的第一个关键词『互联网技术栈』。
同时感谢在我刚实习时推荐给我读《深入理解计算机系统》的这本书的师傅 —— 汪奇伟。这本书带给我了我一个非常基础确全面的计算机认知。可惜另外一本书《算法导论》，我至今也只读了30%。
服务器崩
2017年9月中旬到2017年11月份，随着投放车辆和用户的暴增，公司的阿里云服务器经历了以下崩：MySQL数据库崩（1次），Socket服务器崩（4次），Api服务器崩（2次），Redis服务器崩（1次），日志服务器崩（1次），最短解决时间是5分钟，最长则是6小时。
在前面的创业里我服务器更多的是用的一个LeanCloud的Baas的解决方案（高效率低维护），这一次公司采用的是阿里云服务器的解决方案，所以我综合学到了蛮多的服务器知识。对于Baas服务器，出现问题时更多的是查看他们本身服务器监控和联系他们的技术支持去理解他们的系统，在使用的过程中期间我发现了很多他们的代码问题，并且提交了issue。对于阿里云服务器，我更多的是学习并部署监控到服务器的各种核心指标曲线，用这些指标曲线去协助定位问题。
监控指定进程的Handle/Thread，如果Handle/Thread持续增长或者暴增说明存在资源的释放问题，或者在极限情况下存在资源的失控使用。
利用TCPVIEW来监控网络的使用情况，尤其是你如果在一台阿里CES服务器上部署了多个服务时，查看未释放的资源PID来定位是哪个模块出现了问题。
根据你服务器的选型安装好相应的APM（Java，.Net，Node，PHP，Python这些都是有的），充分使用好你的APM工具来快速定位到问题，比如某个接口的成功率、平均响应时间、最大响应时间。主动发现服务器异常并且解决，分析发现你的服务器应用性能瓶颈。
Redis服务器的运行参数分析，MySQL的运行参数分析等，这些现成的分析只要你能读懂每个字段的含义，也可以帮助你快速去定位到问题和性能瓶颈。
我的经验其实有限，其实我觉得还有更多更好的工具，我并不是一个运维工程师。
其实一句话：工欲善其事，必先利其器。你需要对你的服务器有一个完整清晰确定且数据化的感知，不要变成一个盲人和靠感觉说话的技术。
下面的是我分享一些我在2017年遇到的服务器故障原因和解决方案，崩的情况其实各有不同（应用服务暂停/响应缓慢/无响应等情况）我就不去一一详细叙述，下面仅作我自己的一个经验分享。
1）数据库崩更多的是基础代码写的不好，通俗的讲就是考虑的太少，又不遵守规则，当用户量大时会暴露出问题。我是不建议MySQL数据库使用视图和事务的（后来看到58同城是也是命令禁止的），因为用户量大，并发多时，事务和视图产生的副表和表锁都会极大的概率把数据库弄崩。然后因为是创业，我们也并没有去单独的购买阿里云的高性能MySQL（存储和计算分离）。规则是个好东西，他可以让你后期少遇到很多莫名其妙的问题。
2）Socket服务器崩，是因为解决方案本身有问题，因为是用C#写的，后来我选用了SuperSocket说服并且鼓励他们重写，重写后随着长时间的运行中间又崩了好几次，为了Socket服务器我通宵的时候估计加起来有20天。其实最终还是代码的细节，因为是Socket服务器，你需要考虑各种极端情况下资源的释放，另外你需要考虑很多的关于并发编程的问题，用Lock时要注意到最差情况 —— 考虑有没有比Lock更好的方案。到了10月份彻底解决了Socket服务器的问题。
从基本不了解，到最后把公司旧的Socket服务器变成一个支持高性能高并发的稳定的长连接服务器，让我成长了很多，首当其冲的就是分析问题的过程和能力，其次是我掌握了服务器的一些运维操作，至少在服务器崩时，我能根据我加的运维监控知道是哪里出了问题，是因为Handle暴增，还是线程暴增，还是CPU暴增，还是因为数据库卡死了导致，服务器是一个生态，崩只是一个表现而已，最终你要能根据你的监控，知道是哪个模块发生了问题。
其次就是对Socket编程和并发编程的理解，因为Socket用的是框架（Java是Netty，C#就是SuperSocket了），所以主要还是在高性能的并发编程上的理解要好了很多很多。
3）Api服务器崩，和数据库崩一样，写的代码质量问题引起，到了用户量上来时，就会产生问题，但是在解决这个问题时，也不能盲目的去查代码，这个是很低效的，正确的做法是引入了APM，这样一目了然的知道每个API怎么样，哪里的代码出现了问题。
4）Redis服务器崩，是因为优化Api服务器时用Redis来过滤一些脏请求，而之前他们选用的Redis库（ServiceStack）访问是有限制的（1小时内最多访问多少次），产生了很多莫名其妙的问题，后来切换到新的Redis库，没有限制，但是他们在Api层并没有及时释放掉Redis的Connect，导致阻塞，系统的TCP Handle溢出（还是从系统运维工具这里的异常指标着手去定位问题）。
5）大数据日志服务器崩是因为Baas服务集群的问题，因为是虚拟机，某个单点的吞吐量不够导致的，虚拟机还是虚拟机，不是物理机。
在解决自有阿里云服务器的这些问题的过程中，再结合使用别人家的Baas服务的经验，其实让我对服务器的整体认知好了非常多，也为我目前的技术栈留下了很多实操，实际的问题处理印证了我很多想法和解决问题方案的正确性。
在这里再次感谢技术团队每次出现故障时（尤其是前几次时）对我解决方案的信任，这个和解决了回头看完全不是一回事，当时服务器崩是一个十万火急的现场里，每个人都有自己的猜测和想法。
物联网
2017年，我学习了很多关于物联网的知识，涉及到嵌入式开发，传感器，服务器Socket，App蓝牙这些模块，因为目前公司是做共享电单车这个方向的创业，需要把传统钥匙开锁的电动车改造成一个App能控制的智能电动车。
在改造的过程中有4点重要的事情。
1）你的车不能被任何一个人拿去换一个零件就能变成自家的可以不用App开锁的电动车 —— 为何不能这样，是因为怕被偷回家用，一旦你的产品具备这个能力，那么你投放出去的车几个月后基本都会被偷和破坏，所以必须要100%不能让自己的产品具备这个能力。
2）系统稳定 —— 别人老是借车失败，无法还车，或者临时停车买个东西，发现无法开锁再骑了，会很急。
3）具备安全性 —— 毕竟是要跑在各个城市的大街小巷里，不能因为车上的智能系统出现问题导致任何安全隐患。
4）自检性 —— 车辆后期维护时不用拆开来检查哪里坏了，可以一目了然的知道哪里出现了问题需要更换
2017年上半年时公司并没有人懂这一块，所以我开始学习物联网模块的很多知识，去仔细聆听各个方案商以及供应商的经验。
共享电单车的物联网终端最复杂的工作其实是整体方案的设计以及联调工作，因为涉及到3个供应商公司（GPS，电池保护板BMS，车辆电机控制器），通讯节点越多，对整体车辆通讯的稳定性有了很高的要求，且联调工作也尤为复杂，所以2017年上班年我有大部分时间都是在深圳跑，和各个公司的技术聊我设想的方案，最后逐渐修正到完善。
当时我每去一家供应商公司，都会尽量多和他们公司的技术聊天（请吃饭，帮充话费这些事情我都干过），询问我的一些疑惑，把我的方案细细的讲给他们听，询问是否有不妥的地方，因为我并没有把握，所以当时非常非常非常的谨小慎微，因为我知道这个东西不是App，不是服务器，有问题可以升级，他出问题后公司需要付出太多。
最终我设计出觅马公司现在的这套智能电动车系统，涉及到了GPS，蓝牙，总线通讯，BMS，控制器，并且投放至今，并没有出现任何问题，在设计这个系统时还加入了很多安全性的思考，所以至今也未发生过一起因为车辆系统导致的安全事故。在部分核心技术指标上，比同行都要好上一些。
信息的选择能力
我习惯把自己放到了解决问题的最后一环里，其他人不能解决的问题到了我这里，我可以解决他。在2017年里，我遇到了很多我并没有任何经验的问题，比如上文已经说过的2个：共享电单车物联网系统的解决方案，服务器崩溃等。
下面我仍然是拿一个技术问题来举例。
1）我一般遇到一个技术问题，会仔细查看报错的英文信息，去理解他说的意思，其实50%的问题在这一步就已经定位并且解决了。
如果自己并不知道是什么问题，那么尽量把先自己的问题变成3到5个精髓的英文单词。
2）打开Stackoverflow，开始搜索，去仔细阅读这个问题的真正的解决方案，另外30%的问题在这里可以解决。
那么还有剩下的20%的问题，或者剩下的更重要的工作！
3）不管有没有解决问题，我都会重新开始描述清楚自己的问题，再次深入去理解我遇到的问题，看能不能，开始在Github上搜，看看是否有框架在解决这个问题，你要知道你遇到的问题别人肯定也遇到过，有些问题改一行代码就可以解决，有些问题需要一整套解决方案 —— 比如说消息队列，业务逻辑越写越复杂，难以维护时如何优化等。
其实很多时候当你把你思考的问题放在百万级用户上，放在并发上时，你就会发现，如果你自己去写，需要耗费多少时间和测试资源。做一个好的技术，是需要习惯把自己的代码放在更大的量级上去思考的。这也是很多开源框架在致力解决的问题。
4）系统性学习你搜到的开源框架，他产生的原因，他解决了哪些问题，类似的还有什么框架，区别是什么，目前的趋势又是什么，尽力去理解他。
PS：当你理解的越来越多时，其实最后你会发现，你会慢慢的形成你的一个由点到线，由线到面的完整的技术认知。
5）然后我还要基于我的项目去思考：此时此刻需要采用他么，如果此时需要，评估对自己系统的影响，如果此时不需要，我在什么时候需要采用他。
6）最后对这一次技术更改的反思和总结。
我简单的描述了我是如何去解决问题的，我称之为对信息的选择能力，关键是你搜到哪些有效的信息，你又选择哪个信息，为什么，应用的如何，有没有做一个总结和反思。
这样的能力其实不仅仅是在技术上，比如我做的产品的工作，比如2017年家里的装修（我家是我自己设计和装修的），阅读。
合格的产品思维：会放弃，想生态
2017年我安心的做了一段时间的产品工作，在做这个工作时，我总是在尝试去摒除我的技术思维，我想重新具备一个产品思维。
为何我要在一开始做产品工作时尽力去摒除我的技术思维呢，因为技术思维是有趋向性的，当你想出一个问题的解决方案，你的脑电波就会High一下。而产品思维不是，你需要在太多太多的东西里选择一个最好的，剩下的全部放弃，所以你的思维不能在High，一High其实就就缺少了继续想更好的产品解决方案的潜在动力。所以产品思维的High是什么呢，我想明白了，所以我放弃了什么功能，我想明白了，之前的几个方案都是不对的，这个才是对的。
所以产品思维就是持之以恒的思考，基于这样，在摩拜还没有出红包车的功能时，我就为公司产品计划了红包车的功能。
技术思维是怎么样把一件事情办好，产品思维是我此时应该做什么事情最佳，我此时不应该做什么事情。
所有的资源都是有限的，产品应该去调度资源，按阶段的去做在每个时间点都有最佳性价比的事情。
所以2017年我一开始设计产品时，是设计了一个最小的MVP产品，去验证市场，有时候在能做的时候选择不做，是一个好的产品应该具备的能力，也就是克制。
当最小MVP产品投放市场后，我遇到了很多莫名其妙的小问题，我觉得理所当然了，用户确不会，所以产品第二个我认为的要点是，一定要直观，如果产品有某些限制，你要具备解释的能力，而且应该把解释的引导放在最合适的地方，用户不是你产品经理，天生对某些细节熟悉，也不像捉老鼠时有耐心的猫咪，不会去看你超过25个字的文案。
所以产品要简单直观，细节要到位。
后来公司产品迭代了好多个版本，我意识到了第三个问题。
我迭代版本是为了什么？我产品发展的方向是为了什么？共享电单车产品到底在售卖什么资源？应该如何定价？
这个问题我想了很久很久，后来有了2点结论，共享电单车本质上是小型无人出租车，产品本质上是在售卖时间，而且售卖不掉这1分钟，会立马过期。想清楚这个问题，我就能计算出，车辆的盈利瓶颈是什么，应该从哪里入手去优化盈利模型。
那么产品的迭代方向是什么？
一开始我做的迭代是把信息清晰有结构的展示，但是总是很迷茫，我难道就没有一个根本性的原因么，我做这个事情的总线是什么？
然后某一天我想到了生态，对，我其实是在把我的产品的小生态给建设的更好 —— 引导用户合理还车，不合理还车受到什么样的小惩罚，合理还车受到什么样的奖励，奖励又能变成什么样的东西给用户兑换等等。
所以目前我能意识到，产品是需要一个生态的，细节的优化本质上是在为产品创建一个更好的生态环境，所以我应该想清楚这个生态。
想清除了生态，你才具备一个尺去把功能排列优先级，去对新的功能/更改做出取舍，去把公司的资源用的更好。
规律和时间的重要性
在2017年，我在思考很多问题时都会尝试引入时间这个因素。其实引入时间这个因素后，你会得到一个全新或者相反的结论。
比如在我们投放的城市允许我们随意还车，那么到底我们应该是随意还车，给用户带来便利性呢，还是应该在停车点还车？
其实如果是在一个城市短时间运营，答案是随意停车更好，赢得口碑和扩散效应。但是如果想扎根于一个城市的交通系统，应该是需要在停车点还车。为什么，其实最终俘获用户的是一个产品的规律性，我做什么，能得到什么。而不是你猜车在哪里，这不利于长期发展和使用。
我这么这么做，就会得到这个这个。
规律，这是一个对用户而言，或者对很多很多人而言都很重要的道理。
我们要尝试建立稳定的规律，一个有95%概率成功的快捷开锁的功能要不要加，答案是不要，因为你引入了5%失败，除非这个5%的失败真的不产生任何影响。确定性，规律性是一个产品很重要的特质。
最终用户习惯用某个产品，其实是用户和产品之间建立了一个稳定的规律。
最终一个产品越走越远，是因为他建立了一个良好的生态。
趋势和格局
挺虚的两个词，而且和实际问题并没有太直接的关联，也并不是很好去描述他。
有一句话说的很有道理，解决方案很多时候都不在问题本身，我们需要上升到一定的格局才能用上策去解决他。
在做事情的时候要多考虑时间线，考虑到时间线，你才能明白，趋势是一件很重要的事情。
举个生活中的例子：刚有小孩的家庭，总会遇到很多新的矛盾，比如当你和老婆/你老婆和你妈争论孩子应不应该吃这个时，这个问题本身是没有解决方案的。在有矛盾时要思考到家庭生活的趋势应该是越来越幸福。当你老婆和妈妈对带孩子应该怎么带产生争论时，也是如此。我在2017年一直在尝试告诉我身边的人，日子要过的越来越幸福，有些话需要重复很多很多遍，你会发现，所有人都信了，日子就会过的简单幸福了，哈哈。
对于自己的事业而言也是如此，你所追求的其实都很难在短时间内到达，甚至是十年内到达，所以你要营造你自己生活、工作、孩子教育这些事情的趋势，把这个趋势营造好，其实目标就是水到渠成的事情。
我个人的理解里，懂得营造趋势的人肯定有了格局的意识。我并不知道这2次词有没有强联系。
管理
2017年我管理了20多人的团队，进行公司项目的开发。
可能是百度带来的习惯，我始终觉得人是自驱的，所以我的管理工作更多的是清晰合理的安排好项目的进度，安排好绩效。
其次更多的是一个承上启下，作为一个老板和员工之前沟通的桥梁。
我并不擅长于复杂的管理，至少目前我更多的是想事情，把事情想清楚，然后就是踏实努力的做事情，且让团队把事情做好。
运动
2017，我或多或少的开始了运动，快30岁了，身体变得没有年轻时那么能折腾，一个晚上熬夜需要3-5天才能完全恢复。
我习惯用Keep进行运动，一开始用Keep坚持了3周，后来膝盖疼，不能跑步，加上连续的下雨，中间间断了3周，但是之前运动时我的食量已经上来了，后面确不运动了，导致我后面胖了8斤。
后来又开始断断续续的运动，倒不是真的为了6块腹肌什么的，只是想着自己能有一个更健康的身体。珍惜好自己的身体是对自己和家庭最大的负责。
承认不足和错误
人的心理和产品设计都是一样的，很多时候堵不如疏，关键是要梳理，很多问题，当你正视他，承认他，其实就已经是在解决他了。
2018好奇心
2018，我的目标是在一个行业，努力安静的做上6-10年，对于我的下一步发展而言，行业的积累是非常重要的，很久之前刘斌曾经和说过这句话，我一直都是很认可，但是那时年轻，选择了年轻人的活法。
2017是我自由自在任性妄为的一个终点站，感谢我媳妇给我的支持。
Keep里说过，自律给我自由，2018开始追寻新的自由。
学习是一个终身状态，得到里这句话说的是极好的，保持我对这个世界的好奇。
最后
微信wujiangwei55，欢迎交流。
网友评论