从大一到大三，编写过得程序也不少，但这些程序基本都是老师布置的作业，只要实现老师要求的功能就可以，每次写完后都束之高阁，很少去完善，修改这些程序。而在下一次又遇到类似的题目时，都是从头开始写，所以总感觉编写程序很麻烦，老师所说的编程是一件简单的事总是不能体会。而在今年接触到软件设计模式时才突然发现自己以前编写的看似“完美”的程序是多么糟糕，不能复用，不能维护，不能扩展，一旦修改必然是大工程，程序的方方面面都要进行改动，灵活性可见极差。
可复用，可维护，可扩展，灵活性好可以说是软件设计的核心，整个软件设计都是围绕这四个方面进行，无论什么方法，无论什么语言，万变不离其宗。这四点可以说是在我看《大话设计模式》时最先看到的，也是作者最想告诉我们的。
代码无错是否好？这是作者向我们提出的问题，也是我现在所遇到的问题。如同书中的小菜一样，编写完代码就认为完成任务，从来没有为下次的编程积累，也从来没有考虑过那四个要点，这和我们没有接触实际项目也有很大的关联，但从根本上来说还是我们没有去思考，长此以往下去，当我们步入工作岗位，吃亏的还是我们。
书中关于曹操的举例很经典，面对曹丞相不断提出的要求，负责印刷的工匠先是信心满满，随后叫苦不迭，到最后晕厥。对应到现实中来说，工匠就是程序员，曹操就是客户。当客户提出要求后我们总是信心满满的做出来，但客户永远不会满足，他总会提出新的要求，而程序员能做的就是不断的修改代码，直至实现顾客的要求，而在这过程中，对代码的设计极为关键，好的实现方法可以随着时间的推移代码实现越来越快，无论你顾客提出任何要求，我都可以在第一时间满足你，而差的方法，则恰恰相反，随着顾客不断提出要求，软件最终会走向破产，而在顾客眼中，这种程序员就是无能。俗话说的好，没有规矩，不成方圆，而软件设计在我看来就是代码中的规则，在规则的制约下，才能实现可持续发展。
在以往命名变量时我总是怎么简单怎么来，像什么A,B,C什么的，这种命名方法不能说不对，但是不规范，代码的严谨，在我不断的学习中发现它越来越重要。规范化的命名不仅能提高编程效率，同时别人在阅读你的代码的时候思路将会非常清晰。
所有编程初学者都会有这样的问题，就是碰到问题就直觉的用计算机能够理解的逻辑来描述和表达待解决的问题及具体的求解过程。这其实是用计算机的方式去思考，比如计算器这个程序，先要求输入两个数和运算符号，然后根据运算符号判断选择如何运算，得到结果，这本身没有错，但这样的思维却使我们的程序只为了满足实现当前的需求，程序不容易维护，不容易扩展，更不容易复用，从而达不到高质量代码的要求。
编程有一原则，就是用尽可能的方法避免重复。
在软件设计过程中，UML建模展现出了它的重要性，以前在学习UML时总以为这是个鸡肋，食之无味，弃之可惜，毫无半点实用价值，但在学习和学习本书代码过程中，UML建模就如同指路明灯一般，从另一个角度来说，UML建模就相当于为代码的结构画出草图，而后续的编程都是按着这张草图实现具体内容。
通过封装，继承，多态把程序的耦合度降低，开始用设计模式使得程序更加的灵活，容易修改，并且易于复用，这才是面向对象带来的好处，才是面向对象设计的核心。路漫漫其修远兮，我要学习的东西还有很多，目前仅仅是了解了软件设计模式的好处及其对以后发展的重要性，关于如何具体实现软件设计，如何重构代码，还需要时间去学习，需要具体的操作来了解。