Loading...
墨滴

呜呜啦

2021/08/26  阅读:34  主题:默认主题

【必读推荐】代码整洁之道-程序员的职业素养

整理了一下《代码整洁之道--程序员的职业素养》中一些受益匪浅的观点。

第一章 专业主义

  1. 清楚你想要什么

  2. 承担责任

  3. 了解你的领域

失误率永远不能等于0,但你有责任让它无限接近于零。

每个专业软件开发人员必须了解的技能:

  1. 设计模式。必须能够描述GOF书中的全部24种模式。
  2. 设计原则 必须了解SOLID原则,深刻理解组件设计原则
  3. 结构图 流程图 决策表 状态迁移图表

第二章 说“不”

大多数时间我们都希望能够说“是”。健康的团队都会努力寻找给他人肯定的答复。运作良好的团队经理和开发人员,会相互协商,直到达成共同认可的行动方案。

但是有时候,获取正确决策的唯一途径,便是勇敢无畏的说“不”。这个是比说“是”更负责任,更专业,也更困难的能力。

第三章 说“是”

  1. 遵守承诺
  2. 如果这个事情依赖他人,无法掌控,需要采取一些具体行动来达成目标。比如坐下来讨论一下具体行动,来一步一步接近目标,直至完成目标。
  3. 如果确实无法完成,赶紧去调整别人对你的预期,越快越好

第四章 编码

给他人提供帮助并非说明你更聪明,而是你带来了一个新的视角,对解决问题起到了显著的催化作用。PS:这个描述有点绝对,事实上能够提供完善的解决方案,一眼看出问题出在什么地方也是一种可贵的能力和丰富经验的累积。

辅导年轻的程序员是经验丰富程序员的职责所在,向资深的导师寻求帮助也是年轻程序员的专业职责。

第五章 TDD的三项法则

  1. 在编写好失败单元测试之前,不编写任何产品代码
  2. 只要有一个单元测试失败了就不需要再写测试代码;无法通过编译也是一种失败情况
  3. 产品代码恰好能够让当前失败的单元测试通过即可,不要多写。

TDD可以提升代码确定性、降低代码缺陷率,优化文档和设计的原则。

测试先行,会迫使你去思考什么是好的设计。

事后测试只是一种防守,先行编写测试则是进攻。事后编写的测试已经受制于已有代码,已经知道问题是如何解决的。测试先行的防守编写测试代码比起来,后写的测试在深度和捕获错误的灵敏度方面要逊色很多。

第六章 练习-自身经验的扩展

老板的职责不包括避免你的技术落伍,也不包括为你打造一份好看的简历。保持自己的技能不落伍是自己的责任。

第七章 验收测试

做业务和写程序的人都容易陷入一个陷阱:过早进行精细化。

  1. 不确定性原则

东西画在纸上与真正做出来,是不一样的。业务方看到真正运行的情况就会意识到,自己想要的东西根本不是这样。

一看到已经满足的需求,关于到底想要什么,他们就会有更好的想法——通常并不是他们当时想看到的样子。

  1. 预估焦虑

即便拥有全面准确的信息,评估也通常会存在巨大的变数。其次,因为不确定原则的存在,不可能通过反复推敲实现早起的精准性。需求一定会变化的,所以过早追求精确性是徒劳的。

身为专业开发人员,你的职责是协助开发团队开发出最棒的软件。也就是说每个人都需要关心错误和疏忽,并协助改正。

验收测试和单元测试

验收测试是业务方的,是正式的需求文档,描述了业务方认为系统应该如何运行。关心验收测试结果的是业务方和程序员。

单元测试是程序员写给程序员的,它是正式的设计文档,描述了底层结构和代码行为,关心单元测试结果的只是程序员。

它们的主要目的是如实描述系统的设计、结构和行为。当然他们也可以验证设计、结构和行为是否达到了具体指标,但是它们的真正价值不是在测试上,而是在具体指标上。

第八章 测试策略

尽管公司可能设有独立的QA小组专门负责测试软件,但是开发小组仍然要把“QA应该找不到任何错误”作为努力的目标。

对于QA找到的每一个问题,开发团队都应高度重视,认真对待。应该反思为什么出现这种错误,并采取措施避免今后重犯

第九章 时间管理

关于会议,有两条真理

  1. 会议是必需的
  2. 会议浪费了大量的时间

在走入死胡同后可以快速意识到,并且有勇气走回头路。这就是坑法则:如果你掉进了坑里,别挖。

第十章 预估

当发现预估的时间不足时,最重要的是努力解决这个问题,并向外部同步进展。

预估真正的问题在于:业务方认为是承诺,开发方认为是猜测。

不要给出承诺,除非你确切知道可以完成。

第十二章 协作

你需要理解手上正在编写的代码业务价值是什么,了解雇佣你的企业将如何从你的工作中获得回报。

对做的事情充满激情是好的,但是,最好把注意力集中到付我们薪水的老板所追求的目标上。(关注业务和业务目标)

呜呜啦

2021/08/26  阅读:34  主题:默认主题

作者介绍

呜呜啦