Closed ShannonChenCHN closed 5 years ago
ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago 程序 = 算法 + 数据结构，我们所实现的功能和 UI 界面，本质上是对数据的展示和处理，在实现跟 UI 相关的功能时，要记得我们实际上是在跟数据打交道，这就是数据驱动思想。ShannonChenCHN
commented
6 years ago 关于性能优化，小陈提的问题是觉得性能有问题。
ShannonChenCHN
commented
6 years ago 达人猫项目
YHOUSE
ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago 注：02.13~02.22 期间过年休假
前两天在家里在学 HTTPS 时，发现这个过程并不好理解。所以我在想，对苹果来说，如果他要让普通开发者支持 HTTPS 的话，为了让大家方便，会出一些教程、文档、视频，教大家怎么去实现。这其中的资料有深有浅，对于一般的开发者来说，照着教程去做就能实现 HTTPS 了，不需要了解原理也可以，但是实际上他们不知道这背后发生了什么。然而对于专业的开发者来讲，就会去了解 HTTP 的传输过程，以及 HTTPS 相关的原理，显然他们对于自己所做的事情的理解的层次也更深，这样一来，有几点好处： 一是了解了基本的底层原理能让他们可以从容地面对相关问题。 二是知道了原理后，就可以在这个机制上实现一些自己的想法，也就是说玩得转。 三是这些底层原理、机制是不怎么经常变化的，不受平台、系统所限制，所以学会并深刻理解后，即便换另一个平台、系统、技术栈，也能照样玩得转，学会底层是一本万利的事情。 四是这些底层原理、算法是前人留下的精华，智慧的结晶，可以给我们带来很多启发。
要想避免平庸、有所突破，就需要克服畏难心理，走出舒适区。
ShannonChenCHN
commented
6 years ago ld: library not found for -lPods 这周读了下 jk_night 写的 YTKNetwkork 源码阅读文章，发现写的一般，仅仅是把代码流程走了一遍。相比之下，bang 和涂耀辉算是读的比较深入的了，为什么这么说呢？因为他们在读源码时，比较看重的是： - 刨根问底，读的时候在想 “为什么这么实现”，并且理解其背后的原理，读完后，会有一种“哦，原来是这样的啊~”的惊叹
做事情只会越做越熟练，越高明。比如说读源码，从 2 年多前读IQKeyboardManager，JSONModel，SDWebImage，MJRefresh，到去年读 SDWebImage，WebViewJavaScriptBridge，IGListKit，再到今年读 JLRoutes，AFNetworking，YTKNetwork。自己感觉明显是越来越熟练了，不再像原来只知道一样一板一眼地逐行往下读了，现在看来以前的读法太浅、太死板了。当然，目前仍然还有很多地方需要提高。
ShannonChenCHN
commented
6 years ago 前两天看到有人在掘金上分享了面试时如何回答性能优化的问题，读后有些启发：
做性能优化，觉不仅仅是在某些地方采用了某某手段、技巧优化了某些点，而是对整个程序的功能流程进行评估检测，找出性能瓶颈所在，然后再做针对性优化。之前看过美团分享的关于 h5 加载优化的文章，其实也是同样的路子。引申开来讲，解决问题时也是同样的套路。
前两天再读ibireme 的那篇 JSON 转 Model 的第三方库性能评测文章，文章中列出了对几个 JSON 转 Model 第三方库的评测结果数据以及分析，然后再在容错性、功能和侵入性三个方面做了对比，列出结论，最后还给出了几个 YYModel 性能优化的 Tip。
这又让我想起了在『得到』上听过的『六经注我读书法』，读书的境界分为 4 层：
显然 ibireme 的这种方法非常专业，可以说是达到了最高的那个层次。而我自己目前还是处于最低的“看山是山，看水是水”的层次，总是抱着敬畏的心态去学习。要想有所突破，首先要在知识的深度和广度上有所积累，因为“读”的还不够多；其次就是要积极思考，敢于质疑，多想想为什么这么做，是否可以换种方式做；最后，就是要实践，在实践中验证自己的想法。
昨天看了下GitHub 上每种语言活跃用户的活动情况https://mp.weixin.qq.com/s/80JBZV4f4ERZzMMuAfY7PA， 发现JS、Python 和 Java 真是叼，还有 C++，心想有机会把这几门语言都好好学一下。
后来想想，还是太浮躁，有点急于求成的心态了，今年主要目标还是把前端搞定吧。
从学习的驱动力来看，可以分为两种，一种是因为工作需要，比如小程序、React Native，另一种是自己想要去深入了解，比如 TCP/IP， Objective-C runtime 源码，编译和链接的原理。
上面两种学习方式可以简单概括为，面向应用学习和面向理论学习。其实这两种模式在 这篇文章 中也专门讨论了，文章将这两种学习方式成为自顶向下和自底向上。
湾区日报的维护者是这样评价的：
自顶向下：一上来就做酷炫的项目（网站、游戏），边做边学，容易有成就感，但基础不牢、多是胶水浆糊代码；自底向上：系统地学概念、做课后习题，耗时长、容易失去兴趣半途而废；混合型：做项目与系统学习不断交替。
大学里的教学多是自底向上式的，学概念、做题，学生往往几节课下来就对编程失去兴趣了；社会上的编程培训班多是自顶向上式的，复制粘贴代码做酷炫网站、app，学员出来后都有个漂亮的作品集，但实际工作下去相当不靠谱。
更好的方式是将两者结合起来，既能做出实实在在的东西来，同时知道背后的原理。以实践为基础，在做应用的过程中能将前人积累下来理论、原则和方法论应用到实践中去，用正确的方式做正确的事情才会事半功倍。另一方面，如果实战中遇到疑惑时，正是补充理论查漏补缺的时候。
不管是哪一种，最终要达到的目的是为了能够更好地解决实际问题。
ShannonChenCHN
commented
6 years ago intrinsicContentSize 方法中的数值发生变化时，需要调用 invalidateIntrinsicContentSize 方法进行更新看到 bs 在写读书笔记时，都会提出几个问题，所以即便他没有把一本书从头看到尾，但也能吸收的更多、消化的更好。
另外，在刘未鹏的《暗时间》一书中也看到他提出的一个观点，很有启发，“看书不在于记住了多少知识，更重要的是推理”。我对于他所说的推理的理解是，在读的过程中去思考、分析，而不是一味地吸收。
真正重要的不是知识量，而是对于基础知识的掌握程度和解决问题的能力。
学习其实没有必要、也不可能一步到位，一开始只要了解大方向，而不是深入到很细节的地方，知道整体框架就行，不需要抠细节。因为第一次不可能都能理解的很深，而且也没必要，这样很容易只见树木不见森林。学习关键的还是要有侧重点，比如说第一次接触 runtime ，那就是了解全貌，第二次学习可能是碰到了某个问题，那就要带着目标和问题去深入细节，慢慢地，接触多了，各个细节也就都完善了。
如果是自己实践的话，也是如此，先有大体框架，然后逐步完善。也就是所谓的“自顶向下”设计。
前段时间在知识星球上看到卓同学分享的《滴滴出行 iOS 客户端演进之路》，里面讲到了滴滴的 iOS 团队和 Android 团队在 socket 长链接库上都是公用的一套代码，在这条状态的评论中，@味精 也提到了他们 iOS 团队和 Android 团队在文字排版和动态界面布局引擎这块也是这样做的。从这些可以看出底层的“不变”，比如 C++，网络，操作系统，文本渲染、音视频等。再加上最近在看 runtime 源码，越发觉得学习 C++ 和基础知识的重要性了。
读源码最好要有目的和侧重点，也就说读的时候是要学习作者的思维方式，还是功能实现，还是架构，还是底层原理知识，还是开阔眼界、获得启发。如果没有侧重点，要么走马观花，要么弄的精疲力尽。
发现大左在读代码时的一个特点就是能抓重点和主线，懂得剔除一些细枝末节。
除了深度上的发展，还要在广度上适当（粗粒度）了解一些解决方案，实现思路，技术点。
生命的活力在于发展，我们更应该关注的是如何发挥自己的长处，而不是一味地去盲目补短。
ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago 最近一直在犹豫，因为没想好接下来要学什么、做什么，其实这些方向取决于接下来 1 个月、半年、1 年、甚至 3 年的目标。
记得刘未鹏在《暗时间》中说过犹豫会导致踟蹰不前，而先暂时选择一个马上去做比什么都不做更好。
接下来几天有一个注重算法的电面，所以这几天要多看下算法； 下个月要去新公司了，目标 A 是个大厂，注重APM、性能优化、效率等方面，这需要一定的深度，也正是我喜欢去做的，所以接下来几个月可以多研究下业界各个大厂和大牛们都是怎么做的，加强这方面的深度；目标 B 是个技术氛围比较浓的创业公司（C 轮），项目中有用到 Swift、React Native（这个A厂也有用到）、函数响应式编程这些相对比较“时髦”的技术。综合来看，前端和 JavaScript 是一定要去进一步深入学习的，在 APM 和性能优化方面。
做了将近 3 年的 iOS 开发，对于前端和后端我一直充满好奇心，但是为了能在 iOS 上稳扎稳打，所以一直忍住没去玩玩了。长远来看，要想在技术领域站稳脚跟，决不能仅限于 iOS 一端，所以后面的大目标还是精通 iOS，熟练掌握前端，了解（会写）后端，先有深度后有广度，一定要有自己擅长的领域。
除了技术之外，管理、带团队、产品都要去了解，每个阶段都有不同的目标，当做了 5 年以上的开发后，很多人都会遇到技术瓶颈，感到迷茫，这个时候，扩大边界就可以给我们的工作带来更多的活力和动力。
诚然，对于大多数人来说，工作就是饭碗，所以把工作做好是第一位的。但是，如果只有工作，很容易会让人感到焦虑和乏味，因此，培养一些第二技能很有必要，比如写作、英语等等。
ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago 来携程工作一周的几点感受：
对自己的一些告诫：
刚来到新团队，发现项目并不像想象中的那么规范，甚至可以说是没有规范。我认为在团队合作的过程中，规范是必需的，有了规范，大家就会在工作中很容易知道自己应该做什么、互相之间怎么“沟通”。简单来说，规范的意义就在于降低沟通成本和维护成本。
规范包括：
问题确实是解决了，但是其中暴露的问题是：因为差不多有两年时间没有在团队开发中使用 Git 了，很多操作都比较生疏了，另一方面，对于 git 的使用还是不够熟练，对 git 的原理的了解不够深入。
大多数的软件工程师都会有这样一个困扰：我天天写业务代码，怎么提高自己的能力？
养成一个好习惯很难，丢掉一个好习惯确认容易。因为人总是容易懈怠的，那么如何保持专注、养成好习惯呢？光靠“内力”还是不够的，有时候还是需要借助“外力”，比如环境带来的影响（队友、leader），每天看看耗子叔的专栏，多读书，看看自己跟大神之间差距有多大，让自己受点刺激。
对于技能的学习，如果平时不经常用，很难达到熟练甚至深入的程度。所以，对于技能不需要盲目追求广度，而对于基础知识的学习却需要不断积累和巩固。
ShannonChenCHN
commented
6 years ago 暂时木有
周三调了一整天的 UI，效率不是很高，想想效率低的原因在于： • 客观原因是，对代码还不熟悉，原来的代码逻辑本身也存在问题，写的不好 • 自己早上起得太早，下午又没睡觉，导致精神状态不太好 • 分析问题不够细致，思路也不够清晰，下次最好是一边想，一边记下来，然后再去调
天天写业务代码，是避免不了的，而且本身也是必须要的，所以我们与其想办法逃避，还不如想办法提高效率解决痛点。
怎样才能把时间用在刀刃上： • 想办法提高效率 • 从公司项目中吸收营养 • 学习新技能（最好是能实战中学习） • 夯实基础 • 既有输入也有输出 • 多做些比自己当前水平稍微难一点的事情
如果不知道做什么，可以在每天的实践中，给自己提一些问题，先不要急于寻求答案，而是记录下来，最后再看哪些问题是自己感兴趣的、而且比较有深度，然后再去深入了解。
ShannonChenCHN
commented
6 years ago 暂时木有
不要谈大求全，一周完成一个小目标；一年下来也就能实现一个大目标了。
做事情、学习的时候，最重要的是能够找到最重要的点，这个其实也可以借用 “二八法则” 来理解，真正重要的往往是那 20% 的工作，所以要把精力用在刀刃上。比如，要弄明白一个知识点，不要太追求笔记、代码样式，而是要通过实践把原理弄明白。
首先，要肯定的是，如果跟实践相关的，比如说要解决一些问题痛点、实现一些目标，这是首先要去学习的。 但是，学习的本身应该不是功利性的，为什么呢？一是，学习的乐趣；二是，开阔视野，获取灵感。
ShannonChenCHN
commented
6 years ago 成熟的定义是什么？
积极面对困境、逆境、让自己感到不舒服的东西，比如跟自己不喜欢的人打交道，敢于踏出舒适区。
周四上午读了 Mr.peak 的文章，发现原来 facebook 的工程文化非常大胆、鼓励创新，所以我想我自己是不是太保守了，其实还是要多尝试、敢尝试，只有在做一些超出自己舒适区之外的事情，才会有更大的进步。
周四下午跟 WD 简单讨论了一下 JBox 和 JSPatch 的实现，感悟倒不是在具体的技术细节上，而在其他地方：
写代码的过程其实是搬砖，真正重要的是思考，体现思考的是算法。这个算法其实是指广义上的算法，指的是一种解决思路。所以，我想，要看一个人有没有在思考，让把自己的想法和思路写出来就知道几斤几两 了。
任何一个项目都要经历下面这个过程： 想法->做出来，看起来很丑、很简陋，但是有用->完善->完善->牛逼
周六看完『我不是药神』之后，发现自己讲不出心中的感受。后来看了别人的几篇影评，才意识到，自己缺乏的是吸收、学习、内化的过程。比如如何用一个合适的词去表达自己的感受，这是需要学习和练习的。 另外，一个常见的问题就是聊天时没东西可说、写作时可写，那十有八九是因为缺乏输入（阅读、体验），缺乏思考，缺乏表达技巧。
为什么？跟人聊天能不能聊起来，就看有木有共同话题，写作也是看能不能引起读者共鸣。
怎么解？多体验、多尝试、多感受、多看看别人怎么聊怎么写的、多练习，比如炒股、狼人杀、旅行、多了解不同的技术。
另外一个问题就是，发现自己最近这半年很少精读了，真正高效的学习需要精读和泛读相结合。
ShannonChenCHN
commented
6 years ago 无。。。。。
这周在发布新版本前两天，因为流程上的一些问题，UI 设计师和 Android 团队小伙伴出现了一点小摩擦，我虽是旁观者，但也是小组成员之一，当时在争论时也被牵涉到了其中，事后有些感受：
详见 笔记。
周三早上坐电梯时，电梯门关上了后，因为外面又有人按了按钮想等下一班电梯，结果电梯门又开了。
我一看电梯门开了，就知道肯定是外面有人按了按钮。因为我自己在三年前就犯过这样的错误，所以，我印象深刻。
人的经验来自于两方面，一是自己踩过坑，二是看别人踩过坑。
ShannonChenCHN
commented
6 years ago 无。。。。。
ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago intrinsicContentSize 和 systemLayoutSizeFittingSize: 方法，以及 view 布局生命周期ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago Object.assign()国庆假期的主要收获，就是『速读』和『理财』，以及算法的复杂度分析。
ShannonChenCHN
commented
6 years ago focus() 方法后，自动选中了输入框中的所有文字，后来通过查看 TextInput 源码实现，搜了一下 focus 相关的属性，原来因为设置了 React Native 中 TextInput 组件的 selectTextOnFocus 属性为 true 导致的alignSelf 属性值为 flex-start 来实现ShannonChenCHN
commented
6 years ago 【工作】
【知识点、问题】
【阅读】
【算法】
ShannonChenCHN
commented
6 years ago ShannonChenCHN
commented
6 years ago 【工作】
【知识点、问题】
【阅读】
【算法】
本周大事件
ShannonChenCHN
commented
6 years ago 【工作】
【知识点、问题】
【阅读】
【算法】
其他
ShannonChenCHN
commented
6 years ago 【工作】
【知识点、问题、思考】
【阅读】
【算法】
ShannonChenCHN
commented
6 years ago 简单概括一下，这一周主要是在改一些 bug，以及阅读 CS:APP 这本书，周五参加了公司举办的技术峰会。
进一步明确了自己下一步要努力提升的两个方向：计算机基础知识（原理层）和大前端技术栈（应用层）。
周六晚上看了 stormzhang 的直播，第一次知道了 A8 这个概念，更感叹他的执行力和独立思考的能力，能够在短短几年内从一个普通的一线安卓程序员，成长为一个准 A8 的管理层。对于 20 多岁的年轻人来说，社会跟校园完全不同，要想快速成长，提升认知是最重要的事情，没有之一。
另外，在读过《20岁，光阴不再来》之外，我也越发意识到 20 岁的时光是多么宝贵，佛性地“走一步，看一步”其实是在拖延时间。
ShannonChenCHN
commented
5 years ago 这一周主要是为新版本发布做准备，改一些 bug，所以时间上相对还算充裕，大部分时间都在读 CS:APP 这本书，学习了机器层面的汇编代码。
上周公司基础架构部门的领导表示我们后面将全面转向 RN，机票部门已经基本完成了转型工作，希望我们其他各业务部门不要掉队。去年，一个在大众点评做 PM 的朋友跟我透露，他们那边技术团队前端团队是主体，原生开发只占了一小部分。其实，近一两年时间里，许多大厂的团队都在将原生和 JS 技术栈相融合，比如美团的 Picasso，之前也听百度的一个开发者说他们团队也造了一个类似 RN 的轮子。
昨天看到一个蚂蚁金服的前端工程师在他的文章中提到，他们团队目前希望能够储备一些有过原生和 RN 开发经验的复合型人才。
另外，最近两年，在各大公司内部以及行业内，iOS/Android 开发已经不再是“焦点”，前端和后端可以玩的比原生开发要多得多。而且在很多公司，前端开发团队发展的比原生团队更有活力更有创造力，比如饿了么、百度的 FE。
从这些外部动向可以看到，目前大前端是大趋势。
从技术本身来看，JavaScript 前端技术开发效率高，轮子多，如果基础设施搭建好了，不知道比原生开发高到哪里去了（大多数业务场景下）。
比如下面这个例子，分别用 Objective-C 和 JavaScript 实现同一个样式的富文本：“这是一段文字这是加粗部分”。
iOS
NSString *str_1 = @"这是一段文字";
NSString *str_2 = @"这是加粗部分";
NSString *str = [NSString stringWithFormat:@"%@%@", str_1, str_2];
NSMutableAttributedString *attStr = [[NSMutableAttributedString alloc] initWithString:str];
[attStr setAttributes:@{NSFontAttributeName : [UIFont systemFontOfSize:15]}
range:NSMakeRange(0, str_1.length)];
[attStr setAttributes:@{NSFontAttributeName : [UIFont boldSystemFontOfSize:15]}
range:NSMakeRange(str_1.length - 1, str_2.length)];
UILabel *label = [[UILabel alloc] init];
label.attributedText = attStr;
[self addSubview:label]
// 设置 label 的 origin
// 计算 label 的文字尺寸（使用autolayout 或者 手动计算）
// ...
React Native：
render() {
return (
<View>
<Text style={{ fontSize: 15 }}>
这是一段文字
<Text style={{ fontWeight: bold }}>这里是加粗部分<Text>
<Text>
</View>
);
}
从 Web 技术的发展历史和整个互联网技术体系来看，iOS 开发只是很小很小的一个领域，要想在这个行业走的更远（技术领域），应用层的技术可以多接触，不要把鸡蛋放在一个篮子里，底层基础技术、半衰期长的技术值得长期投资，比如计算机组成原理、操作系统、浏览器原理、数据结构和算法、计算机网络等。
最后，借金旭亮老师的一句话总结一下，“有了扎实的基础知识后，你真正需要深入学习的只有“N+1”和“N-1”层”。
图片来源：https://www.zhihu.com/lives/837669764146003968
ShannonChenCHN
commented
5 years ago git pull --rebase 时出现冲突，接着又折腾了好久才提交成功，目前看来，问题原因是 rebase 时出现了 conflict，所以暂时的解决方案是每次要提交时，先 stash，再 pull，最后再 stash pop + commit + push这个星期主要是做新需求，中途又被借调到了另一个部门，可能许多人觉得这不太好，不想走出舒适区，但是其实我看到的是潜在的机会，逃避现实不如拥抱变化。
总体来讲，这一周的阅读效率不太高，CS:APP 进度慢，而且也没有看其他的书。
原来的计划是每天上班做完需求后就读 CS:APP，先不去管其他的技术了，但是实际上，一方面这样的学习效率并不高，另一方面，CS:APP 这样的书是更偏向于底层的、理论层面的书，跟平时的应用开发关系不大，所以很难能马上起到化学反应，而我又没有去研究“N - 1”层的知识，这样就好像两头都没顾上。
所以，后面打算上班时的自由时间把精力放到 “N-1” 上了，CS:APP 主要是下班后的晚上和周末来学习、消化了。
周末上了瑜伽课，第一次体验瑜伽，仿佛打开新世界。
为什么 C 语言中有 a++，a--，a+=b 这种运算符？
从 CS:APP 上的介绍可以看出，因为最开始汇编里面有，所以 C 里面也有对应的一套，像 goto 语句也是一样起源于汇编。
Swift 里面直接移除了 ++ 和 -- 这两种运算符的特性，Swift 之父 Chris Lattner 还专门写了一篇文章解释了为什么移除了这两种运算符——Remove the ++ and -- operators，其中讲到的一大弊端就是增加了语法层面的复杂度，很容易让使用者感到困惑，比如 a++ 和 ++a。
另外，跟一朋友聊起这件事时，听说王垠也吐槽过这一点。
实际上，a++ 这类运算符并不会带来什么效率，因为在编译层转成的代码和 a = a + 1 效果是一样的。
我做了一个试验，使用 gcc 分别编译了下面两段代码，最后得到的汇编代码确实是做了优化，删掉了不必要的变量和步骤：
x++;
long q = ++x;
return q;最后转成了 leaq 2(%rdi), %rax。
long t = x++;
long q = ++t;
return t;最后转成了 leaq 1(%rdi), %rax，x++ 执行后但是没用到 x，所以直接就忽略了。
讲到这，突然想起了 3 年前刚入行时，坐我旁边的哥们跟我讲，
int a = b + c;
int d = a * x;
比 int d = (b + c) * x; 这种写法多了一行代码，更耗性能，我当时并不认同他，但也不知道底层到底发生了什么。
如果你学过编译和汇编相关的知识就知道，一般情况下编译器时会帮你优化的，另外这点效率跟代码可读性和可调试性比起来根本算不了什么。
最近不时听到外面 cai yuan 的消息，就连安卓大神何俊林都被裁了，最后斗鱼给的赔偿是 N+1，而且绩效还给了 C，并不像网上谣传的 N+5 这么夸张。市场和商业就是这么残酷，一点人情都不给，我在 2017 年初在创业公司时也差点遭遇这种窘境，当时就嗅到了“死亡”的气息，不过还好那时经济还不像现在这么不景气。
今天早上还看到有消息说，根据前程无忧上爬到的数据，发现招聘广告数从年初的 285 万到 9 月份的 83 万，受到冲击的不仅是互联网行业，而是多个行业。首当其冲的是零售行业和餐饮行业；其次就是互联网 IT 行业，小公司倒闭、中公司裁员、大公司缩招；然后就是金融地产，很多地方现在房子都卖不出去，开发商推出了各种促销政策。
何俊林就他被裁这件事分享了一下自己的遭遇经过和感受、感悟，其中的内容很有价值，但是可惜被删了，不过文章最后的几点总结有人截图保存了下来（感谢何俊林和南峰子），这几句用“宝贵的鲜血”换来的老人言值得我们好好冷静思考一下，眼光还是要看的长远一点才行，不光要做好自己，还要看清大形势大趋势。
前两天在一个技术交流群里，跟 bs 聊天，他也感叹道，当你很难从业务代码中抽身出来的时候，那也就谈不上抽时间和精力研究技术提升自己了，毕竟一个人的时间和精力是有限的。
最理想的状态是，业务上给需求量是合理的，既可以在实践使用新学的技术，又可以从业务开发中发现自己的不足，接触到新的东西，更重要的一点是如果有足够的时间能够认真做一个完整的需求，比赶时间赶出一个毛坯收获要大得多。然后在需求之外，可以花时间是查漏补缺，新学一些知识（不一定是新知识），做优化。
但是如果达不到理想状态能怎么办呢？
周二听了一场腾讯理财专家的讲座，我是个理财小白，就记住了“控风险，眼光看长远，坚持做定投”这一点建议。 上周报名了公司同时组织的瑜伽课，周六第一次上瑜伽课，感觉还蛮不错的，年轻时走出舒适区，多接触有助于成长的新事物，对于以后的人生大有裨益。
很多人以为打工的回报就是拿工资、期权和镀金，其实还有一点许多人没注意到的就是大公司的资源，如果你在大公司工作，人脉和社团、可以接触不同部门、领域，这些都是附加福利。
这是 stormzhang 在朋友圈里分享的一些建议，本来是不打算公开的，不过 stormzhang 后来已经在他的公众号公开了，所以也就不算是“泄密”啦
ShannonChenCHN
commented
5 years ago 这个星期主要是在做 HT 聊天页的需求，很久没有完完全全新写一个页面了。
我相信很多技术人都会遇到这类问题：
为什么忙东忙西，最后却感觉又累又没有什么收获？
天天写业务代码怎么成长？
为什么总是感到学习焦虑？
我最近开始意识到了这些问题的严重性了，自己仔细思考分析了一下，导致这些问题的根源是什么——没有抓住重点，不够专注。
所以，我针对这类问题做了调整：
这周做了一个新需求，大概内容是做一个聊天”气泡“效果，结果因为设计师给的图片有问题，折腾了近 2 个小时，最后因为比较晚了就放弃了，然而，第二天一早过来只花了 10 分钟就搞定了。
所以呢，遇到难搞的问题，不要死磕。
参考耗子叔在他专栏上分享的“一二三原则”，我们在遇到一个问题时，先话几分钟自己尝试用不同的方式解决，如果不行，再求助 google，如果 google 还不能解决，就请教身边的同事，如果你身边的同事还不能解决的话，就要求助内部或者外部的高手了。
总之，原则就是依次尝试不同层次的解决途径，知道解决问题，但是要有个期限，期限的长短视问题难度和时间紧迫而定，一般是 30 min 到 2 h，最多不能超过 1 天，否则就要及时上报领导。
另外，很多时候有些问题一下子解决不了，放一放，过一会儿或者过几天，就能解决了（读书也是同理）。
另外，在《代码大全》这本书中，也提到了类似的建议：坚持有时候未必是好事，过于坚持就是固执，坚持最好有个期限，和电脑斗气是不明智的。
周四在写代码时，突然意识到自己写这些业务代码有什么意思呢？另外一个问题是我怎么才能让别人知道我做的好还是一般呢？包括公司同事，圈内人士，以及未来的面试官。
关键在于自己在这个过程中是怎么思考和做事的，你的闪光点在于什么地方，这些往往能够决定自己的成长速度。如果你总是仅仅满足于完成任务，那就是在浪费生命。那么闪光点怎么来呢？一般来自于我们解决问题的方式，三个方向，一个是代码质量，另一个是性能，最后一个是效率。这三个方向是基于我们踩过的坑，实践经验，看过的开源代码，读过的书（比如设计模式、架构、代码大全），对开发语言和平台框架原理和底层原理的了解。
所以，做完需求后，最好有一些对应的复盘总结，看看自己有没有思考，有没有成长。
所以，最近在做的这个聊天需求，就有以下几个问题：
最后说一句废话，光写业务代码是没什么技术含量的，是不能带来成长的。（好像 sunny 之前就说过这句话）
ShannonChenCHN
commented
5 years ago 这个星期的主要工作是在接聊天 SDK。
这次接基础框架部门的 IM SDK，一没文档，二没 demo，三没有统一的中心库，整个接入过程就像便秘，摸着石头总算是基本完成了。
作为基础框架，是提供给公司内部各个产品用的，这就像做开源项目和卖产品一样，要充分考虑广大用户的感受。作为大公司内部的基础框架，更要好好做了，这是一本万利的事情，做好了能够降低不少沟通成本和开发成本。
麻烦、人力不够都不是借口，写个文档和 demo 应该花不了多长时间的，把最基础的功能描述出来， 2 人天的资源应该是足够了。
学习理论之后，直接按照书上一板一眼去做，不敢轻举妄动，那就是读死书，被书束缚住了。比较好的方法是读完书后（不一定要把整本书看完），先放手去做，不要纠结，但是一开始步子不要迈的太大，在不断尝试和“玩”、失败的过程中不断反思，改进。
这跟学开车的过程是一样的。学习的最终目的是实践，所以不妨在“玩”中学。
另外，书上的内容不一定完全对或者完全适合我们，通过实践磨合找到适合自己的方式。
人的生活是多维度的，相应地，学习也可以是多维度的。
这一点跟先精后广不冲突，因为不同的领域需要的深度要求不同，大多数领域都符合“二八法则”，只需要学会 20%，就能够带来 80% 的回报。而在我们最需要的、最重要的和最感兴趣的领域，就需要多花些精力不断深入了。
而且，在其他领域的学习，还能带来一些启发。
在广度上，我们可以拓展哪些领域呢？
这个礼拜，公司要进行年终考核了，又到了要写年终总结的时候了。
可以说每年这个时候都是大家都觉得头疼的时候，我写年终总结的方法是——平时记录+套模板。
也就是说平时养成每周、每月写总结的习惯，写写自己这段时间做了什么、学了什么、有什么进步、有哪些亮点、有哪些做的不好的地方。
年终总结就是把这些周报、月报串联汇总起来。
这次做 IM 模块的一个感受就是，知道当前最重要的是什么，解决问题才是关键。
一开始，还想着能不能好好打磨每个细节，写出高质量高性能的代码，后来发现时间根本不够，这跟当初在创业公司的情况很相似，所以这个时候最重要的事情是按时把需求搞定啊（如果延期那问题就大了），什么刨根问底、高质量、高性能，做到 50%、20% 就可以了（这些可以放到其他时间再做），这个时候甚至可以放下面子直接复制别人的代码。
第一步要感性，不要想太多，先去做再说，第二步要理性，做完第一步后再复盘一下，适当调整或者果断 give up。
ShannonChenCHN
commented
5 years ago 这个星期的主要工作是在忙改 HT 的 bug，和主板 APP 的 RN 需求，另外抽时间读了一点 RN 的源码。
告别 2018 ，明年见！
关于
子曰：一日三省吾身。
这个 issue 用来记录每周的工作和思考，包括做了什么、遇到了什么问题、如何解决的、做了什么优化、有什么思考和进步。
另外，左耳朵耗子也提出了 ARTS 的建议——每周至少做到一次下面几点：
目录
示例：
2018.06.11~2018.06.18
本周工作（主要写本周做了什么工作）
学习收获（主要是输入，包括算法、源码、书籍、文章、技术点）
亮点、难题、优化（有没有一些经过自己思考和沉淀的产出，比如解决了某些难题、在某些方面提高了效率、性能优化等等，具体的总结形式包括造轮子、博客）
感想、问题（讲一下自己最近遇到问题、痛点，以及自己的一些思考和感想、技术观点）
1. 入职感受
来携程工作一周的几点感受：
对自己的一些告诫：
3. 关于代码质量、规范和文档的一些思考
4. Git 提交代码时遇到的问题
5. 业务工程师如何成长？
大多数的软件工程师都会有这样一个困扰：我天天写业务代码，怎么提高自己的能力？
6. 人是很容易就懈怠的
7. 关于技术学习
对于技能的学习，如果平时不经常用，很难达到熟练甚至深入的程度。所以，对于技能不需要盲目追求广度，而对于基础知识的学习却需要不断积累和巩固。
下周计划
学习计划
阅读
TODO （近期和未来要做的）