二月总结

工具: 暴露端口到公网

工具: localtunnel 评测: 速度太慢, 不太实用(也许到了国外会好很多)

OOP

说起来, 要真的让我阐述 OOP, 我又有点讲不清楚了?! 始于入门, 手写教材和工程样板一样的OOP, 眼观耳闻 OOP suck 的舆论. 去尝试斡旋两种力量, 会觉得有点性格分裂. 甚至于, 我的日常已经多范式了, 稍微有点无法看清什么是纯的OOP. 有一些不错的切入点, 比如如何写成风格不好的OOP, OOP哪里不好, 终究会有点隔靴搔痒. 试试看整理下自己对OOP的认知.

什么是 OOP

对象是一些方法的集合体,  对象内方法通过共享局部变量通信,  对象间通过消息传递通信. 接口约定了外部调用的方法和数据, 谓之封装. 在兼容接口的基础上完成部分方法的其它实现, 谓之继承. 继承链上的方法调用的识别与派发, 谓之多态. OOP是一种用对象来组织代码的方法论.

OOP 为我们带来了什么?

• 隔离接口与内部实现
• 语言内建的消息派发

OOP 还为我们带来了什么?

• 一切皆对象的误区
• 可变状态, 邪恶的根源.

什么时候用 OOP?

• 当需要一套接口时;
• 当需要派发消息时;

什么时候不能用 OOP?

有时候, 数据就是数据, 方法就是方法.  不要闷声做大死的一切皆对象. 甚至, 在某种语言里, 数据和方法没有严格的边界, 谓之 homoiconic.

一些思考

• 从数据流向的角度来设计系统.
• 貌似总可以用函数与数据结构
• 貌似总可以用组合, 而不需要继承
• 依赖接口, 而非实现
• 不可变的设计毫无疑义优于可变的设计

Haskell

稍微搂了一些简介, 一个 Monad 的Video, 还尚未有很强大的动力学习, 时间配给不足

Flux Dispatcher 与后端

后端代码经历一段时间的演变后, 必然会走向拆分, 功能性的代码拆分成可安装的库, 服务性的代码拆分成 stand alone service 供其他使用者调用.

方法依赖现在可以被各种 gem, pip, npm 支持的很好, 然后服务依赖现在鲜见广泛使用的标准.

Flux Dispatcher 是一个很值得参考的方法. 随着应用规模的增长, Service 的相互依赖甚至也有可能出现. Service A 可能需要 Service B 先执行一些方法, 再执行自己的方法. 对于调用方, 需要一个显式声明这种依赖的功能.

如此这般, 我们可以在并发和顺序之间得到比较好的平衡.

React State && Props

老是搞不清楚二者的差别, 但大概是这样的:

• 父亲组件的Props, 如果子组件需要用到, 则会是子组件的Props;
• 类似于 Python 的 @property 装饰器, 能被延时计算得出的值不需要成为State;
• 可变的值应该是 State, 不可变的值应该是 Props;

想去的地方

• NZ

新西兰是个不错的国家, 值得去一趟看看, 走走, 停停.

入手新西兰旅行的小册子.

• 箱根神社

老帖重翻

• 12-Factor Apps
• 傻瓜函数式编程

软件架构

架构指的是软件整体结构与组件的抽象描述. 它描述了组件的通讯, 用于表示组件的连接.

经典的4+1视图:

• 逻辑: 功能需求, 对象组织. 这块练习一直很少, 需要加强.
• 开发: 可扩展? 可重用? 已测试? 易维护?
• 处理: 运行时特性. 这块基础知识也比较薄弱. 需要关注: 进程, 线程, 对象, 并发, 同步, 异步, 通信等等. 春节期间主要回顾了大学学的一些经典: 信号量, 临界区, 生产者消费者问题, 读者写者问题. 但没有亲手写一写.该打
• 物理: 安装与部署

微信红包?!

一个奇怪的产品, 因为一个红包都没抢, 所以没有切身感受. 单看数据我觉得是个挺难设计的系统. 他们因为预估失准, 导致最后”上线千台服务器”(?). 流出的一些文档大概有这些信息:

• 拆分项目, 嘛, 有些年头的代码都有这样的要求..
• 可扩展.. 没有更多有意义的做法值得参考
• 基础组件, 嘛, 有些年头的代码都会有基础组件
• 轻松上线,… 这个..也能单列出来么- - 应该是必需品吧…

最在意的细节是

• 海量请求的处理
• 并发进程竞争共享资源

没有更多有效信息啦.. 期待有新的介绍.

另外, 觉得微信单独设计协议很值得敬佩. 工作量大, 脏活累活多, 容易出bug, 也没有社区保障, 但是高度定制为用户体验的提升帮助很大.

看书?!

春节期间果然没法看书. 本月糟透了.