高效程序员的45个习惯：敏捷开发修炼之道
内功心法
迭代开发，价值优先，分解任务，真实进度
站立会议，交流畅通，用户参与，调整方向
结对编程，代码质量，测试驱动，安全可靠
持续集成，尽早反馈，自动部署，一键安装
定期回顾，持续改进，不断学习，提高能力
敏捷
不管路走了多远，错了就要重新返回
软件开发一直处于被动、变换的环境中
-敏捷开发
只关注真正重要的事情，少关注那些占用大量时间而无甚裨益的不重要的事情
一种把一人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法
越早发现问题，越容易修复
敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。
反馈 持续开发
态度决定一切
选定了要走的路，就是选定了它通往的目的地
1. 做事
和团队之间交流的技巧
勇于承认自己不知道的答案
出问题了，先解决问题，再处理事情
说话的措辞
开发的时候尽量的多写注释，无论是修复、重构还是交给他人
单元测试，这个目前真的无能为力，最近才刚开始了解，这个东西再开发之前就可以确定开发的边界，重构的时候也有很大的帮助
2. 欲速则不达
- 对事不对人
- 排除万难,奋勇前进
谁去给猫系铃铛，没有第一个吃螃蟹的人，该计划也就不可能开始
学无止境
即使你已经再正确的轨道上，但如果只是停止不前，也仍然会被淘汰出局。
- 跟踪变化
对团队投资
迭代和增量式的学习
了解最新行情
阅读懂的放弃
- 打破砂锅问到底
了解问题产生的根本原因 - 把握开发节奏
把自己的时间规划好,按照计划进行
交付用户想要的软件
- 让客户做决定
- 让设计指导而不是操纵开发
好的设计应该是正确的,而不是精确的.描述的一切必须是正确的,不应该涉及不确定或者可能会发生变化的细节.是目标,不是具体的方法. - 合理的使用技术
- 保持可以发布
- 提早集成,频繁集成
- 提早实现自动化部署
- 使用演示获得频繁反馈
- 使用短迭代,增量发布
迭代:分析、设计、实现、测试、获得反馈 固定的价格就意味着背叛承诺
敏捷反馈
一步行动,胜过千万专家的意见
- 守护天使
单元测试,写带有反馈的代码 - 先用它再实现它
测试驱动开发 - 不同环境,就有不同问题
- 自动验收测试
- 度量真实的进度
- 倾听用户的声音
敏捷编码
- 代码要清晰地表达意图
- 用代码沟通
- 动态评估取舍
即使不能面面俱到,客户认为有价值的东西 - 增量式编程
- 保持简单
开发可以工作的,最简单的解决方法
代码简单是经验和技能的厚积薄发的产物 - 编写内聚的代码
- 告知,不要询问
- 根据契约进行替换
敏捷调试
- 记录问题解决日志
- 警告就是错误
- 对问题各个击破
- 报告所有异常
- 提供有用的错误信息
敏捷协作
- 定期安排会面时间
- 架构师必须写代码
- 实行代码集体所有制
- 成为指导者
- 允许大家自己想办法
注意帮助的方式和方法 - 准备好后再共享代码
- 做代码复查
- 及时通报进展与问题
尾声:走向敏捷
一灯能除千年暗,一智能灭万年愚.
个人总结:
高效的程序员,不仅仅需要有良好的技术基础,还需要良好的编码习惯,沟通能力,所处的团队.都有必然的联系,
开发程序,不仅仅是做事,更多的还是和人有关系,项目经理,甲方等,都避免不了沟通交流
敏捷开发不是一个人的的开发,是一个团队,更多是的交流,
- 技术
- 良好的编码习惯,用注释或者代码能够表达清楚自己的意愿
- 单元测试,再重构的时候显得非常重要
- 代码的质量
- 态度
- 做事的态度,团队交流态度要诚恳,处理问题,对事不对人
- 保持学习的态度,不断的学习
- 交流
- 不仅仅能够开发出产品经理想要的产品,更要深谙客户的需求
- 沟通的方式要是所有的人都觉得舒服,又能帮你解决问题
组件一个高效的团队,需要全面的、综合能力过硬的队友,
这里没有《人月神话》中组建分工划分的那么仔细,
更偏向的是个人怎么更好的再团队中处置各种各样的问题
而阿里出的《不止代码》可以更好的帮助自己了解团队中其他队员的工作,
当交流不顺的时候,可以进行换位思考下,
或许能更好的解决问题
我也有相同的切身感受,但是更多的选择了回避
平衡的艺术,也要结合实际的情况
入职一年的菜鸟,以后学习的还有很多