1 不是使用了spring ，hibernate 等企業級產品的框架，我們就是企業級產品了。不是我們采用了新瓶裝舊酒的web 2.0 我們就走在技術的前沿了。我門所需要的是一個高性能的，健壯的 產品，是一個可以降低我們實施成本，一個可以樹立我們企業品牌的產品。在這里我不得不對我們產品的所謂的架構們產品疑問，Archetectures,what are you doing？
2 在實現框架代碼的時候，當你對采用那種實現方式猶豫不決的時，換個角度，想一想如果你是程序員，喜歡怎么這些框架。在實現框架的時候一定要考慮程序員是否能夠理解你寫框架的思路，除非萬不得已不要用一些自以為很高明很巧妙，然而卻很晦澀難懂的方法，那樣的框架，程序員至少合格的程序員是不愿意使用的。我想程序員和編碼工人最大的區別就是程序員不僅要知其然，還要知其所以然。
3 只有在不斷實踐中，才能激發你不斷的求知欲。只有把學到的知識不斷的應用道實踐中，你才能在學習中得到滿足。不要為了學習而學習（學院派，不好聽點就是紙上談兵），而是要從實際問題出發，在解決問題的過程中不斷深入，不斷總結，所以說，當你離開了編程的第一線，你將失去學習編程知識的欲望。當然如果你愿意，在別的領域還有更廣闊的天空，但是請不要總是說自己原來編程怎么怎么，其實你已經被三振出局了。
4 想外行一樣思考，想專家一樣實踐，一本書的名字，雖然書沒有看過，但她的名子就已經非常有意思了。這豈不就是我們作需求，和作架構時的座右銘嗎？既能象“外行”一樣的站在客戶的角度思考問題，又能象“專家”一樣參與到整個產品的開發和實施當中，在實踐中不斷提高自我。然而，不幸的是許許多多的所謂的架構師，系統分析員們卻正向著相反的方向邁進。“真正”的做到了，象“專家”一樣思考，象“外行”一樣實踐，可悲呀可悲。
5設計做到什么樣才叫做到位呢。我想只有真正的開發者才有權利發言。只有有它們才是設計的真正使用者和受害者。因為就我所知和所見，絕大多數設計都是設計者自己的游戲（當然，我可能是井底之蛙了沒有見過什么好的設計），程序員所開發往往還是對著原形自己再進行一遍設計，且不說額外增加了多少工作量，浪費了多少時間，就工作質量而言，也是差強人意。畢竟大多數情況下，設計者或稱為架構師的在技術方面的經驗都更為豐富，對業務的理解也更為深入，另外由一個人進行設計在功能復用，和整體性能方面的考慮也更完整一些。但怎么做才能熊掌和魚兼得呢？下面我發表一下我個人的看法：
? 1 代碼就是最好的設計，這句話不是我說的，是 xp開發屆 中的一位大牛說的。之所以在這里引用別人的觀點，并不是自己是一個xp 的fans，也并不時完全贊同xp 的理論，我只是覺得這句話得太對了，對程序員來說什么設計比代碼讀起來更親切呢？。其實設計無非是向開發所著傳達設計者的思想，告訴開發者系統需要開什么個對象，具有什么屬性和行為，它們之間的調用關系又如何。我們在設計文檔中經常使用的方法就是有class 圖，協作圖，和順序圖對上面所提到的進行描述。然而結果呢，面對這大量的令人畏懼的抽象圖表，開發者可選擇的也只有是“重整江河待后生了”。想想，這樣的設計和代碼能夠同步嗎，這樣的設計文檔還有什么用呢？所以說與其是這樣還不如把設計變成代碼，如對象屬性可以這直接在代碼中體現，方法可以只定義接口，實現方式可以作為代碼的注釋，向寫需求分析用例似的來一步一步說明程序是需要怎樣調用。當客戶要求設文檔的時候，只需要提出javadoc就可以了，而其保證和代碼同步。而開發者呢，在開發前需要閱讀用例，了解需求，然后在設計者已經搭好的代碼框架中進行開發就可以了。如果需要修改的話，不用在去設計文檔中更改，只需要修改一下代碼注釋就可以了，（程序員是比較懶的，不怎么愿意寫寫文檔的）。當然了，讓懶惰的程序員能夠自覺地寫好文檔也不是一件容易事，下面也許能給你提供一個好的方法
? 2 交差開發能夠幫助完成最好的設計文檔。
? 3 設計者在開發階段還作什么呢？?????????????????
待續???????????????????????????????????????????????????????????????