神刀安全网

近期的一些反思

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

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

关于学习方式的反思

我在博客的“关于”页面提到了博客驱动学习。创建博客的时候,我的计划是每个月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这种类型系统不严格的语言,如果要应用形式化验证,需要形成一个安全子集。我个人的拙见是,应该开发一种简单的支持形式化验证的语言,将验证工具集成在编译器中,并提供经过验证的安全的标准库,以及常用的容器,如此才能避免对语言本身产生约束或者是对语言妥协。应该没有什么能够比证明自己的程序正确更令人兴奋的了。

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

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 近期的一些反思

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
分享按钮