怎样把自己培养成为一个优秀的程序员
mzcesoft.blogbus.com 2010年05月07日 13:53 查看4092次 作者: 【大 中 小】
文章分类:其它杂谈
态度篇
1. 做实事:不要抱怨,发牢骚,指责他人,找出问题所在,想办法解决。对问题和错误,要勇于承担。
2. 欲速则不达:用小聪明、权宜之计解决问题,求快而不顾代码质量,会给项目留下要命的死角。
3. 对事不对人:就事论事,明智、真诚、虚心地讨论问题,提出创新方案。
4. 排除万难,奋勇前进:勇气往往是克服困难的唯一方法。
学习篇
5. 跟踪变化:新技术层出不穷并不可怕。坚持学习新技术,读书,读技术杂志,参加技术活动,与人交流。要多理解新词背后的所以然,把握技术大趋势,将新技术用 于产品开发要谨慎。
6. 对团队投资:打造学习型团队,不断提高兄弟们的平均水平。
7. 懂得丢弃:老的套路和技术,该丢,就得丢。不要固步自封。
8. 打破砂锅问到底:不断追问,真正搞懂问题的本质。为什么?应该成为你的口头禅。
9. 把握开发节奏:控制好时间,养成好习惯,不要加班。
开发流程篇
10. 让客户做决定:让用户在现场,倾听他们的声音,对业务最重要的决策应该让他们说了算。
11. 让设计指导而不是操纵开发:设计是前进的地图,它指引的是方向,而不是目的本身。设计的详略程度应该适当。
12. 合理地使用技术:根据需要而不是其他因素选择技术。对各种技术方案进行严格地追问,真诚面对各种问题。
13. 让应用随时都可以发布:通过善用持续集成和版本管理,你应该随时都能够编译、运行甚至部署应用。
14. 提早集成,频繁集成:集成有风险,要尽早尽量多地集成。
15. 提早实现自动化部署
16. 使用演示获得频繁反馈
17. 使用短迭代,增量发布
18. 固定价格就意味着背叛承诺:估算应该基于实际的工作不断变化。
用户篇
19. 守护天使:自动化单元测试是你的守护天使。
20. 先用它再实现它:测试驱动开发其实是一种设计工具。
21. 不同环境,就有不同问题:要重视多平台问题。
22. 自动验收测试
23. 度量真实的进度:在工作量估算上,不要自欺欺人。
24. 倾听用户的声音:每一声抱怨都隐藏着宝贵的真理。
编程篇
25. 代码要清晰地表达意图:代码是给人读的,不要耍小聪明。
26. 用代码沟通:注释的艺术。
27. 动态地进行取舍:记住,没有最佳解决方案。各种目标不可能面面俱到,关注对用户重要的需求。
28. 增量式编程:写一点代码就构建、测试、重构、休息。让代码干净利落。
29. 尽量简单:宁简勿繁。如果没有充足的理由,就不要使用什么模式、原则和特别的技术。
30. 编写内聚的代码:类和组件应该足够小,任务单一。
31. 告知,不要询问:多用消息传递,少用函数调用。
32. 根据契约进行替换:委托往往优于继承。
调试篇
33. 记录问题解决日志:不要在同一地方摔倒两次。错误是最宝贵的财富。
34. 警告就是错误:忽视编译器的警告可能铸成大错。
35. 对问题各个击破:分而治之是计算机科学中最重要的思想之一。但是,要从设计和原型阶段就考虑各部分应该能够很好地分离。
36. 报告所有的异常
37. 提供有用的错误信息:稍微多花一点心思,出错的时候,将给你带来极大便利。
团队协作篇
38. 定期安排会面时间:常开会,开短会。
39. 架构师必须写代码:不写代码的架构师不是好架构师。好的设计都来自实际编程。编程可以带来深入的理解。
40. 实行代码集体所有制:让开发人员在系统不同区域中不同的模块和任务之间轮岗。
41. 成为指导者:教学相长。分享能提高团队的总体能力。
42. 让大家自己想办法:指引方向,而不是直接提供解决方案。让每个人都有机会在干中学习。
43. 准备好后再共享代码:不要提交无法编译或者没有通过单元测试的代码!
44. 做代码复查:复查对提高代码质量、减少错误极为重要。
45. 及时通报进展与问题:主动通报,不要让别人来问你。
mzcesoft.blogbus.com 2010年05月07日 13:53 查看4092次 作者: 【大 中 小】
文章分类:其它杂谈
态度篇
1. 做实事:不要抱怨,发牢骚,指责他人,找出问题所在,想办法解决。对问题和错误,要勇于承担。
2. 欲速则不达:用小聪明、权宜之计解决问题,求快而不顾代码质量,会给项目留下要命的死角。
3. 对事不对人:就事论事,明智、真诚、虚心地讨论问题,提出创新方案。
4. 排除万难,奋勇前进:勇气往往是克服困难的唯一方法。
学习篇
5. 跟踪变化:新技术层出不穷并不可怕。坚持学习新技术,读书,读技术杂志,参加技术活动,与人交流。要多理解新词背后的所以然,把握技术大趋势,将新技术用 于产品开发要谨慎。
6. 对团队投资:打造学习型团队,不断提高兄弟们的平均水平。
7. 懂得丢弃:老的套路和技术,该丢,就得丢。不要固步自封。
8. 打破砂锅问到底:不断追问,真正搞懂问题的本质。为什么?应该成为你的口头禅。
9. 把握开发节奏:控制好时间,养成好习惯,不要加班。
开发流程篇
10. 让客户做决定:让用户在现场,倾听他们的声音,对业务最重要的决策应该让他们说了算。
11. 让设计指导而不是操纵开发:设计是前进的地图,它指引的是方向,而不是目的本身。设计的详略程度应该适当。
12. 合理地使用技术:根据需要而不是其他因素选择技术。对各种技术方案进行严格地追问,真诚面对各种问题。
13. 让应用随时都可以发布:通过善用持续集成和版本管理,你应该随时都能够编译、运行甚至部署应用。
14. 提早集成,频繁集成:集成有风险,要尽早尽量多地集成。
15. 提早实现自动化部署
16. 使用演示获得频繁反馈
17. 使用短迭代,增量发布
18. 固定价格就意味着背叛承诺:估算应该基于实际的工作不断变化。
用户篇
19. 守护天使:自动化单元测试是你的守护天使。
20. 先用它再实现它:测试驱动开发其实是一种设计工具。
21. 不同环境,就有不同问题:要重视多平台问题。
22. 自动验收测试
23. 度量真实的进度:在工作量估算上,不要自欺欺人。
24. 倾听用户的声音:每一声抱怨都隐藏着宝贵的真理。
编程篇
25. 代码要清晰地表达意图:代码是给人读的,不要耍小聪明。
26. 用代码沟通:注释的艺术。
27. 动态地进行取舍:记住,没有最佳解决方案。各种目标不可能面面俱到,关注对用户重要的需求。
28. 增量式编程:写一点代码就构建、测试、重构、休息。让代码干净利落。
29. 尽量简单:宁简勿繁。如果没有充足的理由,就不要使用什么模式、原则和特别的技术。
30. 编写内聚的代码:类和组件应该足够小,任务单一。
31. 告知,不要询问:多用消息传递,少用函数调用。
32. 根据契约进行替换:委托往往优于继承。
调试篇
33. 记录问题解决日志:不要在同一地方摔倒两次。错误是最宝贵的财富。
34. 警告就是错误:忽视编译器的警告可能铸成大错。
35. 对问题各个击破:分而治之是计算机科学中最重要的思想之一。但是,要从设计和原型阶段就考虑各部分应该能够很好地分离。
36. 报告所有的异常
37. 提供有用的错误信息:稍微多花一点心思,出错的时候,将给你带来极大便利。
团队协作篇
38. 定期安排会面时间:常开会,开短会。
39. 架构师必须写代码:不写代码的架构师不是好架构师。好的设计都来自实际编程。编程可以带来深入的理解。
40. 实行代码集体所有制:让开发人员在系统不同区域中不同的模块和任务之间轮岗。
41. 成为指导者:教学相长。分享能提高团队的总体能力。
42. 让大家自己想办法:指引方向,而不是直接提供解决方案。让每个人都有机会在干中学习。
43. 准备好后再共享代码:不要提交无法编译或者没有通过单元测试的代码!
44. 做代码复查:复查对提高代码质量、减少错误极为重要。
45. 及时通报进展与问题:主动通报,不要让别人来问你。