共计 1707 个字符,预计需要花费 5 分钟才能阅读完成。
整顿了一下《代码整洁之道 – 程序员的职业素养》中一些受益匪浅的观点。
第一章 业余主义
- 分明你想要什么
- 承担责任
- 理解你的畛域
失误率永远不能等于 0,但你有责任让它有限接近于零。
每个业余软件开发人员必须理解的技能:
- 设计模式。必须可能形容 GOF 书中的全副 24 种模式。
- 设计准则 必须理解 SOLID 准则,深刻理解组件设计准则
- 结构图 流程图 决策表 状态迁徙图表
第二章 说“不”
大多数工夫咱们都心愿可能说“是”。衰弱的团队都会致力寻找给别人必定的回答。运作良好的团队经理和开发人员,会互相协商,直到达成独特认可的口头计划。
然而有时候,获取正确决策的惟一路径,便是勇敢无畏的说“不”。这个是比说“是”更负责任,更业余,也更艰难的能力。
第三章 说“是”
- 恪守承诺
- 如果这个事件依赖别人,无奈掌控,须要采取一些具体口头来达成指标。比方坐下来讨论一下具体口头,来一步一步靠近指标,直至实现指标。
- 如果的确无奈实现,连忙去调整他人对你的预期,越快越好
第四章 编码
给别人提供帮忙并非阐明你更聪慧,而是你带来了一个新的视角,对解决问题起到了显著的催化作用。PS:事实上可能提供欠缺的解决方案,一眼看出问题出在什么中央也是一种可贵的能力和丰盛教训的累积。
辅导年老的程序员是经验丰富程序员的职责所在,向资深的导师寻求帮忙也是年老程序员的业余职责。
第五章 TDD 的三项法令
- 在编写好失败单元测试之前,不编写任何产品代码
- 只有有一个单元测试失败了就不须要再写测试代码; 无奈通过编译也是一种失败状况
- 产品代码恰好可能让以后失败的单元测试通过即可,不要多写。
TDD 能够晋升代码确定性、升高代码缺陷率,优化文档和设计的准则。
测试后行,会迫使你去思考什么是好的设计。
预先测试只是一种防守,后行编写测试则是防御。预先编写的测试曾经受制于已有代码,曾经晓得问题是如何解决的。测试后行的防守编写测试代码比起来,后写的测试在深度和捕捉谬误的灵敏度方面要逊色很多。
第六章 练习 - 本身教训的扩大
老板的职责不包含防止你的技术掉队,也不包含为你打造一份难看的简历。放弃本人的技能不掉队是本人的责任。
第七章 验收测试
做业务和写程序的人都容易陷入一个陷阱:过早进行精细化。
- 不确定性准则
货色画在纸上与真正做进去,是不一样的。业务方看到真正运行的状况就会意识到,本人想要的货色基本不是这样。
一看到曾经满足的需要,对于到底想要什么,他们就会有更好的想法——通常并不是他们过后想看到的样子。
- 预估焦虑
即使领有全面精确的信息,评估也通常会存在微小的变数。其次,因为不确定准则的存在,不可能通过反复推敲实现早起的精准性。需要 肯定会 变动的,所以过早谋求精确性是徒劳的。
身为业余开发人员,你的职责是帮助开发团队开发出最棒的软件。也就是说每个人都须要关怀谬误和忽略,并帮助改过。
验收测试和单元测试
验收测试是业务方的,是正式的需要文档,形容了业务方认为零碎应该如何运行。关怀验收测试后果的是业务方和程序员。
单元测试是程序员写给程序员的,它是正式的设计文档,形容了底层构造和代码行为,关怀单元测试后果的只是程序员。
它们的次要目标是如实形容零碎的设计、构造和行为。当然他们也能够验证设计、构造和行为是否达到了具体指标,然而它们的真正价值不是在测试上,而是在具体指标上。
第八章 测试策略
只管公司可能设有独立的 QA 小组专门负责测试软件,然而开发小组依然要把“QA 应该找不到任何谬误”作为致力的指标。
对于 QA 找到的每一个问题,开发团队都应高度重视,认真对待。应该反思为什么呈现这种谬误,并采取措施 防止今后重犯。
第九章 工夫治理
对于会议,有两条真谛
- 会议是必须的
- 会议节约了大量的工夫
在走入死胡同后能够疾速意识到,并且 有勇气 走回头路。这就是 坑法令:如果你掉进了坑里,别挖。
第十章 预估
当发现预估的工夫有余时,最重要的是致力解决这个问题,并向内部同步停顿。
预估真正的问题在于:业务方认为是承诺,开发方认为是猜想。
不要给出承诺,除非你确切晓得能够实现。
第十二章 合作
你须要了解手上正在编写的代码业务价值是什么,理解雇佣你的企业将如何从你的工作中取得回报。
对做的事件充斥激情是好的,然而,最好把注意力集中到付咱们薪水的老板所谋求的指标上。(关注业务和业务指标)