读后感-高效程序员的45个习惯

前言

如果出于对项目或者产品, 我其实没有多大兴趣读这本书, 因为作为打工人, 公司的条条框框已经疲于应付了.

举例来说, 时间紧任务多, 哪管UT是否质量上乘?

想的都是跑满覆盖率然后赶紧提交转测罢了.

UT也没人看.

但是, 为了能够了解高效的本质, 不做无用功, 不出岔子, 了解什么算好的开发习惯, 可以帮助我看清当前开发面临问题的本质, 基于以上, 我还是想读一读这本书.

PS 读文学名著不如读专业类的书籍让我更投入, 比如"刀锋", 麦田里的守望者倒也不错, 为了快速读其他的书, 这本书我跳读的, 如果印象不错, 是要重读的.

第1章 敏捷-高效软件开发之道

第2章 开始敏捷 Beginning Agility

2.1 一切为了目标 Work for Outcome

身边的人, 包括我, 都喜欢"对人不对事儿", 办公室氛围实在让我觉得不舒服, 懂得多的人喜欢以技术大佬自居, 高傲的睥睨一切,

向他咨询问题, 总是一副我是白痴的姿态, 喜欢拥趸提供情绪价值, 迎合他, 说他爱听的话, 而我也是这样的人, 我对一些事和一些人也有烦躁的情绪, 这章让我认识自己, 感谢.

我也觉得"顶糟糕"的事情: 和一群爱搬弄是非的人共事.

之前, 我觉得不去配合这种氛围做好自己就行了, 但是, 这就类似"投名状"? 大家都在说另一个人坏话, 我能不接茬吗? 我选择转移开, 或者把话圆回来, 因为我不那么喜欢, 哦 也许是还没惹到我, 去谈论别人的问题, 因为自己也有类似的毛病.

本章带来的启发:
遇到问题, 想的首先不是谁的责任, 而是如何解决, 快速的, 以及如何避免.
如果, 有人带着抱怨来找我, 那么我首先了解清楚问题, 然后需要我提供什么样的帮助, 来解决. 因为不去追求责任, 可以消除对方的顾虑, 同时也会让对方觉得我是一个"靠谱的对事儿不对人"的家伙,
他们以后也可以放心的来找我, 因为我是真心的帮助他们解决问题, 赢得信赖, 我觉得也是"领导力"的一部分吧.

因为, 我比较崇尚"团队"精神, 我多次感受过, 多个人一起, 头脑风暴, 想出很多一个人不容易想到的方法可以解决很多事情.

我也觉得, 当我有问题的时候, 我积极的解释清楚我想要什么帮助, 并清晰地表达我想解决问题, 而不是指责别人, 当然, 前提是别人造成的问题, 而非自己, 我向上汇报时, 一直都是这样做的.

但是, 遇到自己造成的问题, 我有时候不那么容易接受对方的不耐烦的态度, 当然, 如果最终能解决问题, 事后我也会原谅对方的傲慢.
毕竟, 虽然是一个团队, 还是有点竞争关系的, 为了绩效?

无论是谁犯的错误, 都是团队内一次极佳的锻炼和学习的机会, 让团队的每个人收益, 促进团队整体的技术水平, 构建和谐的氛围, 进而让团队更容易走向成功.

不要说: “这不是我的问题”, “这都是你造成的”.

但是, 现在的氛围 我能做的影响不大, 毕竟面向领导工作, 领导喜欢追责, 喜欢搞个人成就崇拜, 大家渐渐忽视团队的合作了也就.

2.2 欲速则不达 Quick Fixes Become Quicksand

本章描述了这样的场景:
对于乱麻似的代码, 不去充分理解交互逻辑和上下文, 为了快速的解决当前的问题, 做的一些调整, 暂时是有效的, 但是就像一个定时炸弹, 不知道什么时候, 以什么样的方式爆炸.

匆匆写下的代码, 很容易导致难维护的一坨, 确实会遇到书中提到的场景: 不要动那写代码, 写这个代码的人已经不在了.
代码逻辑混乱, 但是依然在生产环境上运行, 只是没几个人, 除非万不得已, 愿意捏着鼻子去"欣赏"这坨杰作.

如果团队内这样的事情很多, 成员是不可能敏捷的.

避免这种问题, 可以尝试以下方法:

• 不要独自编程: 团队内的成员互相阅读各自写的代码, 读得越多, 越好, 更容易发现bug. (不过, 一般都是代码review的时候会这么做吧? 平常除非, 需求涉及到, 不怎么会读别人的代码)
• 用好UT: 单元测试可以帮助你把代码自然的分层, 模块化, 易管理. 一个良好的UT类似一中可执行的文档, 可以帮助阅读者更好的理解代码的业务逻辑. (我们这边UT纯是为了覆盖率, 还不如直接看代码理解得快)

记住: 不要一头扎进"简单快速"的bug修复中, 简单快速不一定有效, 保持代码整洁, 做到容易阅读, 容易管理才重要.(类似"代码整洁之道"中提到的? 亦或是"代码大全"? 提到的一种观点: 软件工程中的代码首先是给人看的, 其次是让机器跑的.)

“源码面前了无秘密”, 如果想要了解清楚功能是怎么实现的? 去阅读代码吧, 源码没有设置"警戒线"阻止你.
也许你不了解每一块代码处理细节, 也不了解算法每一步是怎么执行的, 但是你已经具有了通用的应付工作足够的能力, 自信点, 勇敢的读下去, 一切终将明朗(更好的实现自己的功能需求).

注意平衡:

• 你需要知道每块代码工作原理, 但是不要精通, 因为我们并不是要成为语言专家, 或者做什么研究, 一切为了高效.
• 如果团队有成员表明某块代码难以理解, 那么团队内的其他成员(包括原作者)也难以维护它, 那么就要考虑简化它.
• 不了解清楚代码前, 不要做蹩脚的修复. 不要解决现象, 而是解决本质问题.
• 大多数系统比较复杂, 没有任何一个人可以熟悉全部, 站在更高维度去理解系统中大部分组件是如何交互的, 对于你要从事的部分要深入理解.

2.3 对事儿不对人 Criticize Ideas, Not People

我们也许都曾遇到过, 讨论逐渐失控, 并由情绪引导, 最终下结论的依据是"谁提出的"而不是"想法更好".

这很正常, Lee在展示一个新的想法, 很容易说"这很蠢", 显然地, 这也代表Lee很蠢.
稍微好点的说法是带点解释: “这很蠢, 你忘记考虑线程安全了”.
实际上, 花点心思, 这样说更合适: “感谢Lee的展示, 我有个疑惑, 如果两个用户同时登陆会发生什么?”.

看到区别了吗? 对于错误的观点, 人们通常有如下的反应:

• 驳斥这个人能力不够.
• 驳斥观点有明显的缺陷.
• 询问队友自己的疑惑.

第一个反应, 简直就是白费力气, 计算Lee是一个十足的笨蛋, 一点也不懂编程, 指出这些事实并不能提升他的教育水平, 反而会导致今后他再也不敢提供任何想法了.
第二个反应, 有点聚焦问题了, 但是对于Lee的帮助有限, 很可能会导致反噬, 比如, Lee很可能会通过比较机灵的方式回应线程不安全: “哦! 这不涉及多线程, 因为这将运行在Frozbot模块的上下文中, Frozbot在一个独立的线程中运行.”, “操, 忘了这个Frozbot模块了”, 事到如今, 感到尴尬的就只剩你自己了, 并且还得罪了Lee, 因为你觉得他是个笨蛋.
第三个反应, 没有指责, 没有评判, 只是简单的阐释一个想法, 这将让Lee自主的识别这个问题, 而不是把问题甩到他脸上. 这就是良好沟通的开始, 而不是令人不快的争论的开始.