如何成为一个优秀的开发人员--程序员的修养
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1. Duplicated Code – 重复的代码 2. Long Method -- 过长的方法与函数 3. Large Class -- 过大的类 4. Long Parameter List -- 过长参数列 5. Divergent Change -- 发散式变化 6. Shotgun Surgery -- 霰弹式修改 7. Feature Envy -- 依恋情结 8. Data Clumps – 数据泥团 9. Primitive Obsession – 基本型别偏执 10.Switch Statements 11.Parallel Inheritance Hierarchies – 平行继承体系 zy Class – 冗赘类
6
深入一种语言去编程
• 代码大全 P.67 正如David Gries所言，编程工具不应该 决定你的编程思路，Gries对“在一种语言上编程 (Programming in a language)”和“深入一种语言去编 程(Programming into a language)”做了区分。“在 一种语言上编程”的程序员将他们的思想限制于“语言 直接支持的那些构件”。如果语言工具是初级的，那么 程序员的思想也是初级的。 • “深入一种语言去编程”的程序员首先决定他要表达的 思想是什么，然后决定如何使用特定的语言提供的工具 来表达的这些思想。
13
面向对象的设计原则：
• 单一职责原则(The single responsibility principle)SRP
• 开-闭原则(the open-close principle) OCP • liskov替换原则(the liskov subsititution principle)LSP • 依赖倒置原则(The dependency inversion principle)DIP • 接口分离原则(The interface segregation interface)ISP • 组合/聚合复用原则(Composition/Aggregation Principle)CARP • 迪米特法则 (Law of Demeter)LoD
• •
• 80%的时间在Debug，20%时间在Coding，我们的课题是如 何增加Coding的比例，减小Debug的时间。
9
团队意识
• 每一个人都是在一个团队中工作，你的问题就是团队的 问题。你的荣耀是团队的荣耀，你的失败是团队的失败 。 • 每个Leader应当建立起团队，这是最大的责任。 • 团队意识（在Arcsoft中的故事）
11
代码中的Bad Smell：
13、Speculative Generality – 夸夸其谈未来性 14、Temporary Field – 令人迷惑的暂时值域 15、Message Chains – 过度耦合的消息链 16、Middle Man –中间转手人 17、Inappropriate Intimacy – 过分亲近关系 18、Alternative Classed with Different Interfaces? - 异曲同工的类 19、Incomplete Library Class – 不完美的程序库类 20、Data Class 纯稚的数据类 21、Refused Bequest – 被拒绝的遗赠 22、Comments – 过多的注释
敏捷软件开发
14
Thanks
15
7
防御式编程
• 假设外部的程序代码都是不可靠的，函数应该不因传入 错误数据而被破坏，哪怕是由其他子程序产生的错误数 据。更一般的说，其核心思想是要承认程序都会有问题 ，都需要被修改，聪明的程序员应该根据这一点来编程 。
•
推荐好书：《代码大全》
8
一些经验值
• 每个函数不超过100行，每个函数只承担一项工作，函数 名用定名词形式。一个类不超过1000行。类名和函数名 清晰易懂。 计算人月的一般方法1000 Lines/Month。 80%的问题发生在20%的模块中。
•
4
扎实基本功
Tips： • 一些写代码的好习惯： • 内存哪里分配，哪里释放。 • 指针用完就关闭 （设NULL）。 • 写代码时符合代码规范 • 没有规矩，不成方圆 • 勤于写注解 • 推荐的好书：
C ++ 应用程序性能优化
5
关于程序的构建
• Bug越早发现越好，程序的质量要求起初越严格，越好。 （扁 鹊看病的寓言）
如何成为一个优秀的开发人员ຫໍສະໝຸດ --程序员的修养本次讨论会目标
• 本次讨论只是我这近10年编程经验的总结，希望分享给大 家。
• 本次讨论希望给出我的一些失败经历让大家少走弯路。 • 我的一些经验不一定是正确的，如果觉得有自己的想法请 随时提出来，让我们一起来讨论，所以这次我也称其为交 流会。 • 希望我能抛砖引玉，大家一起讨论，在这里还有其他一些 有很多工作经验的老大们，希望这次也一起分享他们的经 验。 • 有些经验不但能够应用在写程序，也能够应用于其他的领 域。
•
• • • • • •
面向接口编程，而不是面向实现编程。
开发环境一定要稳定，命名规则清晰，系统干干净净，环境不 稳定很容易造成一些极难调试的Bug。 保持设计，代码和思维的一致性。 不要过度设计，简单就是美Simple is Beautiful （Simple is Not Easy）。 随手编译，小步开发，小步执行（一个人同时只能注意7个点 ）。 保证小模块，小片代码的稳定可靠，然后通过每个稳定的小模 块组成大模块。 大模块之间需要持续集成，每天进行Build （参考Martin Fowler: Continuous Integration）。
2
不能达到的目标
• • 能够立即解决手头上的Bug，项目就能顺利开展。 所有的经验照搬就能成为高手， 每个人的个性不同，背 景不同理解也不同，请参考我的经验，消化吸收为自己 的知识和经验。
3
勿在浮沙筑高台—扎实基本功
• 基础知识或者说基本功是很重要的，电脑编程最基础的 知识之一是数据结构及算法。这些知识在大学里都学过 ，但是没有几个可以非常清晰的记起这些书里面的具体 内容，尤其是实际中的应用，更是很少能够关联起来。 但是数据结构及算法却是思考程序的基本，在考虑的程 序的时候数据结构总是起着基础性的作用。 对于C/C++ 语言本身的理解以及编译器，操作系统底层 的理解。很多时候我们只是使用C/C++ 语言，调用它的 一些函数但是很少去思考为什么他是这样运作的以及他 究竟是如何运作的。 （Virtual 函数的例子）
责任心： • 要有责任心，男人要有责任心，记住我们写的代码是发 送到千千万万用户手上的，全球的用户都在使用你的程 序，如果有Bug出现会有巨大的损失。 • 程序员要对自己维护的程序有责任心。Team Leader不但 要对程序负责，还要对你的属下负责，要让他们有东西 可学，能够发展。
10
代码中的Bad Smell：
12
设计中的Bad Smell：
• • • • • • • 僵化性（Rigdity）：设计难于改变。 脆弱性(Fragility):设计易于遭到破坏。 牢固性（Immobility）:设计难于重用。 粘滞性（Viscosity）:难以做正确的事情。 不必要复杂性（Needless Complexity）:过分设计。 不必要的重复性（Needless Repetition）:滥用 ctr+c,ctrl+v 晦涩性（Opacity）:混乱的表达。
6
深入一种语言去编程
• 代码大全 P.67 正如David Gries所言，编程工具不应该 决定你的编程思路，Gries对“在一种语言上编程 (Programming in a language)”和“深入一种语言去编 程(Programming into a language)”做了区分。“在 一种语言上编程”的程序员将他们的思想限制于“语言 直接支持的那些构件”。如果语言工具是初级的，那么 程序员的思想也是初级的。 • “深入一种语言去编程”的程序员首先决定他要表达的 思想是什么，然后决定如何使用特定的语言提供的工具 来表达的这些思想。
13
面向对象的设计原则：
• 单一职责原则(The single responsibility principle)SRP
• 开-闭原则(the open-close principle) OCP • liskov替换原则(the liskov subsititution principle)LSP • 依赖倒置原则(The dependency inversion principle)DIP • 接口分离原则(The interface segregation interface)ISP • 组合/聚合复用原则(Composition/Aggregation Principle)CARP • 迪米特法则 (Law of Demeter)LoD
• •
• 80%的时间在Debug，20%时间在Coding，我们的课题是如 何增加Coding的比例，减小Debug的时间。
9
团队意识
• 每一个人都是在一个团队中工作，你的问题就是团队的 问题。你的荣耀是团队的荣耀，你的失败是团队的失败 。 • 每个Leader应当建立起团队，这是最大的责任。 • 团队意识（在Arcsoft中的故事）
11
代码中的Bad Smell：
13、Speculative Generality – 夸夸其谈未来性 14、Temporary Field – 令人迷惑的暂时值域 15、Message Chains – 过度耦合的消息链 16、Middle Man –中间转手人 17、Inappropriate Intimacy – 过分亲近关系 18、Alternative Classed with Different Interfaces? - 异曲同工的类 19、Incomplete Library Class – 不完美的程序库类 20、Data Class 纯稚的数据类 21、Refused Bequest – 被拒绝的遗赠 22、Comments – 过多的注释
敏捷软件开发
14
Thanks
15
7
防御式编程
• 假设外部的程序代码都是不可靠的，函数应该不因传入 错误数据而被破坏，哪怕是由其他子程序产生的错误数 据。更一般的说，其核心思想是要承认程序都会有问题 ，都需要被修改，聪明的程序员应该根据这一点来编程 。
•
推荐好书：《代码大全》
8
一些经验值
• 每个函数不超过100行，每个函数只承担一项工作，函数 名用定名词形式。一个类不超过1000行。类名和函数名 清晰易懂。 计算人月的一般方法1000 Lines/Month。 80%的问题发生在20%的模块中。
•
4
扎实基本功
Tips： • 一些写代码的好习惯： • 内存哪里分配，哪里释放。 • 指针用完就关闭 （设NULL）。 • 写代码时符合代码规范 • 没有规矩，不成方圆 • 勤于写注解 • 推荐的好书：
C ++ 应用程序性能优化
5
关于程序的构建
• Bug越早发现越好，程序的质量要求起初越严格，越好。 （扁 鹊看病的寓言）
如何成为一个优秀的开发人员ຫໍສະໝຸດ --程序员的修养本次讨论会目标
• 本次讨论只是我这近10年编程经验的总结，希望分享给大 家。
• 本次讨论希望给出我的一些失败经历让大家少走弯路。 • 我的一些经验不一定是正确的，如果觉得有自己的想法请 随时提出来，让我们一起来讨论，所以这次我也称其为交 流会。 • 希望我能抛砖引玉，大家一起讨论，在这里还有其他一些 有很多工作经验的老大们，希望这次也一起分享他们的经 验。 • 有些经验不但能够应用在写程序，也能够应用于其他的领 域。
•
• • • • • •
面向接口编程，而不是面向实现编程。
开发环境一定要稳定，命名规则清晰，系统干干净净，环境不 稳定很容易造成一些极难调试的Bug。 保持设计，代码和思维的一致性。 不要过度设计，简单就是美Simple is Beautiful （Simple is Not Easy）。 随手编译，小步开发，小步执行（一个人同时只能注意7个点 ）。 保证小模块，小片代码的稳定可靠，然后通过每个稳定的小模 块组成大模块。 大模块之间需要持续集成，每天进行Build （参考Martin Fowler: Continuous Integration）。
2
不能达到的目标
• • 能够立即解决手头上的Bug，项目就能顺利开展。 所有的经验照搬就能成为高手， 每个人的个性不同，背 景不同理解也不同，请参考我的经验，消化吸收为自己 的知识和经验。
3
勿在浮沙筑高台—扎实基本功
• 基础知识或者说基本功是很重要的，电脑编程最基础的 知识之一是数据结构及算法。这些知识在大学里都学过 ，但是没有几个可以非常清晰的记起这些书里面的具体 内容，尤其是实际中的应用，更是很少能够关联起来。 但是数据结构及算法却是思考程序的基本，在考虑的程 序的时候数据结构总是起着基础性的作用。 对于C/C++ 语言本身的理解以及编译器，操作系统底层 的理解。很多时候我们只是使用C/C++ 语言，调用它的 一些函数但是很少去思考为什么他是这样运作的以及他 究竟是如何运作的。 （Virtual 函数的例子）
责任心： • 要有责任心，男人要有责任心，记住我们写的代码是发 送到千千万万用户手上的，全球的用户都在使用你的程 序，如果有Bug出现会有巨大的损失。 • 程序员要对自己维护的程序有责任心。Team Leader不但 要对程序负责，还要对你的属下负责，要让他们有东西 可学，能够发展。
10
代码中的Bad Smell：
12
设计中的Bad Smell：
• • • • • • • 僵化性（Rigdity）：设计难于改变。 脆弱性(Fragility):设计易于遭到破坏。 牢固性（Immobility）:设计难于重用。 粘滞性（Viscosity）:难以做正确的事情。 不必要复杂性（Needless Complexity）:过分设计。 不必要的重复性（Needless Repetition）:滥用 ctr+c,ctrl+v 晦涩性（Opacity）:混乱的表达。