E_Coder程序员iOS

程序员的修炼:从优秀到卓越 - 读书笔记

2016-03-20  本文已影响2185人  J_Knight_
程序员的修炼 - 从优秀到卓越

本书是笔者上一篇读书笔记高效能程序员的修炼的姊妹篇,同样介绍了一些程序员需要了解的,有关于编程本身以外的一些事情。

和上一篇读书笔记的风格类似,笔者摘录了几段原书内容并结合了作者的感悟写下了这篇读书笔记。笔者还是深切希望各路英雄能提出宝贵的意见和想法。


关于 To-Do list

这个冗长的To-Do列表始终存在着,像一把悬挂在我头顶上的利刃,而且每天都在变得更加沉重和锋利。

每天早上使劲想出这天你需要做的最重要的3件事。

其实对于待办事项列表,笔者也读过相关的书籍,一般都是不推荐使用待办事项列表的。笔者总结出原因有二:


关于探索的态度

比起专业技能或者智商,成功更需要一种探索的态度,它是一种对于可能性和失败后果的执着。那些具备良好潜质的人总是会做出类似的回答“我总是在犯一些作物。昨天刚发生了一件挺严重的事情,前因后果是这样的。。。”。

相反,那些回答“我并没有犯过大错误”或者“我犯过一些严重的错误,但是错误的原因并不在于我”的人是不会成为杰出的外科医生的。

探索的态度对于程序员也是尤为重要的。笔者在开始写代码的时候总是以“解决问题就万事大吉”的标准,遇到了可能的坑却睁一只眼闭一只眼。但是每每这样的时候,后来总是会出bug。

其实这就是逃避,就是一种缺乏探索精神的表现。其实我把那些坑弄懂了也不需要多少时间嘛。弄懂了,以后再遇到就稳稳当当搞定了。没弄懂,就还是踩坑。突然想到了一句话:遇到问题,你硬着头皮解决了一半,就只剩下一半的问题。但是你逃避,就是两个问题了。

不管你在做什么项目,怀揣着学习和锻炼的态度去完成它吧,这是绝对值得的!与项目结果相比,过程才是最大的财富。如果你没能从一个项目的过程中学到一点东西,这才是真正失败的项目。


关于专家

这个世界上只有少数的专家,却有大量的普通人。当你想要建立一个包含各种信息的网站时,这些普通人的贡献是最重要的。这是一个不规则的世界,里面装满了无穷无尽的细节。

作为专家,重要的是不是告诉别人你知道什么。而是要清楚你应该问什么样的问题,并且灵活运用你所掌握的知识去解决眼下的具体问题。作为专家,你的作用是提供明确的,可执行的方向。

读到这些,笔者觉得专家理应受到种种质疑,而为了能经得起这些质疑,那么就不应该跟人家说“我读了神马神马著作,精通神马神马技术,你看我的论文,你看我的研究成果等等”,真正证明自己是专家的途径,一般只有帮助非专家人士或者别的专家高效地解决问题。

其实,庞大的知识体系也是对解决问题帮助很大的:因为这些有着庞大知识体系的专家的晶体智力水平很高,很多时候,他们并不需要动脑子(也就是流体智力),直接调出相应知识就能解决。所以说,那些自称专家的人如果连连无法解决问题的话,那么真的是low爆了。


关于软件项目管理

鼓励并强制要求程序员创建一张他们所要做的全部事情的列表,然后尽可能添加所有的子项,这样就能估算这个任务话费多少时间了。

如果有人问你的时间表,你应该拿出一张你要做的所有事情的列表。如果拿不出来,你所要做的第一件事情,就是要做出这么一张列表。

这种列表和待办事项列表稍有不同。这种列表属于“时间表”,它的目的是监控进度:所以说,它的时间总长度是不变的。但是待办事项列表的时间总长度是趋于“无限的”(当然,只对于执行力很差的人来说)。


关于“一夜成名”

一夜成名的传说容易让人误入歧途,并且遗毒不浅。如果你打算做一个全新的东西,要有打持久战的准备。

勤于练习:不是一遍又一遍的简单重复,而是要不断挑战略微超出自身能力之外的任务-努力尝试,并在做的同时以及之后对自己的表现进行评估,然后纠正错误,如此反复。

这里谈到了程序员对自己本身的迭代:快速迭代。其实同软件开发是一个道理:软件迭代的速度远重要于迭代的质量。也就是说,我们在学习的过程中,对自己的提升也应该是快速而轻盈的。

切忌一口气吃个胖子,肯定是吃不消的。应该结合自己已有的知识水平,再寻找对自己来说稍微有点挑战性的技术来攻克,一来学习效率高,二来可以提升自信,进入到新一轮的学习中去。


关于优秀和平庸程序员之间的鸿沟

  • 成为更加优秀的程序员的方法是抛开编程。
  • 你的兴趣越广泛,就能越胜任你的工作。
  • 为了真正地成为一名更好的程序员,你必须培养自己对于编程周边所有事情的热情。
  • 单单靠编程,你只能补足或者增强自己已有的变成技能,永远也无法成为一名优秀的程序员。你需要尝试去了解你的客户,你所处的行业以及相关的业务。
  • 聪明的开发者知道,他们的工作远远不止编写代码和发布产品:他们的工作是开发出人们真正想要使用的软件。这当然包括编码,但还有大量全局性的其他事情,比如撰写技术文档,交互设计,培养用户社区,乃至产品愿景,这些对于软件的全貌成功都是至关重要的。

关于修复bug

在对报告数据的广泛分析之后,我们看到:80%的客服问题在修复了用户报得最多的20%的bug之后就得到解决。即使修复用户报的最多的1%的bug,也能解决50%的客服问题。这个分析结果通常对于各家公司都是成立的。

如果你修复了一个真实用户永远也碰不到的bug,那你修复有什么价值呢?

你越快将你的软件推到真实用户面前,就会得到越多的数据来改进你的软件。问题不在于你在发布软件的时候带去了多少bug,而是在于你能多快地修复那些bug。

因此,笔者认为在bug管理的问题上,要注意两点:


关于衡量软件的成功

多少用户在真正使用你的软件?这才是衡量成功的终极标准。

其实无论交互多绚丽,功能多么吊炸天,一旦用户不需要,用户不喜欢,不掏钱,其实是没有任何卵用的。而且在一定的技术水准上,如果无法“说服”大量客户使用产品,也同样是让人心痛的。


关于用户的谎言

  • 我们必须根据用户的实际行为模式来设计产品。
  • 他们会说喜欢你的软件。但是我们应该去观察他们是否使用了软件,以及他们是怎么使用的。基于行为数据去设计软件,而不是靠用户说的“谎言”。

笔者认为,我们很少能从用户言语上得到用户特别真实的感受。那些善良的客户们有时碍于面子,有时想当和事老,凭着“你好我好大家好”的原则,说一些心里没有的,善意的谎言。

所以那些问卷调查什么的,走街串巷访问什么的其实意义不大。真正能“窥视”用户内心的是那些技术埋点。我记得有一次参加一个分享会,触宝科技的CEO跟大家分享了他们的埋点:他们通过埋点的方式,甚至会知道导致用户删掉app的是哪几个界面和动作。这让我感触很大,既然能做到这些,那么如果想知道用户喜欢点击那里,喜欢看哪里,喜欢做那几个动作,岂不是轻而易举?知己知彼,百战岂殆?


最后作者推荐的书籍

  1. 《代码大全(第二版)》
  2. 《点石成金:访客至上的网页设计秘籍》
  3. 《人件》
  4. 《程序员修炼之道:从小工到专家》
  5. 《软件工程的事实与谬误》

其中第1本和第4本笔者在看。第1本对于非科班出身的笔者来说实在是晦涩难懂。不过既然作者说读完此书就能超过90%的程序员,那么不失为一个节省时间的好方法。以后有机会的话,希望能和各路英雄讨论讨论个中奥妙。


笔者最后的话

其实还是希望能和各位相互讨论,其实相比于文章被“喜欢”,笔者更希望诸位能留下评论,毫不留情地指出小弟想法中的不妥之处,这些是远比“打赏”和“喜欢”更让小弟高兴的呢!

本文已经同步到我的个人博客:传送门,欢迎常来^^


本文已在版权印备案,如需转载请访问版权印。48422928

获取授权

上一篇下一篇

猜你喜欢

热点阅读