軟體公司生存的一些想法

1. 如果你選擇用某一種技術是為了這個產品更好賣，那基本上可以說你不上道。
2. 一個開發模式或者設計模式，是否適合引入到你的項目中，也不取決於這個設計模式多先進，而是取決於使用這些模式的客戶，也就是開發人員是否能夠理解和掌握它們。如果不行，那就不是一個合適的技術。這個時候你有幾個選擇：1、教育你的員工；2、換一批員工；3、放棄這個技術。對於一個新公司來說，可見選項1和2成本都是非常高的，而選擇3也許會讓你很不爽，但是卻是一個較為可行的方案。
3. 企業級架構的部署和應用具有極高的風險成本。很多時候，對於一個創業階段的小公司，其生存能力取決於他的應變能力和執行能力。打一個比方說，某天突然中國移動和你達成一個合作意向，前提條件是你能夠提供該服務。這種合作背後有兩個潛在的邏輯：a)很可能某天突然有第三家插進來，比你更早提供該服務，於是正式的合作合約就泡湯了；b)更重要的是，即使你提供了該服務，出於其他客觀原因，最終該意向還是很有可能不了了之。於是，你可能辛辛苦苦做出來的東西，最後卻是毫無作用。要知道，龐大的東西如果毫無作用，反而可能會是一種負擔，這個時候就會很尷尬：拆除他還是不拆除？通過做Branch的方式也許在面對一個這樣的合作還有可能，如果同時不週期性進行多重專案，用Branch來避免拆除問題就比較不切實際了；
4. 企業級架構，甚至設計模式對於很多開發人員來說仍然是一種天書。千萬不要以為開發人員都會像那些搞出設計模式或者TDD開發模式的Crowdsourced Security Testing那樣聰明，如果真那樣的話恐怕你我之間都是比爾蓋茨了。根據我的經驗，以一個小企業所能夠找到開發人員來說，能夠理解這些東西的人不會超過33%。也就是說，你在這裡面如果應用這些設計模式、開發模式，無非就是面對如下兩個結果：a)那66%的人需要你去告訴他你寫的到底是什麼（對於他們來說，你在寫天書）；b)那66%的人會乾脆繞過你的代碼，重新寫一堆很爛的代碼，這種情況居多。這實在不是一件什麼好事，比如你會看到一堆噁心你心情的代碼。此外你可以想象原本好好的MVC代碼，一層層剝離的很好，沒過一段時間可能就會有人直接在V上面寫一堆的SQL語句和商務邏輯。我在這個時候寧願沒有MVC結構，這樣我就不會浪費時間調試M層明明正確的Sql和C層明明正確的商務邏輯了，更不會搞不清楚他到底什麼地方亂寫一氣，什麼地方有突然調用了底層的代碼了。當然，這是最糟糕的情況。在最好的情況下，隨著時間的推移，亂寫一氣的代碼總會不斷的堆積並占絕對多數。也就是說，你的努力最終都是白費的。