讓我們回頭想一想，一直以來，我們都在不停得做項目，趕項目。我們的項目一般是怎么做出來的!每個公司有不同的做法，但是起碼在有些方面還是差不多的。相信從大家開始做項目到現(xiàn)在，做過了很多或大或小的項目，或多或少也有讓自己很引以為豪的成功項目。
每次一有項目，通過幾次會議之后，項目就開始了，先是分配人員，分析一些從客戶那里拿來的需求，然后一些骨干的開發(fā)人員就開始為項目搭架子。于是一個項目就算是進行起來了。談到了為項目搭架子，專業(yè)點說就是做架構了，說是做架構，其實就是把項目按照慣例分割為幾個邏輯層，至于說這個架構好不好，有什么風險，是否可以適應以后的變化，采用的技術的風險和可行性分析，這些很少考慮，為什么呢？因為一般的都是這么開發(fā)的，應該沒有什么大的問題。確實，很多的項目也確實是這樣的開發(fā)的，而且很多也成功了。這些無可厚非，至于說什么標準不標準，是否遵循了什么開發(fā)的原則，沒有多少人在乎，不管怎樣，項目是成功了。項目管理論壇
就這樣，一年又一年，開發(fā)項目，做項目，趕項目，完成項目。漸漸地很多人對做軟件開發(fā)沒有那么大的興趣了：原本以為軟件開發(fā)是一種高智商的活動，現(xiàn)在發(fā)覺有點像是體力活。一年一年，我們?yōu)橐粋€個不同的客戶開發(fā)出一個個不同的系統(tǒng)。
相信很多公司也常常提出很多很“誘人”的口號：通過做大量的項目，積累和開發(fā)通用組件，組件越多，以后開發(fā)就是僅僅只是堆積木了....但是真正的項目中，客戶不停在催，上頭也在催，最后就沒有人顧及什么通用不通用了。項目開發(fā)是越做越累，相信這也是很多開發(fā)人員轉行和轉型的原因之一吧。
項目開發(fā)中，很多的原則我們是很清楚：什么單一職責，依賴反轉，什么可測試性，維護性.....很多時候，在coding的時候，這些原創(chuàng)反倒成了多余，項目最后成為了功能代碼的堆積，特別是在趕項目的過程中，代碼堆積的效果就更加明顯了：只要把功能搞定，其他的以后再說?？梢酝@個“以后再說”就成為了“永不再說”。這個也無可厚非。
那么，什么是企業(yè)級項目呢？ 為一個企業(yè)，機構，客戶公司開發(fā)的項目就算得上是企業(yè)級項目了嗎?一個很大的項目就是企業(yè)級項目嗎?一個小的項目就算不上是企業(yè)級項目?其實，一直以來，我個人也對什么是“企業(yè)級”的概念不是很清晰。只是天天是在這么說。
說到企業(yè)級項目，隨著而來的有很多概念：企業(yè)級架構，企業(yè)級開發(fā)。但是不管怎么說：企業(yè)級這個概念和項目的大小是沒有什么很大的關系的，甚至可以說是幾乎沒有什么關系。其實企業(yè)級項目其實就是一帶著一種“企業(yè)級”的思想來做項目。
在文章中的第一部分，我們到了現(xiàn)在我們做項目的方式：代碼的功能“堆積”。通過這種堆積出來的代碼就僅僅只是用于這一個項目，對于以后其他的項目幾乎是沒有什么用處的，也就說代碼的重用行不夠，而且往往在一個項目中，很多的代碼都是雜七雜八的，很多相似的功能都是各自搞出一套代碼。諸如之類的問題，導致項目越做越累，很多美麗的口號化為泡沫。
企業(yè)級的項目起碼有以下幾個特征：穩(wěn)定性、靈活性、隔離性、重用性、維護性等
相信這些特性大家都不陌生，所以我就不具體的解析。說了這些多，可能大家認為我說的是廢話，屁話，但是有一點可以說的：現(xiàn)在我們開發(fā)項目確實很多的時候忽略了這些東西，因為這個忽略，確實使得項目項目的開發(fā)加快，但是從長期的來看，項目開發(fā)還是越來越累的。如果在開發(fā)的時候，每次帶著一點點這樣的思考，盡量寫出符合那些特性的代碼，慢慢的，一種“企業(yè)級的心智”就慢慢出來了，一個很類似的比喻：在項目中，遇到了一個很難
的技術問題，我們往往花很多的時間來攻克，最后終于搞定。確實這個攻克的過程我們從思維上可以這樣分析：我們思維和問題的答案之間隔了一道墻，我們一次次的嘗試各種解決方案去攻克問題的時候，我們的思維一次次的在撞擊這道墻，最后墻被撞破，我們也得到了問題的解決方案。項目管理者聯(lián)盟
同樣的道理，如果我們在項目中帶著“企業(yè)級”思維，我們就在一點點的撞擊那道“墻”，最后的結果就是:通用的功能被封裝為了通用的組件，為以后的項目的留下積累。
雖然很少人敢說自己有“企業(yè)級的心智”，包括我。但是，不能因為這樣就不去關注，因為帶著這個思想作項目，思想能夠得到一定的提升，而且還真的得到了不少通用的組件，雖然說組件善待完善，但是我們不是已經(jīng)嘗到了些甜頭。