天天看點

我心目中的商用化開發和工程化開發

理論部分

1. 商務程式員是什麼?商務程式員和老師和學生的差別是?他們和工程的關系是什麼?

商務程式員是解決實際問題的人。用的時間,人力,物力盡可能的少。隻要求解決問題并且在問題裡面很全面,在問題外面很簡潔。

模 型

    打個簡單的比分商務程式員,老師,學生,客戶。好比參加大學開卷考試,答對得分,打錯倒扣分。客戶是命題人,試卷是計算機,老師是全範圍研究怎麼命題和怎麼解題的和過去有哪些解,并形成理論,學生是學習老師的理論,商務程式員是快速解題的。現在開始打比方,現在客戶們各出了一道題目,一張試卷完成了。

闡 述

老師們往往有查閱以往參考答案的權限,偶爾也跳進來參與解題,不過做起題目來了就不管你誰誰了,隻有題目做不錯的出來,能不能解,不會出錯由計算機說了算,客戶隻關心這個題解沒解出來,是不是按照他的要求解的,産品長相很差影響到客戶的心情的要扣分的,連續做錯也是要倒扣分的,如果嚴重了可能答卷的資格也沒有了。

解得是否完備嚴密,分類讨論的是否都讨論了計算機和客戶說了算,商務程式員隻關心如何快速解題。微軟的讨好使用者政策在一定範圍内也能取得很好的“好印象”分。

在答題時間内做完了檢查了直接做下一道,在考試的時候題目是很多的,基本上都答不完,能做一道是一道,做得越快可以越早做下面的題目和提前交卷以及準備下面的考試。

一張試卷,我們要的是高分而不是一道題兩道題解得過于漂亮,從長遠來看漂亮的答題是可以友善大家查卷的。

至于你答題的方法是否好,答題用的紙的面積是否小客戶不關心,計算機也就關心一點點。但是這個對你來說就是全部了,如何多快好省的解題将決定的未來的基礎。

好比數學考試上面你做出了一道數學題,使用函數做的、還是用微積分做的或者其他的理論定理都可以,能不能得滿分取決于你是否各個情況都讨論到了。

如果解一道題花費了過多的精力、時間對後面的答題無疑是不利的。初級階段是做出來。後面能夠移植、歸納、加速就是決定你将來的答題品質。這個就是商業化開發和工程化開發——一環套這一環。

照着這個思路和模型想大家都不陌生。你已經具備了商業化和工程化的思維和意識形态。

2.商務程式員怎麼樣?

第一要義是解決問題,核心是以客戶為本,基本要求是快速開發,根本方法是統籌兼顧。

第一要義,也就是關鍵,是解決問題。所有的東西都要圍繞解決問題來完成。

問題沒有解決基本上一切都是零

,原因很簡單,不解決問題就不會給錢^_^,考卷上面的一個題,如果做了,沒做出來無疑浪費了時間。而開發上一個月不吃飯公司的人都餓死了。

客戶的需求就是核心,客戶要求這樣就是這樣那樣就是那樣。好比上面的評卷子。

你寫了答案是你的,給多少分,給多給少命題人說了算。另一方面計算機參與改題,是以它的情況你要摸清楚。一個不是問題的問題也會造就大麻煩。

因為你是為了别人打工。

要求是快速開發。能夠用通解的用通解,不能用通解的用特解,還有通解+特解甚至你答第五題來個由第二題的第三行到第十行的結論得~!@#你複制過來就可以。

而一個團隊的生存在于能否比其他團隊更快速的開發出項目來,這個是殘酷的鬥争。

政治經濟學上認為相同勞動時間複雜勞動的報酬是簡單報酬的數倍。簡單來說就是你做出了一道難題花的時間如果和别人做的簡單的題目差不多那麼就你的得分就高。

高學曆将獲得高視野,高手段達到高目标。不管怎麼樣都是要在規定的時間内搶分。一切的一切都來源于平時的積累。

前面說了這麼多就是要花最小的力解決盡可能多的問題。要懂得平衡之道和舍棄之道。快速解題和快速程式設計差不多。是做還是換要有一杆秤。

3.如何成為商務程式員?

這個問題展開來講就很廣了。至于是術還是道的問題我覺得應該都有。就一道題而言比起一大堆的理論我更關心如何做出來的。就一張卷子來說我關心用到了哪些,哪些需要再歸納成定理,為了下次快速解題。道是第一要義是核心是基本要求是根本方法。有了架構還要術來充實。平時要養成準備術和歸納道的好習慣。一切為了實用,一切為了快速解題。

3.1幾點誤區和已有經驗

1)有人說:我去念個博士出來解題該快了吧?

你怎麼不去念個教授出來再解題呢?我們是解決問題不是比誰念書念得好。理論搞得好。對一般問題來說隻有0和1的差別。實踐是檢驗的唯一标準。過多的前進無疑是無用功。如何加速怎樣加速大家見仁見智。

2)為何要規範?在商業開發中如何避免我的缺點?

忘記說了,考試不是一個人的考試而是一群人的。可能分工是你做135他做246,也可能你們一看就是兩種情況a=0和a≠0你們分工合作.但是遇到了重要的地方他一看這個小問題你解決了,來個由第一題的第8到14行的結論得。結果寫到了計算機裡面出了問題,編譯通不過。無疑浪費了你們兩個的時間。如果他不看你的解的過程自己寫又無疑降低了效率。很可能你們考完了都挂了~

解題寫得越規範越好,有的時候甚至保守一點。規範是寫給自己和别人用的。團隊就像一個人的手指頭。雖然各有特點作為一個整體共同完任務。IBM有很大的代碼庫,要用直接搜尋然後拿來一改就可以用。這個就是規範。解題就是要揚長避短合理分工。規範之後開發速度将大規模提升,将很免去一些認識和調試的時間。

3)為何要分類讨論?優缺點又是什麼?

分類讨論使大家看得明白。說白了就是尋求穩定。其實分類讨論之後全局改起來巨麻煩,而且有極大可能降低系統性能。逐漸求精是個思想,把缺點控制在小的範圍内是可行的。

你也可以不讨論直接求全解,那很容易就看得一團糟。之後不隻是别人就是你自己也不容易看明白。計算機裡面就是結構化,面向對象,子產品化和透明化。我這裡取最廣義的概念。說白了就是分工明确,層次清晰,協同完成,内部無關。

我在這裡隻說兩個模型。一個是計算機網絡的tcp/ip模型,一個是OSI模型。前者是四個,後者是七個,老師教我們的時候說了你說七層也可以,我說計算機網絡有兩百層也可以隻要能夠拿來用,分層過粗不容易了解概念不明确,分層過細就更不容易了解了。

事實是TCP/IP因為發展的廣泛是以成為了實際的标準,上面的三個是自己的,在最底下是不分層的,原因是各個國家各個廠商有了自己的标準要統一起來不太可能比如對與資料傳輸歐洲有E1标準北美有T1标準。上層統一定義接口供他們使用,而下層的使用上層毫不關心。是以靈活TCP/IP成為了實際的标準。而OSI考慮完整和全面,是以有的滞後于發展或者有的技術超前于發展而無法實作。

4)更高角度的思考

   蜘蛛人上面有句話:能力越大責任越大。對應的中國有居廟堂之高則憂其民,處江湖之遠則憂其君。底層的朋友要考慮上層的東西,一切為了出來。上層的朋友一切為了實用考慮底層的東西。都是為了掙錢,都是為了和客戶打交道。表面透明實則不然。有的時候一些細節處理的疏忽是為了高效的程式設計。比如10^16+1=10^16

同時預見性的無法忽視的錯誤需要避免,越早解決代價越小,後期的大錯誤往往是緻命的。問題特征往往來源于以前的項目裡面,需要多做分析。

比如微軟就稱自己是做軟體測試而不是做軟體開發的。開發中有70%的時間用于測試而編碼隻占到了很少的時間。可否把70%的時間減少?我看是可以的,因為在一個團隊裡面程式設計的始終是那幾個人那幾杆槍。像對待解一樣通用錯誤的通用檢測特殊錯誤的專人檢查這樣也算是流水線将減少時間。

更好的方法是逐漸将好的東西養成習慣而習慣是從不習慣開始的。

5)如何對待理論學習和方法?

誰都知道學得越多越好。就像第一問中的博士一樣,但是沒有誰能充分學習。書到用時方恨少。理論學習越高深度越高,解決問題的思路可能越透徹有益無害但是理論的學習也是要時間的。我們考研的英語卷子不說我們做,就是命題人在規定的時間内也不一定做全對。更不要說各個 高校的 老師、外語系的人。不是說英語好就可以做的對,程式開發也是這樣。沒有無敵的教材隻有無敵的頭腦。聞道有先後,專攻需具體。

6)程式設計之外

基本上我們能列舉出來的市面現存的作業系統都比微軟的好,但是市場呢?還是windows的。下面是一個SUN的Solaris和微軟的windows的例子。

比如把C槽的東西複制到F盤去。CTRL+A,CTRL+C,CTRL+V不一會就會出現個顯示時間的條條出來,如果沒有,重新整理一下也就出來了。雖然那個時間是不可靠的,但有比沒有好。在Solaris作業系統中你複制之後沒反應。好了彈出來至于他搞沒搞,啥時候搞得你是不清楚的,使用者不能等待。是以比windows優秀的多的作業系統沒有走進千家萬戶。功夫還要下到位,就如何讨好使用者來說微軟下了很多功夫,Sun的倒塌也能從這裡看到端倪。

貪吃蛇是很簡單的遊戲,現在有了網絡貪吃蛇,如果能夠分析出潛在的需求項目将獲得成功。

有的時候我們除了在程式設計上需要動腦筋程式設計之外也要下功夫。這樣才能高效優質的赢得市場。

了解商用開發很簡單。就是寫一張你寫不完的數學卷子。大學就是為了考試。商業化開發就是為了快速解題。工程化開發就是為了每個題目都是滿分。

附件一:屬于實習版,也有一點我程式設計之外的想法,和商業開發無關,也不在本文讨論的範圍之内,更像做系列産品。

http://student.csdn.net/space.php?uid=52770&do=blog&id=18523