披着盛装的稻草人-- 编程中的随笔

披着盛装的稻草人-- 编程中的随笔

1 不是使用了spring ，hibernate 等企业级产品的框架，我们就是企业级产品了。不是我们采用了新瓶装旧酒的web 2.0 我们就走在技术的前沿了。我门所需要的是一个高性能的，健壮的 产品，是一个可以降低我们实施成本，一个可以树立我们企业品牌的产品。在这里我不得不对我们产品的所谓的架构们产品疑问，Archetectures,what are you doing？

2 在实现框架代码的时候，当你对采用那种实现方式犹豫不决的时，换个角度，想一想如果你是程序员，喜欢怎么这些框架。在实现框架的时候一定要考虑程序员是否能够理解你写框架的思路，除非万不得已不要用一些自以为很高明很巧妙，然而却很晦涩难懂的方法，那样的框架，程序员至少合格的程序员是不愿意使用的。我想程序员和编码工人最大的区别就是程序员不仅要知其然，还要知其所以然。

3 只有在不断实践中，才能激发你不断的求知欲。只有把学到的知识不断的应用道实践中，你才能在学习中得到满足。不要为了学习而学习（学院派，不好听点就是纸上谈兵），而是要从实际问题出发，在解决问题的过程中不断深入，不断总结，所以说，当你离开了编程的第一线，你将失去学习编程知识的欲望。当然如果你愿意，在别的领域还有更广阔的天空，但是请不要总是说自己原来编程怎么怎么，其实你已经被三振出局了。

4 想外行一样思考，想专家一样实践，一本书的名字，虽然书没有看过，但她的名子就已经非常有意思了。这岂不就是我们作需求，和作架构时的座右铭吗？既能象“外行”一样的站在客户的角度思考问题，又能象“专家”一样参与到整个产品的开发和实施当中，在实践中不断提高自我。然而，不幸的是许许多多的所谓的架构师，系统分析员们却正向着相反的方向迈进。“真正”的做到了，象“专家”一样思考，象“外行”一样实践，可悲呀可悲。
5设计做到什么样才叫做到位呢。我想只有真正的开发者才有权利发言。只有有它们才是设计的真正使用者和受害者。因为就我所知和所见，绝大多数设计都是设计者自己的游戏（当然，我可能是井底之蛙了没有见过什么好的设计），程序员所开发往往还是对着原形自己再进行一遍设计，且不说额外增加了多少工作量，浪费了多少时间，就工作质量而言，也是差强人意。毕竟大多数情况下，设计者或称为架构师的在技术方面的经验都更为丰富，对业务的理解也更为深入，另外由一个人进行设计在功能复用，和整体性能方面的考虑也更完整一些。但怎么做才能熊掌和鱼兼得呢？下面我发表一下我个人的看法：
  1 代码就是最好的设计，这句话不是我说的，是 xp开发届 中的一位大牛说的。之所以在这里引用别人的观点，并不是自己是一个xp 的fans，也并不时完全赞同xp 的理论，我只是觉得这句话得太对了，对程序员来说什么设计比代码读起来更亲切呢？。其实设计无非是向开发所着传达设计者的思想，告诉开发者系统需要开什么个对象，具有什么属性和行为，它们之间的调用关系又如何。我们在设计文档中经常使用的方法就是有class 图，协作图，和顺序图对上面所提到的进行描述。然而结果呢，面对这大量的令人畏惧的抽象图表，开发者可选择的也只有是“重整江河待后生了”。想想，这样的设计和代码能够同步吗，这样的设计文档还有什么用呢？所以说与其是这样还不如把设计变成代码，如对象属性可以这直接在代码中体现，方法可以只定义接口，实现方式可以作为代码的注释，向写需求分析用例似的来一步一步说明程序是需要怎样调用。当客户要求设文档的时候，只需要提出javadoc就可以了，而其保证和代码同步。而开发者呢，在开发前需要阅读用例，了解需求，然后在设计者已经搭好的代码框架中进行开发就可以了。如果需要修改的话，不用在去设计文档中更改，只需要修改一下代码注释就可以了，（程序员是比较懒的，不怎么愿意写写文档的）。当然了，让懒惰的程序员能够自觉地写好文档也不是一件容易事，下面也许能给你提供一个好的方法
  2 交差开发能够帮助完成最好的设计文档。
  3 设计者在开发阶段还作什么呢？                 
待续