《高效程序员的45个习惯：敏捷开发修炼之道》了解一下

叁歲伎倆 2021-09-16 00:38 256阅读 0赞

高效程序员的45个习惯：敏捷开发修炼之道

--------------------

内功心法

> 迭代开发，价值优先，分解任务，真实进度  
> 站立会议，交流畅通，用户参与，调整方向  
> 结对编程，代码质量，测试驱动，安全可靠  
> 持续集成，尽早反馈，自动部署，一键安装  
> 定期回顾，持续改进，不断学习，提高能力

# 敏捷 #

> 不管路走了多远，错了就要重新返回

软件开发一直处于被动、变换的环境中

\-敏捷开发  
只关注真正重要的事情，少关注那些占用大量时间而无甚裨益的不重要的事情  
一种把一人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法  
越早发现问题，越容易修复

敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。  
**反馈** **持续开发**

# 态度决定一切 #

> 选定了要走的路，就是选定了它通往的目的地  
> 1. 做事  
> 和团队之间交流的技巧  
> 勇于承认自己不知道的答案  
> 出问题了，先解决问题，再处理事情  
> 说话的措辞

开发的时候尽量的多写注释，无论是修复、重构还是交给他人  
单元测试，这个目前真的无能为力，最近才刚开始了解，这个东西再开发之前就可以确定开发的边界，重构的时候也有很大的帮助  
2. 欲速则不达

1.  对事不对人
2.  排除万难,奋勇前进  
    谁去给猫系铃铛，没有第一个吃螃蟹的人，该计划也就不可能开始

# 学无止境 #

> 即使你已经再正确的轨道上，但如果只是停止不前，也仍然会被淘汰出局。

1.  跟踪变化
2.  对团队投资  
    迭代和增量式的学习  
    了解最新行情  
    阅读
3.  懂的放弃
4.  打破砂锅问到底  
    了解问题产生的根本原因
5.  把握开发节奏  
    把自己的时间规划好,按照计划进行

# 交付用户想要的软件 #

1.  让客户做决定
2.  让设计指导而不是操纵开发  
    好的设计应该是正确的,而不是精确的.描述的一切必须是正确的,不应该涉及不确定或者可能会发生变化的细节.是目标,不是具体的方法.
3.  合理的使用技术
4.  保持可以发布
5.  提早集成,频繁集成
6.  提早实现自动化部署
7.  使用演示获得频繁反馈
8.  使用短迭代,增量发布  
    迭代:分析、设计、实现、测试、获得反馈
9.  固定的价格就意味着背叛承诺

# 敏捷反馈 #

> 一步行动,胜过千万专家的意见

1.  守护天使  
    单元测试,写带有反馈的代码
2.  先用它再实现它  
    测试驱动开发
3.  不同环境,就有不同问题
4.  自动验收测试
5.  度量真实的进度
6.  倾听用户的声音

# 敏捷编码 #

1.  代码要清晰地表达意图
2.  用代码沟通
3.  动态评估取舍  
    即使不能面面俱到,客户认为有价值的东西
4.  增量式编程
5.  保持简单  
    开发可以工作的,最简单的解决方法  
    代码简单是经验和技能的厚积薄发的产物
6.  编写内聚的代码
7.  告知,不要询问
8.  根据契约进行替换

# 敏捷调试 #

1.  记录问题解决日志
2.  警告就是错误
3.  对问题各个击破
4.  报告所有异常
5.  提供有用的错误信息

# 敏捷协作 #

1.  定期安排会面时间
2.  架构师必须写代码
3.  实行代码集体所有制
4.  成为指导者
5.  允许大家自己想办法  
    注意帮助的方式和方法
6.  准备好后再共享代码
7.  做代码复查
8.  及时通报进展与问题

# 尾声:走向敏捷 #

> 一灯能除千年暗,一智能灭万年愚.

--------------------

个人总结:

> 高效的程序员,不仅仅需要有良好的技术基础,还需要良好的编码习惯,沟通能力,所处的团队.都有必然的联系,  
> 开发程序,不仅仅是做事,更多的还是和人有关系,项目经理,甲方等,都避免不了沟通交流  
> 敏捷开发不是一个人的的开发,是一个团队,更多是的交流,

*  技术  
    
    
     *  良好的编码习惯,用注释或者代码能够表达清楚自己的意愿
     *  单元测试,再重构的时候显得非常重要
     *  代码的质量
 *  态度  
    
    
     *  做事的态度,团队交流态度要诚恳,处理问题,对事不对人
     *  保持学习的态度,不断的学习
 *  交流  
    
    
     *  不仅仅能够开发出产品经理想要的产品,更要深谙客户的需求
     *  沟通的方式要是所有的人都觉得舒服,又能帮你解决问题

组件一个高效的团队,需要全面的、综合能力过硬的队友,  
这里没有《人月神话》中组建分工划分的那么仔细,  
更偏向的是个人怎么更好的再团队中处置各种各样的问题  
而阿里出的《不止代码》可以更好的帮助自己了解团队中其他队员的工作,  
当交流不顺的时候,可以进行换位思考下,  
或许能更好的解决问题

我也有相同的切身感受,但是更多的选择了回避  
平衡的艺术,也要结合实际的情况  
入职一年的菜鸟,以后学习的还有很多