随便唠唠设计模式与IT新人的成长

最近公司新员工比较多，工作经验都很少，在进行编码时，感觉仍旧和我十多年前刚工作时走一样的路子。对于这样的路子会面对的坎坷，自己深有体会，非常不希望他们进行重复。一方面，希望他们快速成长，也算我对得起他们；另一方面，也不希望由于他们的加入，导致项目质量出现很大的下降。很多时候，找别人的代码缺陷远比自己重新实现一遍痛苦地多。
其实对于设计模式，我并没有专门去学习过，记得只看过一本《道法自然》，但其实也是一知半解，有时候将它与自己目前项目中的模块结合来看，才能够理解其中的某几个模式的意义。其实很多时候，我们的代码中不是没有模式，只是和书本上的有所区别而已。
为了让新员工能够更快的、更好的编写代码，提高个人能力，一方面我对要求他们完成的模块，尽量灌输用某种设计模式的思路来实现模块功能，并具备一定可扩展性的方法，会给他们画一个模块结构图；另一方面要求他们在进行编码前，能够先整理自己的思路，能够把自己的思路用文字或图表达出来，一方面让自己更清晰，另一方面能够拿出来和别人交流。形成习惯后，以后更容易让自己成长为软件设计师，并具备能够进行团队协作的能力。
现在很多人编码能力有，但设计能力基本为零，我觉得是没有尝试和积累造成的。我们公司有些老员工，不知道怎么写设计，一要求他们写设计，就一堆的理由，比如没时间，比如没有模版，或者模版不适合它的项目。我想说的是，没时间是因为他不熟练，我们公司以前有个部门经理，写设计比写代码还快，照着他的设计，基本不需要和他太多交流，就能够写代码，基本上还没有什么问题。你不去实践，永远写不快。就像我们学英语，学汽车，当你熟练后，都是下意识的行为，根本不需要思考，如果你需要思考，那说明你还不熟练。这个需要一个过程，如果你胆怯，懒惰，那结果只能如此，你只能在码工这个级别，无法提升。至于模版，我想说的是，模版只为不会写的人准备的，就是因为你不会写，才需要一个模版帮助你。对我来说，只要你认为可以将你的设计表达清楚的形式，都可以，不需要考虑模版的约束。当然，如果能遵循一些标准，规范，用大家能够看得明白的语言或图形，当然是最好的。（希望IT新人们能够听进去，也许一段时间内你是比较辛苦，艰苦，但未来肯定会受益的）
设计模式中，我觉得重点还是先要理解六大原则（其实我搜索一下，虽然各个资料中都讲六大原则，但其实有七个原则，只不过各自选了其中六个，我还不清楚具体是为什么，很有意思的事，也没有看到谁提过这件事）。设计模式都是在这六个原则基础上的。开始的时候，理解起来是困难的，这需要我们具备一定的实战经验。因此，在进行项目开发过程中，一定要进行结合。或者项目结束后，都需要及时进行分析，总结，重构，提高自己对原则的认识，那你就逐步向设计模式的精髓靠拢了。
在项目开发中，要注意合理使用设计模式。设计模式应该尽量地应用在容易发生变化的地方，它的价值才能更好地体现出来。如果使用在不可能出现变化的地方，那就属于浪费了。另外，我们也未必完全按照设计模式进行开发，更多地会使用一些变体，或者一种平衡。因为设计模式是一种理想模式，它在带来好处的同时，也会带来一些弊端。比如类的数量可能有很大的增长，或者实际的运行效率可能会降低等，为此可能会放弃一些高内聚，低耦合。
设计能力的锤炼，就像一个剑手，先是不会剑招，只会乱舞(初级码工)，时间长了倒也会像模像样，可不会教别人(高级码工)；找了个师傅，从一招一式开始练剑，不能随意(学习设计模式中)；出师后，能够熟练使用剑招与他人PK(初级设计师)；逐渐招式熟练，任意发挥(中级设计师)，有一天，能够创造出新的招式，自成一派(高级设计师)；最后，形成无剑胜有剑，无招胜有招的境界，成化外飞仙(**设计师)。
希望IT新人们能够找到自己的领路人，从一招一式努力学起，不要放弃，把每次跌到都当成成长的阶梯，终有一天会破茧成蝶。
后面再聊聊怎么去做设计吧。
为了更好地指导新人，我努力的去学习设计模式。要想培训他们，我必须先要有所了解，否则培训也不会有太多价值。对我这种高级码工来说，也需要在招式的基础上，才能给别人提供一些有用的帮助，但同时对于自己也是有益的。