高效程序员的45个习惯总结版文末脑图

编程

1 做事

一个重大的错误应该被当做一次学习而不是指责他人的机会,团队成员一起工作,应该互相帮助,而不是互相指责

2 欲速则不达

不要为了修复问题而去修复,要投入时间和精力保持代码整洁

3 对事不对人

一个团队能够很公正的讨论一些方案的优点和缺点,你不会因为拒绝了有太多缺陷的方案而伤害别人,也不会因为采纳了某个不完美(但更好的)解决方案而被人记恨

尽量贡献自己的好想法;不要脱离实际的争论;不要带个人情绪的争论和盲目接收观点

4 排除万难,奋勇前进

如果设计或者代码中出现了奇怪的问题,花时间去理解为什么代码会这样。如果你找到了解决办法,但代码还是令人费解,那么只能重构,让它可读性更强。如果你没有理解那段代码,就不要轻易否定和重写它们

如果在你提出代码中出现问题的时候,遭到抵制,你需要用他们能够听懂的话表达

5 跟踪变化

跟踪技术变化,你不需要精通所有技术,但需要清除知道行业的动向,从而规划你的项目和职业生涯

6 对团队投资

"一个学习型的团队才是较好的团队",比如设定每周轮流主持讲座,讲完后,进行开放式讨论,这样每个人都可以发表自己的意见

7 懂得丢弃

在合适的场景决定使用新技术还是旧技术

8 打破砂锅问到底

通过问"为什么",直到明白问题的根源

9 把握开发节奏

在每天结束的时候,测试、提交代码

以固定、规律的长度运行迭代,调整迭代长度,找到团队最舒服可行的时间值

10 让客户做决定

让你的客户做决定,开发者,经理或者业务分析师不应该做业务方面的决定,用业务负责人能够理解的语言,向他们详细解释遇到的问题,并让他们做决定

11 让设计指导而不是操纵开发

"不要在前期做大量的设计",在没有经过真正的代码验证之前,不要陷入太多的设计任务。当对设计一无所知的时候,投入编码业是一件很危险的事 。好的设计应该是正确的,而不是精确的,也就是说它描述的一切必须是正确的,不应该涉及不确定或者可能发生变化的细节,它是目标,不是具体的地方

12 合理的使用技术

根据需要选择技术,首先决定什么是你需要的,要解决什么问题,接着为这些具体的问题评估使用技术,对任何要使用的技术,多问一些挑剔的问题,并如实回答

13 保持可以发布

保证系统随时可以编译,运行,测试并立即部署,可以通过分支来专门处理某个需要修复的问题,再把代码合并到主分支,但这里需要注意代码冲突问题,简单流程是 本地测试 > 检查最新代码 > 提交代码,最好是通过持续集成系统,自动集成部署并报告集成结果

14 提早集成,频繁集成

代码集成是主要的风险来源,要规避这个风险,只有提早集成,持续而有规律的集成,比如每天集成2-5次,如果到最后才进行集成,可能将花费更多的时间来解决集成中的问题,而持续集成发生的问题都是一些小问题更容易解决

15 提早实现自动化部署

自动化部署使得软件能在不同的目标机器上同时部署应用,并且更容易发现问题,比如缺少依赖关系

16 使用演示获得频繁反馈

在开发软件的时候,要跟客户保持沟通,每个一周或者两周,将完成的最新功能演示给客户看,并获取他们的反馈

17 使用短迭代,增量发布

发布带有最小可用功能块的产品,每个增量开发,使用1-4周左右迭代周期

18 固定的价格就意味着背叛承诺

软件项目是变化无常的,不可重复,如果要提前给出一个固定价格,就几乎肯定不能遵守开发上的承诺,如果必须要提供一个价格,可以先构建最初的,小而有用的部分,并给客户演示,客户可以选择继续开发,还是停止或者取消合同

19 守护天使

使用自动化的单元测试,好的单元测试能够为你的代码问题提供及时的警报,如果没有好的单元测试,就不要轻易设计和修改代码,直到修改好单元测试

20 先用它再实现它

测试驱动开发(TDD),先写测试,再写代码。先写测试能让你从用户的角度去思考,而不是一个单纯的实现者,另外先写测试有助于消除过度复杂的设计

  • 测试驱动开发 https://juejin.im/post/5c3e73876fb9a049d37f5db1

  • 测试驱动开发实例 https://blog.csdn.net/mostbravebird/article/details/12833409

21 不同的环境,就有不同的问题

使用持续集成工具,在不同的平台和环境中运行单元测试

22 自动验收测试

使用客户的业务逻辑来验证系统

23 度量真实的进度

评估剩下的工作量,不要用不恰当的评估来欺骗自己或者团队,要评估那些需要完成的待办事项,通过待办事项,就可以随时知道下一步最重要的任务是什么。有时候对于一个任务,评估是2天,做到一半发现还需要4天时间来完成任务。

24 倾听用户的声音

每一个用户的抱怨都是有原因的,不要生气,不需要轻视,要找出真相,修复真正的问题

25 代码要清晰的表达意图

应该让自己或者团队的其他任何人,可以读懂自己一年前写的代码,而不是只读一遍就知道的它的运行机制。

在编写代码时,应该使用语言特性来提升表现力,使用方法名来传达意向,对方法参数的命名要帮助读者理解背后的想法,异常传达的信息是哪些可能会出问题,以及如何进行防御式编程,要正确的使用和命名异常,好的编码规范可以让代码变得易于理解,同时减少不必要的注释和文档。

26 用代码沟通

写简明扼要的注释;

在代码可以传递意图的地方不要使用注释;

解释代码做了什么的注释用处不那么大,反而注释要说明为什么会这样写代码;

当重写方法时,保留描述原有方法意图和约束的注释

27 动态评估取舍

如果现在投入额外的资源和精力,是为了将来可能得到的好处,要确认投入一定要得到回报(大部分情况下,是不会有回报的);

真正的高性能系统,从一开设计时就在向这个方法努力;

过早的优化是万恶之源;

过去用过的解决方案对当前的问题可能适用,也可能不适用,不要事先预设结论,先看看现在的状况;

28 增量式编程

在很短的编辑、构建、测试循环中编写代码,要比话费长时间仅仅做编写代码的工作好得多,可以创建更加清晰、简单、易于维护的代码。

如果构建和测试循环花费时间过长,你就不会希望经常运行他们了,要保证测试可以快速运行;

在编译和测试运行中,停下来想一想,并暂时远离代码细节,这是保证不会偏离正确方向的好办法;

要休息的话,就要好好休息,休息时远离键盘;

要像重构你的代码那样,重构你的测试,要经常重构测试;

29 保持简单

开发可以工作的、最简单的解决方案。除非有不可辩驳的原因,否则不要使用模式、原则和高难度技术之类的东西。

代码几乎总是可以得到进一步精炼,但到了某个点后,再做改进就不会带来任何实质性的好处了。

强行让代码变得优雅和过早优化类似,同样会产生恶劣的影响。

简单的解决方案必须要满足功能需求,为了简单而在功能上妥协,这就是过分简单化了。

30 编写内聚的代码

让类的功能尽量集中,让组件尽量小,避免创建很大的类或组件,也不要创建无所不包的大杂烩类

31 告知,不要询问

不要抢别的对象或是组件的工作,告诉它做什么,然后盯着你自己的职责就好

调用者不应该给被调用对象做决策,这个工作应该由被调用对象自己完成

32 根据契约进行替换

通过替换代码来扩展系统,通过替换遵循接口契约的类,来添加并改进功能特性,要多使用委托而不是继承

相对继承来说,委托更加灵活,适应力也更强

33 记录问题解决日志

维护一个问题及其解决方案的日志,保留解决方案是修复问题过程的一部分,以后发生相同或类似问题时,就可以快速找到并使用

34 警告就是错误

将警告视为错误,签入带有警告的代码,就是签入有错误或者没有通过测试的代码一样,都是极差的做法,签入构建工具中的代码不应该产生任何警告信息

35 对问题各个击破

将问题与应用其他部分隔离开,可以将关注点直接放在与问题相关的议题上,可以通过多种改变,来发现问题发生的核心,只有最小数量的相关代码与问题有联系

36 报告所有的异常

处理或者向上传播所有的异常;当捕获或者抛出异常时,都要记录日志信息;

37 提供有用的错误信息

展示有用的错误信息,提供更易于查找错误细节的方式,发生问题时,要展示出尽量多的支持细节,不过别让用户陷入其中

38 定期安排会面时间

定期与开发人员进行良好的沟通,立会是比较好的选择,立会一般在大家到公司后的半个小时到一个小时之内举行。立会能让团队达成共识,保证会议短小精悍不跑题。

39 架构师必须写代码

优秀的设计从积极的程序员那里开始演化,积极的编程可以带来深入的理解,不要使用不愿意编程的架构师,不知道系统的真实情况,就无法展开设计。

40 实行代码集体所有制

任何一位团队成员,只要理解某段代码的来龙去脉,就应该可以对其进行处理,如果某一段代码只有一位开发人员能够处理,项目的风险无形中就增加了。

在团队中实行任务轮换制,让每个成员都可以接触到不同部分的代码,可以提升团队整体的知识和专业技能,也可以提升代码的整体质量

代码集体制并不意味着可以随心所欲的随意改变代码

41 成为指导者

分享自己的知识,付出的同时便有收获,还可以激励别人获得更好的成果,而且提升整个团队的实力

42 允许大家自己想办法

给别人自己解决问题的机会,指给他们正确的方向,而不是直接提供解决方案,每个人都能从中学到不少东西

用问题来回答问题,可以引导提问的人走上正确的道路

如果有人真的陷入坑里,就不要折磨他们了,告诉他们答案,再解释为什么是这样

43 准备好后再共享代码

绝不要提交尚未完成的代码,不要签入编译未通过或者没有通过单元测试的代码,代码一旦提交,别人就可以访问到

44 做代码复查

复查所有的代码,有助于提升代码质量和降低错误率,

在代码复查中要看什么呢?如下是基本的检查列表:

  • 代码能否被读懂和理解

  • 是否有任何明显的错误

  • 代码是否会对应用的其他部分产生不良的影响

  • 是否存在重复的代码

  • 是否存在可以改进或重构的部分

45 及时通报进展与问题

及时通报进展与问题,发布进展状况,新的想法和目前正在关注的主题,不要等着别人来问项目状态如何。

图片转自https://www.jianshu.com/p/84a6ba715049

以上是 高效程序员的45个习惯总结版文末脑图 的全部内容, 来源链接: utcz.com/z/510699.html

回到顶部