近期的一些反思

• codesun
• April 10, 2016
• 闲谈
• 反思, 杂谈

自创建这个博客以来，我一直在写一些技术类的文章，虽然写得不怎么样，但贵在坚持。

这几天突然觉得，如果一个博客没有主观性的思想，似乎少了什么，于是乎就有了本文。

关于学习方式的反思

我在博客的“关于”页面提到了博客驱动学习。创建博客的时候，我的计划是每个月4篇，相当于每周一篇周报，当然我不可能积累了这么多的技术文章能够发布，因此这势必会驱使我去学习，这就是博客驱动学习的由来。在实践期间，我发现这个实现起来有困难，理由是平时有课程，有作业，又要写代码，博客的优先级自然高不了。

我的另一种学习方式是通过做项目，但经常会在一个项目快要成型的时候，放弃转而玩其它技术，比如之前的博客平台、Linux发行版、Json解析器等等，现在服务器快要成型了，意料之中，我开始玩起了开发板，当然我并不准备放弃服务器。

这种行为，按照以前一些老师的定义，即为“不专注、不踏实”。众所周知，坚持做一件事不易，而我自认为不是一个有足够毅力坚持到底的人，很多情况下，我着手做一个项目是出于对该技术好奇，想要通过实践来学习个中的原理，当到达“快成型”这个分水岭后，自然地会稍稍膨胀下，产生“这个技术不值得深究”的想法，这也就不难理解为何我会不停地“切换”项目了。

如何评价这种行为？至少从目前来看很难下定论，从学习的角度来看，我确实掌握了关键技术，而继续深入就是一些“体力活”了，价值不大。这和依靠项目发论文类似，当论文发表后，这个项目也就停滞了，因为工程性的活对于学术而言并没有什么价值，后者需要的是开创性。另一方面，从个人成果角度来看，这种学习方式是极为不妥的，稍稍坚持一段时间，或许就能遇到更加有趣的挑战。并且谈得功利一点，这对个人今后的求职或许会有帮助，至少能使简历更加丰满。

关于团队合作的反思

着手做这些项目期间，我尝试邀请过许多小伙伴加入我的项目，当然也形成过一些团队。将一个个人项目变成团队项目，是一件有趣但又困难的事情，其中总会和软件工程理论扯上点关系，但在这里我并不想这么做。

奇怪的是，在组团期间，基本会发生一些相同的现象，成员的积极性不高，而且并不是他们对项目不感兴趣，但就是无法做出贡献。对于小团队而言，实施scrum模型是比较理想的，但scrum的前提就是团队成员积极自觉。这令我一次又一次的感到失望，理想和现实的差距是如此大。

在一次实践中，我觉得可能是他们并没有跟上项目的进度，因此，我把任务的粒度缩减，并将需要涉及的API进行剥离，编写相应的demo，期望他们能够通过修改并改良demo来完成任务。但是当deadline到来，他们依旧没有完成相关内容。

在本科期间，我就总结了关于团队合作失败的一些结论，其中很重要的一条是，“没有约束，就没有团队”。但我当时认为，这应该和个人有关，并不是普适的，因此进入USTC后，我又实践了一下，结果依旧。或许，从个人项目转为团队项目后，成员会觉得他们只是在为你做事，而又没有报酬，真的还不如花时间刷刷知乎，吹吹逼。

没有共同的目标，就没有团队，没有约束，就没有团队。对于绝大部分人而言，这似乎已经成了不变的真理，但我坚信一定有像我一样的人，只不过我没遇到罢了。现实中，很多人答应参与，并不是你的言论打动了对方，只是他们碍于面子没有正面回绝你，他们会通过相对含蓄的方式拒绝你，比如，答应参与，但不贡献。

今后，千万不要轻易邀请人一起做事，能自己完成的就自己来，这里不存在车库文化，己所欲亦勿施于人。

关于技术的反思

对于技术，我个人的技术视角总体而言是偏上层的，这里的上层指的是内核态以上，包含编译技术，POSIX编程，Network开发，以及WEB开发等，大三、大四的时候，认为Web基本就是应用未来的开发形式，但我不想做前端，自然将视角保持在Web框架，甚至是Web服务器了，后来也就有了现在的项目，一路走来，个人的成长是显而易见的。

这几年，前端技术可谓是层出不穷，主要原因是JavaScript的全面爆发，比如nodejs，今年的ThroughsWork的技术雷达也给予了ES6一个Adopt。我个人是支持前段模块化的，但我并不认为JS在后端能有很大的作为，因为采用回调的方式解决异步问题是不完美的，而且它的并发模型也不是普适的。总体而言，目前的局面尚未稳定，Web一统的局面亦尚未成型，但我坚信这是目前的趋势，除非有更加优秀的技术取代，但可能性并不高。

前端如此发展的后果就是，很多框架的模板引擎似乎显得不太必要了，就比如Java Web，一个Servlet处理Ajax请求就行了，这极大降低了Web框架的复杂度，但也使得很多Web服务器变成了纯粹的Restful Api服务器。其中，遭受最大打击的或许应该是PHP，不过现在PHP开发者也基本都用框架，在一定程度上能够减少这种趋势带来的影响。

前端的变革尚未对我的项目造成什么冲击，目前对Web Server影响较大的是HTTP/2.0协议，变动较大，特性很诱人，如二进制协议，连接复用，支持server push等，但是就目前来看，这个协议并不是很成熟，server push基本未被实现，启用的方式还得是通过HTTP/1.1的upgrade，或许未来会有所改观，但至少目前而言，我个人认为应用价值不大，性能也未必有很大的提高。但这些只是我个人暂时不实现HTTP/2.0解析器的说辞罢了，大势所趋，要做的总是逃不了的。

另一项“蓬勃发展”的技术就是Docker，虽然namespace和cgroup并不能算什么新事物了。。。但Docker发展之迅速，实在是令人出乎意料，Docker的发展，带动了微架构的普及，简而言之，就是大家开始将一个大的服务进行拆分，形成一个个小的服务，有点像SOA，但它又不依赖于MQ，这种架构可以扣上很多貌似，比如分布式服务，内部有很多关键，比如一致性协议，服务发现，服务监控，日志聚集等。我虽然较早接触docker，但是很遗憾，直到最近，我才开始着手深入微架构。我个人认为这并不是什么革命性的技术，但却值得深入学习。

在本节的最后，还是得说说老本行——程序语言。在国内，大家谈得最多的还是go，以及rust，我很早就学习过go，这个语言不错，就是少了泛型、动态链接，多了GC，倘若去掉GC后，很多功能将无法实现，相比于C，也就是多了点语法糖，尚不足以说服开发者使用go，只能说国内某些人对于go的普及有很大贡献。听老板说，rust在并发模型中使用了分离逻辑，这倒是挺高级的，尚未深入了解。对于D语言，我还是挺喜欢的，但问题也比较严峻，多了GC，编译器不成熟，有些概念存在问题。所以，我个人依旧是首选，C和lua，lua为C提供动态性，比如实现一些ORM框架，C为lua解决性能问题，听起来还是挺美好的。

在PL方面最值得投入的或许还是形式化验证技术，相比测试，验证是证明程序正确，而测试是为了找出程序的错误，根本无法保证什么。从本质而言，测试技术是在验证技术不成熟的前提下的一种妥协。但问题在于目前的形式化验证工具对程序语言有约束，尤其是像C这种类型系统不严格的语言，如果要应用形式化验证，需要形成一个安全子集。个人拙见，应该开发一种简单的支持形式化验证的语言，将验证工具集成在编译器中，并提供经过验证的安全的标准库，以及常用的容器，如此才能避免对语言本身产生约束或者是对语言妥协。至少我个人觉得应该没有什么能够比证明自己的程序正确更令人兴奋的了。

在技术方面，还是应该不断探索，不断接触新事物，长期从事一个项目，固步不前，反而会对个人的发展不利，好在我喜欢折腾各种东西，唯一缺的就是时间，现在做项目需要时刻考虑，技术含量是否和研究生应有的水平匹配，如果技术含量过低，基本就是在浪费时间了。