Something more important than code

[FrankKai]

古人云：闻道有先后，术业有专攻。
要多从大牛们那里汲取经验和知识，才能一步步变优秀。
这篇博客主要记录文章中，视频中，技术分享上等等地方，我认为的非常好的技术相关的观点和想法。

2016年5月，在知乎上听过小爝的live《前端工程师如何不断自我提升》，从此养成了写博客的好习惯。
2017年5月，在知乎上听了尤雨溪的《不吹不黑聊聊前端框架》，接触到很多新的概念，直到现在依然不懂。
2017年10月，在家里看了方方老师的《这些年，中国前端社区在做什么（吐槽向）》，了解到很多前端届的八卦。
2017年11月，回到母校杭电的教室里听了《小芋头君的个人从业分享》，加深了对nodejs的理解，多用于反哺前端开发。
2017年12月，参加了阿里巴巴第12届D2前端技术论坛，参与了几个性能方面的分享，发现BAT级的企业对前端性能有着极致的追求。
2018年1月，看了饿了么前端，《探究Nodejs的服务端之路-黄鼎恒（饿了么前端）》的PPT，对前后端职责的划分有了清晰的认识，前端主要解决快速开发，快速渲染和视觉效果，而后端则主要负责稳定，性能和负载。
2018年3月，在家里看了当当网架构师张亮《从码农到大牛，技术与心境的双重提升》的视频，这是截至目前为止，最言简意赅，最面面俱到，最让人如沐春风的后端角度或者说架构师角度的开发经验。
2018年4月，参加了《有赞前端技术开放日》，对有赞的一些开源项目，以及如何使用Github发布和管理开源项目和CI有了更好的认识，也为自己继续在前端开发领域去深入注入一股鸡血。

其实还有很多没有写在这里，我也不绞尽脑汁去想了，后面如果我再有遇到一些从大牛们那里了解到的好的思想，会及时更新在这里。

[FrankKai]

题目：从码农到大牛，技术与心境的双重提升
分享者：当当网架构部负责人 张亮
关键词：后端，架构

业务功能关注点

1. 业务理解和分析
2. UML建模
3. 数据库表结构设计
4. 选择合适的开发框架

非功能需求关注点

• 安全性
  • sql注入的问题
  • 密码是否加密，明文传输在网上
  • 跨域脚本攻击
  • 托库
• 健壮性
  • 异常导致程序崩溃
  • 性能：锁没写好挂住响应慢
• 可伸缩性
  • 用户量增长提升硬件性能，增加更多机器
• 可维护性
  • 部署方便性
  • 挂掉重启是否方便
  • 运维系统，容器系统

微观关注点举例

• 如何对慢sql创建索引
• 如何保证线程安全(form表单，需要理解线程模型)
• 如何减少Full GC频度(JVM一个小时做一次Full GC,程序暂停一秒)
• 如何使用设计模式(使用已有的发现出来的设计模式，降低沟通成本)
• 如何写出具备表现力强的代码(代码自阐述，注释)

宏观关注点举例

• 如何选用适合数据库存储相应的数据(订单：关系型数据库)
• 如何规划系统的范围划分和拆分(SOA，微服务)
• 如何规范系统间的同步异步通信方式(RPC协议,REST同步，消息中间件异步)
• 分布式系统高可用以及伸缩性如何保障(分布式系统不确定性，不保证信息能够发过去，可能性指数上升，服务治理系统，服务降级)
• 如何考虑资源，调度，运维，监控一体化(自动化运维)

工匠精神

• 守 掌握经典理论(CAP理论，BASE协议)、熟练框架
• 破 修改框架的源码、总结自己的最佳实践
• 离 抛开束缚，自己独立去创造东西

成长必要条件

• 兴趣
• 决心
• 毅力
  成为大牛的先决条件就是想成为大牛，被动得被推为一个大牛是不可能的

一些建议

• 优质完成工作（不能纯研究技术，要做好业务）
• 保持对技术的热情（止步于工作，转管理，技术千变万化）
• 完成一个基于兴趣的作品（当成艺术品去做）
• 维持开放的心态（一个人永远不可能认知所有技术，需要多沟通，多交流，多学习，充实自己）
• 开源，分享，回馈社区（代码被挑战，被质疑，影响更多的人，回馈代码或者是分享文章）

成长目标-专业性的态度

• 框架是设计出来的还是演进出来的？
  开放性的问题，经过层层演进出来的，适配其他技术需要持续演进。
• 如何精炼一个模块？
  好项目：增了多少删了多少，螺旋形方式去精炼
  新项目：增多

成长目标-前瞻性的眼光

• 架构是演进出来的还是设计出来的？
  设计出来的，如果设计不好，那么中间会出现很多问题
• 设计一个世界还是实现一个细节？
• 颠覆一个架构损失有多大？
  更换语言和框架的成本比较高，实在用不了才会去换。

成长目标-系统性的思考

• 方案如何落地？不仅仅是开发者单点，而是用户，开发等组成的闭环。
• 代码提交了就是全部吗？文档，出bug怎么解决。

心境转换

• 责任心（能力越大，责任越大）
• 自驱力（自驱力多强，成长到多强）
• 执行力（系统的尽快地去推，这样才有下一个事情去做）

目标愿景

• 工作愿景：职位
• 个人愿景：收入
• 社会愿景：成为社会的责任，开源项目有issue，推着自己往前走，社区认可度更高

[FrankKai]

题目：有赞前端技术开放日
分享者：有赞前端团队
关键词：开源，CI， 代码规范
这篇博客既包括"师傅领进门"（现场笔记），也包括"修行在个人"（拓展思考），主要对《有赞在Github开源项目实践》的一些记录和思考，文末会有参加这次有赞开放日一些主观的感受。

主任务：

• issue模板如何创建？
  .github(ISSUE_TEMPLATE,PULL_REQUEST_TEMPLATE)
• 标签管理
  可以为issue添加label，注明优先级和issue类型，从感官的角度来讲，为issue加上不同的颜色也显得更有活力些，为全球最大的同性交友网站增添了几分不一样的色彩
• github与CI
  推送代码到github后，自动构建和测试代码，从而阻止bug被部署到生产环境
  有赞的同学主要介绍了两种：travis(稳定)和 circleCI，除此之外Github官方还罗列出Percy，Buddy等等工具，但是没有看到Jenkins， 因为我司在用Jenkins，google到一篇对比三款主流CI工具的文章，：Continuous Integration. CircleCI vs Travis CI vs Jenkins
  引用文章最后的总结：

选择哪一款CI系统？还是那句老话，根据业务场景去选择。
CircleCI推荐用于小型项目，主要目标是Do it ASAP。
Travis CI推荐用于开源项目，因为这些项目会在不同的环境中进行测试。
Jenkins被推荐用于大型项目，可能需要做大量的定制，可以通过使用各种插件来完成。甚至可能改变几乎所有的东西，但这个过程时间成本比较高。所以如果想尽快尝试 CI的甜头，Jenkins可能不是最好的选择。

• github的milestones功能
  milestones可以更好的展现当前项目的进度，也就是说与某个功能相关的issue组或者PR，抑或是二者皆有，方便有能力的开发者更好的参与到开源项目

• 版本发布Semantic Version
  如果仅仅是提交了一个微小bug，不要升级主版本了，升级修正版本即可。
  基本格式是这样主版本号 . 子版本号 [. 修正版本号 [. 编译版本号 ]]
  关于版本号，react从v0.14.8直接升级到v15.0.0还蛮有意思的，单纯从版本号上去看，举个不恰当的比喻，有一种瞬间从鸡蛋长成公鸡的感觉，不过这并不影响react的强大。
  编译版本号还蛮有趣的，比如angualr的6.0.0-rc.5 ，6.0.0-beta.8，其中rc和beta代表什么意思呢？这就可以和下图的软件生命周期对应起来了。
  

• 如何保证入库的代码格式一致？
  prettier，gofmt，refmt
  这个我司在用的Gerrit很像，但是又不完全像，Gerrit是人工的做code review，主要检查代码的正确性，对于格式其实并不能检查出来，当然使用eslint也可以去规范代码格式，但是eslint的规则是可以人工手动修改的，所以在代码入库前，再做一次代码格式规范还是蛮有必要的。
  我想下面这3个工具结合起来，入库的前端代码一定很优雅。

eslint→Gerrit→prettier

• 开启github的squash merging
  可以压缩多个提交到一个提交，之前只知道使用git commit --amend添加忘记的文件到单个commit，没想到多个commit还能合并。

副本：

• chrome插件可以拦截请求
  改天试试看，当然不是用postman去拦截，改天（等能力达到）写个插件玩玩。
• zan-proxy与any-proxy的对比
  两款都没用过，不过听德来前辈将是类似于ss的一款代理工具，改天用过两款大牛们写出来的玩意儿再来填坑。
• zan-api与大搜车的easy-mock对比
  easy-mock已经十分好用了，看起来zan-api的功能更多一些，到时候可以试试看，都用过后再来填坑。
• Hession协议解析
  头一次听说这个协议，查了下资料，不过还是仅仅能看懂简介的水平。

Hession二进制web服务协议
Hessian二进制Web服务协议使得Web服务可以在不需要大型框架的情况下使用，而无需再学习另一种协议字母表。由于它是一种二进制协议，因此它非常适合发送二进制数据，而无需使用附件来扩展协议。

• alinode仅支持阿里云的服务器
  因此有赞团队基于koa2开发了一个"阿童木"node框架。
  由于我一直在2B企业工作，所以知道对于银行，医院，运营商或者一些传统的企业，为了保证数据的安全性，都有自己专门的服务器，而不会选择公有云的方案，私有云是更好的选择。由此看来，产品与业务的关系是紧密关联起来的，技术能力只是一种服务于业务的手段，可能需要根据业务场景去找不同的技术解决方案。

Others:

• 主办方很有心，细节做的很好
  纪念品很实用，演讲者经过多次预演，QA环境很有耐心，茶歇供大于求，发票提供免费邮寄，会后在有赞官网的文章中罗列出了与会单位的完整名单。
• 有一个好的团队以及有想法的leader很重要
  好的团队体现在有赞的同学喜欢撸工具去解决问题，往小了说，这是一种提升工作效率的方式，往大了说，这是一群有想法的同学的方式，没有枪，没有炮，我们自己造，其实仔细想想，在业务非常饱和的情况下，还能抽出时间去开发工具，真的很不容易，真心佩服，而这一点，与一个有想法的leader是分不开的，施德来前辈的"牛逼的技术是被业务逼出来的"这个观点我十分赞同，业务场景复杂，才会遇到奇奇怪怪的问题，坑踩多了，技术自然而然就提升起来了。
• 前端妹子依旧很少，分享者清一色汉子
  再一次亲眼验证了前端汉子占绝大多数的事实，和上次参加D2的感觉差不多，有区别的在于，上次D2还有零星的几个妹子有分享，这次有赞技术开放日清一色的汉子，希望下次有妹子做分享。
• 听不懂的还是不少，需要提高
  可能和前端领域的业务场景有关，我一直在做2B业务的企业中工作，对于互联网式的开发场景有微小的陌生，也和目前的能力有关，底子需要更加扎实，实践需要踩更多坑。年前有赞面试凉了很大程度也是这个原因。
• 面基的好机会，存在潜在面基对象
  偶遇同届点我达的小干同学，茶歇的时候聊的很投机。偶遇学弟，虽然没有面基，但是在微信里聊的很投机。潜在面基对象，转专业后的班级大一的班助，两个同学向我推荐，但是由于懒就没主动去。

总而言之，参加了这次有赞前端技术开发日，不能说瞬间提高多少水平，但是我相信日后会潜移默化对自己的前端开发领域的硬技能和软技能有所提升。有的时候，参与技术分享，并不是想从分享者那里Get到多少东西，可能是某个清晨从床上睁开眼的瞬间，大脑里会闪过一个想法：除了自己，还有很多同学，日夜奋战在前端开发领域，他们也和你一样，在用自己的双手努力让这个世界（用户界面）变好，你需要向他们学习。

That 's it !

[delai]

总结地很用心，在奔跑中造车确实需要点勇气和毅力

[FrankKai]

题目：公司内部code review
Presentation地址：https://slides.com/piedpiperkai/code-review#/

CV流程：

• 选择近期工作中的一个功能
• 梳理出相关代码逻辑
• 向评审者讲解开发思路
• 提出自己的疑问

QA环节：

• code review是建立在代码规范的基础上
• 标签怎么分类的
  • 可以用loadsh的group by
  • 图标可以尽量在awesome icon之类的苦库中去找
• 表格有做好的组件
  • 公司有现成可以用的，尽量使用可以用的
• easy-mock新项目没有在用，可以尝试引入
• 如何在多次单个查询与单次多个查询间选择？
  • 数据量大时需要分开处理
  • 数据量小时io成本很高
• 频繁切换branch是否会影响开发效率？南瑞||辽电？
  • 有bug时bug优先
• 对于小白有什么建议？
  • 写多了就自然而然会了
  • 少挨骂：怎么能写出好一点的代码，让后面的人少骂一点
  • 可读性很重要，性能后面可以慢慢调，否则后面的人拿到以后遇到一行莫名其妙的代码，只能开骂了

Thoughts：

• code review对于新人成长来说有很大的帮助
• 除了code review，希望能有前端小组周会，共同讨论一周工作中踩到的坑，促进团队共同进步，提高代码质量和开发效率
• 希望能有前端技术分享，鼓励团队成员学习新技术，并且应用到项目中来