转载

近期的一些反思

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

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

关于学习方式的反思

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

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

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

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

关于团队合作的反思

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

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

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

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

没有共同的目标，就没有团队，没有约束，就没有团队。在哪里都一样，无论你说得如何天花乱坠，很多人可能只是碍于面子没有拒绝你的邀请，并不是发自内心的想要参与进来。这是咱们这里特有的拒绝人的方式：答应参与，但不干活。

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

关于技术的反思

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

这几年，前端技术可谓是层出不穷，主要原因是javascript的全面爆发，比如nodejs。我个人是支持前段模块化的，只不过目前的局面尚未彻底稳定，web一统的局面也尚未成型，但我坚信这是目前的趋势，除非有更加优秀的技术取代，但可能性不高。

前端如此发展的后果就是，很多框架的模板引擎似乎显得不太必要了，就比如java web，一个servlet处理ajax请求就行了，这极大降低了web框架的复杂度，也使得很多web服务器变成了restful api服务器。

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

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

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

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

在技术方面，还是应该不断探索，不断接触新事物，长期从事一个项目，故步不前，反而会对个人的发展不利，好在我会折腾各种东西。

原文 http://blog.lucode.net/tattle/introspection.html

正文到此结束