全栈

本文主要是看过极客时间“左耳朵耗子”《左耳听风》课程的一篇总结，由于这个课程涵盖的知识面积非常广，所以没有像原课程名字那样富有诗意，姑且这篇总结就叫做全栈开发吧。我这里会将原文内容提炼，有些精华领悟了就没有在这里码字，喜欢的话大家可以去购买课程。

管理

技术领导力

具有技术领导力的工程师所具有的特质：能够发现并简单优雅地解决问题，了解不同方案的优缺点，代码高性能、可复用、可扩展、易维护，能够用正确方式管理团队，发挥每个人潜力以及提高团队效能，并具有创新能力。

为了具备以上特质需要有扎实的基础技术，非同一般的学习能力，坚持做正确的事，不断提高对自己的要求标准。以上几点中，要做到做正确的事可以包括：提高效率，自动化，掌握前沿技术，知识密集型，技术驱动。同时，我认为坚持做正确的事也是最难的，它受到太多外在因素的影响。

对于一个普通的开发人员来说，写代码的过程中，你明明发现有个地方需要重构优化，但是你做了得不到任何利益，不做的话也没有人说你，你愿意花自己的时间加班做这个工作么，我想几十个人里才能挑出一个人愿意这样做的，受益的看起来是公司，其实是你自己。

对于一个管理者，谁都知道代码审核作用很大，但是有几个公司能做到真正的代码审核，不忙的时候什么都可以做，只要一忙起来神马都是浮云，然后进入恶性循环。

领导

让大家追随 Leader 的素质包括：赢得他人的信任，开放的心态，以身示范，保持热情和冲动，抓住事物本质，描绘令人向往的方向，为他人创造机会。

分布式技术

高性能：缓存、负载均衡、异步调用（消息队列）、数据镜像（读写分离）、数据分区

高可用：拆分、冗余、限流降级、多活、监控及 DevOps

高可用

可用性 = 平均故障前时间/（平均故障前时间 + 平均修复时间）

今年看过的工作类图书

过去的一年工作重心不再偏向 iOS，所以也没有看任何跟 iOS 相关的书籍，走过程序员退休的年龄，之后会考虑向大前端（iOS & Android & Web）方向发展，同时兼顾 Java 后台路线，接受新的技术挑战。

《从零开始学架构》

介绍 Java 后台架构的一本书籍，真的能做到零基础也能对后台架构有一个较全面的认识。

前段时间做 Android 的朋友年底工作述职，被其他部门老大问到对后台技术高并发如何处理，我相信看过这本书的话，他也就不会抱怨为什么问移动客户端工程师后台的技术问题了，机会总是给有准备的人，你总是对现状不满，不知道如何努力就不努力，状态停滞不前又能怪谁没给你机会呢？看看不相关的技术也许对眼前的工作没有什么帮助，但是它能开阔视野和思路，今后工作中跟其他人沟通也不至于鸡同鸭讲。

《区块链——通往资产数字化之路》

这本书英文名字 Master Bitcoin 缩写 MB，MB 对于很多了解区块链的人来说不会陌生，豆瓣评分 9.0 。不管是从技术角度的剖析还是应用角度的讲解都非常全面到位，相对于《区块链革命》这本讲区块链会给人们生活带来什么改变的介绍书籍，通过 MB 你能够对区块链有一个比较具象的认识，而且书中介绍了加密算法、椭圆曲线加密算法、默克尔树等等对密码学的介绍也相当有趣。

《智能时代》

最近在看后台相关的技术书籍，总结一下架构相关的知识。

复杂度

软件架构：一些列相关的抽象模式，用于指导大型软件系统各个方面的设计。

架构设计的目的：解决软件系统复杂度带来的问题

高性能

高性能带来的复杂度主要体现在：单机计算机内内部为了高性能带来的复杂度；多台计算机集群为了高性能带来的复杂度

单机复杂度

最关键的地方就是操作系统，操作系统和性能相关的就是进程和线程。

要考虑高性能的软件系统，需要考虑如多进程、多线程、进程间通信、多线程并发等技术点

扫盲一下几种常见的服务器

Apache
Apache HTTP Server（简称 Apache）是 Apache 软件基金会的一款开放源码的 WEB 服务器软件

优点：稳定、开源、跨平台，适合处理动态请求
缺点：不支持高并发

发展时期很长，它兴起的年代，互联网产业远远比不上现在。所以它被设计为一个重量级的。在 Apache 上运行数以万计的并发访问，会导致服务器消耗大量内存。操作系统对其进行进程或线程间的切换也消耗了大量的 CPU 资源，导致 HTTP 请求的平均响应速度降低。

Nginx
同 Apache 一样都是一种 WEB 服务器，是轻量级高并发 HTTP 服务器和反向代理服务器。
优点：轻量级、高并发、处理静态文件好消耗内存少，提供负载均衡
缺点：需要配合其他后端使用，没有 Apache 稳定

正向代理最大的特点是客户端非常明确要访问的服务器地址
反向代理，”它代理的是服务端，代服务端接收请求”，主要用于服务器集群分布式部署的情况下，反向代理隐藏了服务器的信息

常见的网站架构有：Nginx + php、Nginx + tomcat、Nginx + apache + php 等

以上 Redis 是单进程单线程的，但是它的效率不比单进程多线程的同样基于内存的 KV 数据库 Memchache 差，官方提供的数据是可以达到 10万+ 的 QPS（每秒查询次数）。原因是它是基于内存存储，数据查找类似于 HashMap 时间复杂度是 O(1)；数据结构简单；单线程模式不用上下文切换和竞争条件；使用多路 I/O 复用模型，非阻塞 IO。“多路”指多个网络连接，“复用”指复用同一个线程。多路 I/O 复用技术可以让单个线程高效的处理多个连接请求。

集群的复杂度

• 任务分配：每台机器都可以处理完整的业务任务

过去的一年急于知识的输入却忽略了输出，导致很多东西看过就忘了或者没有深刻理解。最近看书的时候总把书中的标题看作问题，然后自己思考再将自己的想法和书中观点进行对比加深理解，所以用这个方式对技术管理类问题做个整理。

《跃迁 从技术到管理的硅谷路径》
这里列出的书名，是指从本书中找到的问题，下面的详情结合了作者观点，并加入了一些自己的见解和补充。

• 如何帮助团队成员成长

不要陷入静态思维。
不要用固定的眼光看待下属，不要因为下属曾经的能力在某一个级别上，就在很长时间内都觉得他没有成长；不要关注下属的错误，而是主动帮助他从错误中成长；不要为了团队目标而忽略下属的个人目标；给下属的反馈或者评价应该是帮助他提升的，而不是模棱两可的说你不够努力，你没有进步；要给下属分配稍有挑战性的任务，而不是为了保证项目进度将任务一直分配给你觉得值得信任的人。

让组员经常做一些总结，研究原理或者深入一些的知识；推荐图书让大家阅读；并进行知识分享；同时鼓励组员对工具类代码进行开源。

• 项目延期了怎么办

今年看过的工作类图书

记得去年在博客里写过要今年要多看些技术书籍，结果好像技术类书籍阅读的数量并没有增多，主要是目标转变导致的吧，所以不打算给明年下明确的读书目标，能阅读引发思考的书籍就好。

《深入理解计算机系统》

看完 CSAPP 这本书突然觉得大学学过的什么《操作系统》那本书简直烂得不行了，大学的时候完全不知道学的这些玩意儿对实际应用有什么指导。只恨自己上学不努力，不说当时能不能学会这些深奥的东西，眼界至少都被局限了。看这书的时候查了下卡内基梅隆大学，这个学校据说什么专业的人都会编程，如果每天不学习到凌晨三四点都无法跟上节奏。哎…

《程序员的自我修养 —— 链接、加载和库》

主标题应该是出版社起的吧，真的不是很喜欢这种俗气的名字。这本书在七八年前大致翻阅过，对它基本上没有什么印象，当时对知识的积累不够，看不太下去。这次看就觉得轻松了很多。书这种东西就是这样，你想要通过看一本经典的了解所有知识，但是看完经典的书又觉得没看一样，因为好些内容无法理解，所以不要奢求看了一本书就什么都学会。

《Thinking in UML - 大象》

UML 从没有好好学过，看了两篇帖子就以为自己会用了，殊不知比细节的话简直弱爆了，所以特意买了书了解一些细节，例如组合和聚合的差异等。

《TCP/IP 详情 卷一》

这本书也是八年前就买的，当时是准备面试同事推荐看的书，也是曾经不知所云，现在基本上能看进去，但是也不完全都能理解。能看得进去，是因为工作中遇到一些弱网优化等问题引发，还有在看这本书之前看了下面这本《图解 TCP/IP》。

《图解 TCP/IP》

这本书算是比较浅出，如果看上面那本书觉得有些吃力，建议先看看这本。如果觉得做 iOS 对理解网络的知识没有什么意义，建议去找找移动端网络优化相关的文章看看。

《*OS Interals: Volume one》

BeeHive 是一款阿里开源的解耦框架，通过模块和服务（Service）的方式实现组件化。

Module 和 Service 的调用方式

Annotation（标注）方式

Service 与 Module 的调用方式类似，只是 Service 有两个参数 ServiceName (以 Protocol 方式表示)以及实现的 IMP，以模块的调用方式为例

@BeeHiveMod(ShopModule)

该宏的定义为

#define BeeHiveMod(name) \
class BeeHive; char * k##name##_mod BeeHiveDATA(BeehiveMods) = ""#name”";

#define BeeHiveDATA(sectname) __attribute((used, section("__DATA,"#sectname" ")))

将宏展开

class BeeHive;
char *kShopModule_mod __attribute(used, section("__DATA_,"BeehiveMods" ")) = “ShopModule"

宏 ## 和 # 的使用方式

‘#’ 参数字符串化

#define SINGLE_SHARP(x) #x
SINGLE_SHARP(hello)
// "hello"

‘## 连两个字符串

#define DOUBLE_SHARP(x, y) x##y
DOUBLE_SHARP("hello", "world");
// hello word

《人月神话》是七八年前就被推荐要看的书，但是那个时候对这种月亮啊、神话、科幻类的书籍不是很感兴趣，所以一直没有翻阅（好吧，我只能说这本书的书名太容易误导人了）。很惋惜初做管理时就应该读的书，现在才拜读第一遍，读后意犹未尽，所以又看了《人件》，这篇文章对书的内容和自己的理解做个总结。

人月神话

焦油坑

编程就像是一个许多大型系统和开发人员在其中痛苦挣扎的焦油坑。

但无数人进入这个行业也是因为它还存在着乐趣，这些乐趣包括：创造新事物、创造对他人有用的东西、持续学习、将想象创造为现实，作为领导者可以根据员工的乐趣偏好进行激励。

人月神话

项目滞后的主要原因：

• 乐观主义。估算出的时间多为假设一切运作良好的情况下的完成时间，但是总有一些意外或者没有想到的事情会发生。
• 人月。误认为估算的人和月可以互换，将进度与工作量相互混淆。在任务不可分解的情况下，以及需要沟通才能完成的任务中，时间不会随着人员的增多而减少。
• 软件经理通常不会有耐心持续的估算这项工作。
• 对进度缺少跟踪和监督。
• 当意识到进度有偏差时，错误的认为增加人力就能解决问题。

软件进度安排的经验法则：

• 1/3 计划
• 1/6 编码
• 1/4 构件测试和早期系统测试
• 1/4 系统测试，所有的构件已完成

之前也做过编码两倍的时间来做计划的项目，基本上在计划的时候要做的事情非常细，包括框架的设计、类之间的关系、函数名，甚至连函数的参数和参数名称都定义好。对设计进行评审后才开始变吗，写代码时基本不需要思考，除非出现一些意外设计时没有考虑完全的情况。但是这种开发模式是之前使用 C 语言编程的时候了，后来进入移动时代再没有可能这样开发。

最后，任务不应该由顾客对完成时间紧迫程度来决定，为了在顾客要求的紧迫时间内完成任务，必定会影响质量。开发并推行生产率图表、缺陷率图表、估算规则可以有助于项目经理根据可靠数据来说明强行上线可能带来的风险。

Brooks 法则：向进度落后的项目中增加人手，只会使进度更加落后

这是一本书的名字，书还没有时间看，借鉴下看过源码的那些轮子是如何写测试代码的

单元测试

AFNetworking

AFN 的单元测试分为 UIKit 测试（包含有 UIKit 调用的测试，如 UIImage/UIImageView/UIButton 等），还有接口测试。基本上每一个类对应一个测试类，每个类都保证创建后能返回非空，或者预期的值，具体代码省略。

CocoaLumberjack

使用了第三方库 expecta 使代码更易读。测试点类似 AFNetworking，具体代码省略。

Masonry

使用了 expecta，创建约束后，经过一些设置后，确认是否能获得预期的值，具体代码省略。

NullSafe

[NSNull null] 的 stringValue/ bytes 方法应当返回 nil

XCTAssertNil(result);

[NSNull null] floatValue 方法是否返回 0.0

XCTAssertEqualWithAccuracy(result, 0.0f, 0.0f);

[NSNull null] intValue 方法是否返回 0

XCTAssertEqual(result, 0);

创建 [NSNull null] 的类，类名是否 NSNull

XCTAssertEqualObjects(result, @"NSNull");

[NSNull null] description 方法是否返回

XCTAssertEqualObjects(result, @"<null>");

[NSNull null] range 方法是否和 (0,0）范围一致

NSRange compare = NSMakeRange(0, 0);
XCTAssertTrue(NSEqualRanges(result, compare), @"Range test failed");

NSNull 的 Category 创建的方法 NullTestMethod 返回非0数字后是否依然能按照 0 处理

XCTAssertEqualWithAccuracy(result, 0.0, 0.0);

JLRoutes

设置 route，添加各种可能性的设置，测试是否能够正常处理，具体代码省略

UI 测试

主要是录制一些操作，然后进行校验，忽略轮子中的测试方式

IQKeyboardManager

主要是界面中操作过程中录制测试，具体代码省略

DZNEmptyDataSet

Pod 引入了 FaceBook 的第三方 FBSnapshotTestCase，这个库目前已经更新为 iOSSnapshotTestCase

截图测试

DetailViewController *vc = [[DetailViewController alloc] initWithApplication:app];
FBSnapshotVerifyViewWithOptions(vc.view, app.displayName, FBSnapshotTestCaseDefaultSuffixes(), 0);

使用方式：在 setUp 中首先设置 recordMode 为 YES，进入录制模式，执行测试的上述方法，会生成截图，忽略结果，这时只是截图操作，生成的图片文件在 getReferenceImageDirectoryWithDefault 中指定的位置，以此截图为参考图片。修改 recordMode 为 NO，然后再执行测试方法，就会用快照和之前存在指定位置的参考图片做对比，如果两个图片不匹配的话，测试就会失败

参考文章

iOS 单元测试和UI测试教程

总结下过去这段时间在重构过程中看过书中的知识点，以及一些经验教训。
PS: 本文没有写完，部分内容待完善，不定期更新

重构

重构的原因

最近负责的项目已经运行了六年，一套代码支持了几十个项目。时常出现一改动代码就引发新 Bug，功能或者项目之间很容易互相影响。这套结构混乱、耦合度高、复用性不强，逻辑混乱的代码给现今的工作带来种种不便。再加上缺乏需求和设计文档，新入职的员工来了半年也不能接手新业务。解决方案就是重构拆分，模块独立，降低系统耦合性。

重构和重写

大多数人都喜欢看自己写的代码，觉得别人的代码不容易理解，维护以前的代码浪费时间，所以一说到重构他们首先想到的是重写。不说重写会造成多少资源的浪费，但是我相信重写引入的 Bug 肯定会比合理重构造成的 Bug 只多不少。《Refactoring》书中给了我们很好的说明什么时候应该重写

现有代码根本不能正常运作。你可能只是试着做点测试，然后就发现代码中满是错误，根本无法稳定运作。

重构的目标

• 解耦，减少 Bug
• 组件化，将可以共用的部分抽离，避免重复代码散落多处维护困难
• 模块化，按照业务功能拆分，做到高内聚低耦合
• 逻辑结构要清晰。变量、方法放合适的地方
• 接口合理化，不好用的接口的表现是，调用者又写了一些逻辑去弥补接口应该完成的工作
• 梳理混乱的目录结构
• 使用 CocoaPods 发布，每个模块打包成单独的 Pod

另外，即使使用 MVC 结构，大家都清楚 C 层不应该放 V 和 M 层的逻辑，但是一些初级的开发人员很容易就会把 V 或者 M 层的逻辑写到 C 层。

如上图橙黄色层为业务模块，绿色为中间层，红色为第三方开源库和底层 API，绿色是对红色层的封装，橙黄色只能调用绿色层和底层，红色部分是不可以修改的部分。调用关系如白线所示，模块间不能通过硬编码互相调用，模块间的重复部分可以下沉到组件。

今年看过的工作类图书如下：

iOS 成长之路 2017 春 夏

《春》的内容少一些， 关于 HTTP 2.0 的介绍得很详细。《夏》在内容上就丰富多了，对不同层次的开发者应该都有一些吸引点。

Learning OpenCV 3

OpenCV 的手册书，学 OpenCV 必看

Mastering OpenCV with Practical Computer Vision Projects

介绍了 PC 和 iOS、Android 上使用 OpenCV 的实例。包括人脸识别、人物变动画效果、汽车牌照识别等等应用场景。

架构实战－软件架构设计的过程

这本书是7、8年前在亚麻买的，买后随便翻了下觉得写得不好就放下了，今年突然想起这本书，拿出来仔细阅读了下，真的是没冤枉它这些年被尘封，这次看完就扔了，都是概念、名词解释，没有什么实际指导意义。它应该比较适合完全没有接触过软件架构的人看。

管理类书籍包括：

格鲁夫给经理人的第一课

安迪格鲁夫是英特尔公司前 CEO，这本书凝聚了管理学的经典理论和方法，并且结合实际介绍了些方式方法。

德鲁克系列之 管理的实践

《管理的实践》《卓有成效的管理者》《管理：任务，责任，实践》这三套书是德鲁克书籍中的经典，非常详细的说明了德鲁克的管理理论。

给你一个团队，你能怎么管

书名一看就是国人写的书，估计是出版社特意要求的。相对于其它国人书籍的特点举实例、讲具体方法，这本书还是结合了一些理论和方法，值得思考和借鉴。

这一年读的很多管理类书籍感触很多，重要的它们改变了我看待事物的角度，但是还没有来得及整理成文字，接下来的一年会找个时间写一篇系统的总结。另外由于这一年要做代码重构的工作，重读了《重构》《Head First Desgin Patterns》《设计模式》以及《Effective Objective-C 2.0》，经典的书每次都能让你有不同的体会。很欣赏西方人总结的能力，自己在这方面十分欠缺，大部分时间都是在干活，却忽略了总结。

非工作类书籍的特殊推荐

艺术的故事 （贡布里希）

去年写读书总结的时候没有列任何一本非工作类书籍，这一次特意把它记录下来，是因为这本书解开了我对艺术的太多的疑问，它让我爱上了曾经看不懂的很多名画，让我对欧洲的旅行有了些许期待，更重要的是它帮我开拓了眼界，打开了格局，格局可以决定行动，行动可以决定未来。

另外还看了一些财会、战略类的书籍，好吧，今年看的书特别杂设计类书籍看的有点多了，技术类书籍明显有点少了，来年要多看一些技术类的书籍了。