发布于
阅读代码是很好的锻炼耐心和毅力的机会
发布于
物联网通信各类消息技术(应用层协议)，各自特点、特定的物联网应用场景
这类协议都直接用于在无线或有线网络环境下的设备之间、人与设备之间的通信，物联网开发者都会与这些协议打交道
发布于
发布于
一、简单明快的早期时代(Web 1.0)
适合创业型小项目，不分前后端，经常 3-5 人搞定所有开发
页面由 JSP、PHP 等在服务端生成，浏览器负责展现。基本上是服务端给什么浏览器就展现什么，展现的控制在 Web Server 层
本地起一个 Tomcat 就能开发，调试什么的都还好，只要业务不太复杂
业务总会变复杂，这是好事情，否则很可能就意味着创业失败了
业务复杂> Service 越来越多，开发的人员从几个 > 速扩招到几十人
典型问题：
Service 越来越多，调用关系变复杂，前端搭建本地环境不再是一件简单的事
团队协作，搭建集中式的开发服务器来解决
对编译型的后端开发来说也许还好，但对前端开发来说并不友好
只是想调整下按钮样式，却要本地开发、代码上传、验证生效等好几个步骤
也许习惯了也还好，但开发服务器总是不那么稳定，出问题时往往需要依赖后端开发搞定
看似仅仅是前端开发难以本地化，但这对研发效率的影响其实蛮大
JSP 等代码的可维护性越来越差
JSP 非常强大，可以内嵌 Java 代码。这种强大使得前后端的职责不清晰，JSP 变成了一个灰色地带
经常为了赶项目，为了各种紧急需求，会在 JSP 里揉杂大量业务代码。积攒到一定阶段时，往往会带来大量维护成本
为提高可维护性 > 前端组件化：
理论上，如果大家都能按照最佳实践去书写代码，那么无论是 JSP 还是 PHP，可维护性都不会差
但可维护性更多是工程含义，有时候需要通过限制带来自由，需要某种约定，使得即便是新手也不会写出太糟糕的代码
如何让前后端分工更合理高效，如何提高代码的可维护性，在 Web 开发中很重要
技术架构的演变如何解决这两个问题
发布于
给公司解决问题的时候，基本都是这样的 Pattern
发布于
设计 架构 架构师
需求、想法变成代码前的过程 > 设计
一些经验丰富的程序员执行这个设计过程 > 架构
与之对应的程序员身份 > 架构师
发布于
负责的业务出了大纰漏，各项指标一路走衰。屋漏偏逢连夜雨，重压之下冰冻三尺的人事问题也同时爆发，业务线上各个职能部门之间开始乱撕。再加上高层的不满和怀疑声不断，一时间有崩盘的感觉
枭雄最爱乱世，几个职能部门的头儿(counterparts)不约而同想借机扩大自己在这个目前极度cross-functional的业务线中的控制权
表面指标不错，管辖的领域一直在扩大，且多元化。自信面对背景迥异，性格张扬，能说会道，且和自己没有合作历史的manager下属或director同事，还可以比较准确地找到他们的优缺点
跟非技术部门交流的机会，Sales Head，Ops VP
Director，要从管理理念和长远战略制定等维度来衡量
Senior Manager的能力范围，瓶颈，团队规模不再和能力大小成线性比
靠一班优秀的engineering managers和tech leaders的助力
管理能力质的变化，对产品定位的影响力，自身的时间分配，处理broken window的策略，跨部门机制优化的参与度和积极程度方面
面对一个烂摊子的时候，难免不自觉地想，首要任务是把烂摊子收拾好。如果这个时候有个人不帮着整理，却在一旁站着说话不腰疼“将来的摊子要怎么搭，卖哪几种水果，分别怎么摆放”，你是不是会想抽丫一巴掌！
那个帮着伙计们一起收拾，没有多去思考明天又乱了咋办的摊主
健康的团队中一定要有这么一个看似袖手旁观却在高瞻远瞩的人
但如果看得到，却没有vision去改变，受制于当下的各种contraints，或是有计划却无法说服决策者，往往是从小循规蹈矩的象牙塔里的人经常遇到的困惑！
人脉。每当真有需要时，遍历professional contacts，发现自己信得过的也相信自己的还是那么几个，要么是前同事，要么是半公半私的朋友。对一个合格的Director而言是不够的
要多招跟自己互补的人，不轻易接受现状的人，善于在不确定性不完美环境下工作的人，懂得防患于未然的人
格局不够大，限制了团队中managers的进步
我们往往把forward looking planning和next year planning混为一谈，下个季度下个半年的planning常常是被动的，不过就是应对incoming requests和安排先前来不及做的backlog
真正的forward looking是要让团队从还债模式变成ahead of the curve！这才是Director+ level应该去关注的事情
“烂摊子”案例中，forward looking更多是为了修复。而那些看似稳步发展甚至是捷报频传的领域，也需要proactive的forward looking。比如说，友司推出了Uber brand的Visa卡，我们的Payments为什么没有做，现在是copy还是leapfrog，哪些才是门槛足够高的differentiators，没有自己的观点是不对的
Data Infrastructure独立出去，因为大数据专家从脸书加盟，更关键的是要把Data打造成作为一家软件公司的竞争优势项目。这就是forward looking战略部署
业界也有不错的例子，比如Stripe从单纯的支付交易处理，慢慢向marketplace of freelancers靠拢，非常卓越的构想
没有专业性，成功指标只能是团队的宽度，用宽度弥补专业深度的欠缺。随着宽度增加，专业性就更薄弱了，进而可能影响到对相关业界发展的嗅觉和敏感度
一个公司涉足全新领域尤其是cutting edge technology的时候，还在摸索阶段时，需要的技术领袖大多是有非常强的专业性，其次才是招募能力和管理经验
发布于
架构师和总监之类的 title 一样，已经彻底被用烂了
具备什么素质的同学是贴合架构师形象的？
业务理解和抽象 代码 全面 全局观 权衡
发布于
可靠事件
补偿
TCC
发布于
系统间通信的主要原理、手段和实现