先向各位拜個晚年。
今年過年期間都在想DRP的事，很多朋友也聯系我，討論技術問題的、謀求合作的、分析行業前景的、讓我提供源碼和數據庫的都有。再次謝謝朋友們的關心。目前來說，在修改系統bug的同時，我打算重新找一份工作，畢竟在能力轉換成財富之前，生活還是要繼續。
Winform or WPF：
今天在QQ上和一位山東的朋友聊了會，其中聊到BS和CS的老生常談，說道有些功能BS不好實現。我認為兩個事物孰優孰劣需要放在特定場景中才能比較，關於這兩者的區別谷歌一下即可，我就不分析了，徒惹板磚。其實同樣是CS，具體的UI框架也包括很多，在.NET中主要就是winform和wpf，前幾天就看到一篇文章關於開發WPF的一些感想，作者提出：為什么到現在都沒有客戶端的WPF系統？在如今WEB化和移動化大行其道的情況下，windows桌面程序開發的價值又有幾何？說實話，我也心存同這位博主一樣的疑慮。對於這兩個問題，每個人都有自己的看法。我認為相似的幾個技術有個先來后到的“優先級”，試想，假如wpf和winform的出現時間換一下，再擴展一下思路，假如當初C#和Java這兩種語言同時出現在大伙面前，假如HTML遵循XAML的語法……世界會是什么樣子？所謂的市場占有率通常並不能比較出技術間的優劣（沒有貶低誰的意思），只能說聲：抱歉，哥比你先到。
單純對於行業軟件而言，在winform和wpf中選擇，我偏向於wpf。如果非得選擇winform也可以，不過最好給我提供一個winform實現框架，這個框架需要包含以下三點功能：
- 支持源數據更改通知反饋；
- 支持路由的Command；
- 易用的界面設計功能；
架構設計：
工作多年，接觸過許多編碼界的朋友，其中一些高手對OO的理解可謂已入化境，沒事就抽個接口玩玩，調試他們程序的時候永遠只能看到黃色小箭頭在浩瀚的代碼海面上跳躍，要想一探究竟，對我這種菜鳥來說只有淹死的份。記得我剛參加工作那會，參與開發一個簡單的會議管理軟件，項目經理給我展示項目架構，說這是當時最流行的架構設計。我猛地一瞅，頓時有種膜拜的趕腳——那龐大的項目，那眾多的類庫，那抽象，那反射，那配置，一看就很高級喲，我估計沒十年八年是理解不了的，差點還動了轉行的念頭。項目經理意味深長地拍着我的肩膀，說慢慢來，會明白的。可是我最終也沒能明白。
我不明白的是為什么數據層要有個接口，他們跟我說為了支持多數據庫，雖然現在只用到SqlServer，保不齊百年之后要切換到Oracle；我不明白的是為什么業務邏輯層也要接口，他們跟我說可能客戶會經常改變需求，雖然需求改變常常導致改變接口本身，不過這是OO的原則，你納悶說明你理解的還不夠深；我不明白的是為什么要用工廠方法、抽象工廠方法，他們說這叫統一標准，雖然大部分接口都沒有第二個實現類；我不明白的是為什么這看似高級的架構沒有給開發者和用戶帶來良好的體驗，他們說加班還不夠；……
一年以后，我離開我的第一家公司。跟同事們告別的時候，我們都看到了各自心中的郁悶，這是長期作戰的結果，而敵人是由我們自己制造出來的。
我還碰到過另一個極端，不是說三層么，做啥項目都只建三個類庫，對應數據層、邏輯層、UI層，最多加個實體類庫。你想要個通用類庫，門都沒有。
后來，我把QQ簽名改成“設計，是一種美，就像蓋大樓，如果每座房屋都是千篇一律，那么也就不存在架構師了。”，這是從某博文上復制下來的。雖然這句話並非那篇文章的重點，不過當時看到這句話的時候，我感覺到了共鳴，壓抑已久的心靈終於得到解放，忍不住出門打了三斤白酒站在陽台就喝了起來。
開發效率：
原本我打算連着生產系統一塊開發，后來想說先把分銷穩定了再說。開發這套系統，至今經歷了5個半月。想起當初我的4人團隊一個半拉子系統都要搞幾年，我驚異於自己的效率。本系統完全從0開始，所采用的框架也非我原本熟悉的，只不過在業務需求上借鑒了行業經驗，但也增加了很多實用功能。若一個普通團隊開發，我估計要在相同時間內完成幾乎不可能（何謂普通？並不大的軟件公司的項目團隊）。也許你不會贊同我的觀點，那是你沒有經歷過文檔流於形式的“趕鴨子上架開發模式”。
這套系統首先大規模的系統重構就有4次，這對我來說，也就咬咬牙的事，但對一個團隊意味着繁瑣的溝通、重疊工作的分配、不滿情緒的滋生、冒出的各種bug、疲勞的重復測試、責任問題、文檔更新等等，以及上述負面效應的多次“迭代”。
對於分配給A的任務，你不能保證A完全按照你的想法來，即使功能實現了，你也得檢查看看有么有影響運行效率的語句，特別是對能力不足的成員，尤其提心吊膽。在實現難點或功能點較多的模塊，通常難以在一開始就明確知道采用何種方式，往往花四天時間構思，兩天時間編碼，在編碼過程中會重構個好幾次，這需要編碼者有足夠勝任該項任務的能力（而一個普通團隊中很難有幾個相當優秀的程序員，而技術主管又不能事事親力親為），有時候還得其它模塊配合，這又牽扯出上述情況了。當某處需求實現了，盡管代碼看上去並不十分完美，為了“顧全大局”，也就這樣吧，甚至優良代碼要向劣質代碼讓步。
若有原成員離開或新成員加入，稀奇古怪的編碼風格會讓相關成員抓狂，編碼風格可以強制規范，但代碼邏輯時不常地出現理解偏差。當系統終於成型，呈現出來的很可能是個臃腫的胖子，因為每個開發人員按自己的需求寫的幫助類代碼，很多都是重復的，更不用說隱藏在各處的私有可抽離代碼。這無疑增加了后期維護的成本。
團隊開發過程中，有規范的文檔會好很多，此時文檔就相當於整個團隊的大腦負責信息存儲的存儲區，而成員間的溝通賦予了新的含義，那就是團隊思想的源泉。不過我並不認為開發文檔（如詳設）在一開始就必須存在，而是在項目架構等基本上穩定了，再着手編寫。說回來，現在有多少公司的文檔作為其原本的意義而存在呢？
創業（？）：
老實說我這還談不上創業二字，更多的是區別於正常上班的另一種工作方式。若以后能靠這賺點錢更好，否則就當提升下自己的開發能力。我並非做事目的性明確的人，所做的事只是我認為做了並無害處。大多數人都有個創業夢，特別是在IT界，真正去做的寥寥無幾；創業並且小有成就的，寥寥無幾；創業並且大展宏圖的，寥寥無幾。這些都不是我的目的，我的目的很簡單，多賺點錢，然后做我真正喜歡做的事。
我一直以為我不是能堅持長久的人，特別是獨自一人完成一個產品，特別是在一個結婚生子都顯略晚的年紀。車子賣了，存款花了，即使通情達理的父母不會埋怨，即使有熱心的兄弟幫着給我打氣，卻在無形中加重了我心中的負擔。畢竟代碼的世界里我能依靠的只有自己，每天對着顯示器敲着一個個代碼，偶爾想到迷霧重重的前景，我就想說：算了吧，安耽地找份工作也有不錯的收入，何必逞強呢，一個人難道能比一個團隊開發出更好的作品嗎。孩提時代偉大的理想，此刻變成對社會幾乎無用的“賺錢”二字，百年之后，誰又記得我呢？有時思想如同不小心打開的潘多拉魔盒，負面的情緒傾瀉而出，讓人極為沮喪。
令我欣慰的是，我完成了計划的第一步。沒有半途而廢並最終完成一個可用的產品，感覺挺好。
最后貼個系統截圖以供觀賞，截圖中的數據為測試數據，圖片摘自互聯網，所示功能使用MVVM模式開發，若采用Winform，沒有引入特殊擴展框架的話，估計至少三倍工作量還不一定能完成吧。
轉載請注明本文出處：http://www.cnblogs.com/newton/archive/2013/01/20/2868272.html