昨天和乙個同事發生爭執，兩個人都堅持自己的觀點，爭執不下，最後情緒很激動，說了些話，場面很尷尬。
回頭想想，雖然自己的觀點沒有錯，但是也應該心平氣和的討論。在這裡向你道歉，為我昨天的態度，如果你能看到的話。
起因是就乙個專案如何開展產生了分歧，這個專案是個小專案，主要是我公司的乙個現有產品為第三方提供乙個查詢和訂貨的介面，業務和採用的技術都比較簡單，目前的問題出在這個專案的參與人員不熟悉現有產品的業務，需要產品開發團隊進行支援，但是產品開發人員需要下週才有時間，而且能提供支援的時間很短，可能只有幾天時間，這就出現了乙個問題，我們這邊專案組需要做什麼事情來準備下週的業務開發工作。
同事的觀點是現在業務不明朗，現在討論業務部分沒有意義，還不如把技術框架搭起來，做乙個簡單技術demo給業務開發人員看，讓他們來把握業務需求，然後模仿技術demo來開發業務。
我的思路正好相反，對於這種小專案，技術方面是非常簡單的，可能的風險出在業務需求的不明朗和將來可能的變化上，我希望專案組先著重把業務需求理順，即使對產品的部分不了解，也可以將產品介面的部分空出來，由業務開發人員來填充。如果我們現在不拿出詳細的需求和設計方案來，下週的時間可能都花費在討論業務需求上了。
到底應該技術先行還是業務先行？
在軟體開發過程中，應該技術先行還是業務先行不能一概而論，我的觀點是：風險大的部分先行
。對於技術複雜性的專案，例如：嵌入式系統、底層開發、框架開發等專案，技術先行是對的，因為要花大量的確定具體的技術方案，這類專案中，如果技術方案出了問題，對專案的影響幾乎是致命的。
對於業務複雜性的專案，例如：mis系統、**這類專案，採用的必然是成熟的技術，除非都是一幫菜鳥開發，技術上的風險應該是很低的，對於這類專案，應該走的路線是，用業務驅動設計，也就是業務先行。
大小端與高位先行 低位先行
近期學習嵌入式過程中混淆了大小端和高位先行 低位先行的區別，現總結如下。首先解釋大端小端模式。大端模式即高位位元組存放在低位址中，低位位元組存放在高位址中 小端模式相反，高位位元組存放在高位址中，低位位元組存放在低位址中。用圖表示更加容易理解。如下圖，我們將資料0x01020304分別按照大端模式和...
設計先行，編碼在後
當晚，太太跟我交流要設計的工具很多東西沒想清楚，沒法寫 方向感不強，於是我們花了些時間，把設計要點整理到紙上 請忽略這個廣告紙 因為我知道，今晚不搞清楚這個事情，想看個電影都難咯，於是這篇文章，我花了些時間思考和寫出來，幾分鐘可以讀完。現實生活中房子，大多數開發商交樓的時候已經是帶裝修，業主索取設計...
進軍SharePoint,資料先行
最近計畫學習sharepoint，收集到的部分資料，願與大家共享，希望對大家有用，讓我們共同進步！了解sharepoint sharepoint portal server軟體概述 介紹一下sharepoint 實現sharepoint的無限潛力 wss和sps2003的區別 sharepoint的...