这两天读bob大叔的《程序员的职业素养》，感觉作为一个专业的软件开发人员不容易，身上顿时感觉压力山大。

bob大叔认为作为一个专业软件开发必须精通以下几点

1、设计模式。必须能描述GOF书中全部24种模式，同时还要有POSA书中的多数模式的实战经验。

2、设计原则。必须了解SOLID原则，而且要深刻理解组件设计原则。

3、方法。必须理解XP、Scrum、精益、看板、瀑布、结构化分析及结构化设计等。

4、实践。必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程。

5、工件。必须了解如何使用UML图、DFD图、结构图、Petri网络图、状态迁移图表、流程图和决策图。

自我总结：

在bob大叔说的这几点中，我能做到几点呢？认识思想一下，发现大概有这么几点能做到：

1、设计模式，这些年来国内很多关于设计模式的书，读大学时代看《大话设计模式》，只是把大鸟和小菜的对话当做故事书来看，很多设计模式的知识只是看了就忘记，后面工作后买了本《Java与模式》来看，发现其中设计模式的思想挺好的，作者通过讲些中国传统故事来形容和讲述设计模式，通过这本书学习到了不少设计模式的思想，但是老是就忘，后面随着编程经验的增长，了解到设计模式其实就是OO思想和设计原则的产物，设计模式不是去学的，应该是感悟的，是我们程序员通过工作经验去感悟的，感悟设计模式才能掌握设计模式的精髓，才能学会怎么去开发高可扩展性程序，设计模式不是多少种去说的，而且一种怎么开发高扩展高可维护性程序的思想和实践。说来惭愧设计模式现在24种大多数了解其思想，但是现实编程使用的不多。如果要学习重构编程法，设计模式比不可少，福勒的《重构》很多手法就是往设计模式方面靠拢。

2、设计原则SOLID，以下这些是我这几年个人的感悟：

SRP The Single Responsibility Principle单一责任原则：当需要修改某个类的时候原因有且只有一个，让一个类只有一个职责，当这个类需要承当其他类型的责任的时候，就需要分解这个类。这也是bob大叔在《代码整洁之道》关于类这一章说的，让类小尽可能的小，承担的职责单一，这样才能保持代码的整洁性，不会让这个类经常由于其他职责的原因而需要修改，这也是达到关闭修改的方式和手段。

OCP The Open Closed Principle开放封闭原则：对扩展是开放的，而对修改是封闭的。这个原则是诸多面向对象编程原则中最抽象、最难理解的一个。其实这个原则我感觉是OO思想最核心的思想，怎么样提高程序的扩展性而又不用去修改以前的代码，这是我们变成中需要注意的问题，当然很多设计模式就可以达到这种效果，工厂、策略模式等都是为了这些而工作的。

LSP The Liskov Substitution Principle里氏替换原则：所有的子类都可以替换其基类，这个原则其实是对编程语言的要求，只有实现这个原则，我们才能使用多态去创造灵活的程序。

DIP The Dependency Inversion Principle依赖倒置原则：高层模块不应该依赖于低层模块，二者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。其实这些都是为了对扩展开放这个原则服务的，Spring的IOC，策略模式这类东西都通过接口去声明其实现类，达到修改和替换子类不影响现有代码的实现。一切都依赖于接口，程序直接的耦合在于其抽象而不在于其具体实现，bridge模式和抽象工厂就是其经典实现。

ISP The Interface Segregation Principle接口分离原则：不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。这个原则想表达的思想和单一责任原则有点像，一个接口的方法多了，所有的子类都需要去实现它们，当有一天某几个子类需要增加一个方法时候，考虑把它放到接口里面，但是又影响了其他子类，使得其他子类需要实现这个方法，所以接口要尽可能的小。

3、方法：XP、Scrum、精益、看板、瀑布、结构化分析及结构化设计，这些只是对瀑布、Scrum、迭代开发实践过，极限编程（XP）、精益、结构化分析及结构化设计都是了解一些皮毛，这些方面都得努力去学习和实践。

4、实践：测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程，对面向对象设计有所涉及但不深入只能说刚入门，测试驱动开发了解这种思想，只会写简单的单元测试，没有在项目中经历过测试覆盖开发的工作，其他结构化编程、持续集成和结对编程都是了解一点没用深入理解和实践过。

5、使用过UML和流程图，其他几个图都没有用过和了解过。UML图在工作中只有半年多的设计工作中使用过，需要深入理解。

路漫漫其修远兮，吾将上下而求索，学习技术之路很漫长。做一个专业的程序员不容易，需要多加努力，使自己成为一个专业的程序员，成为一个具备职业素养的程序员。