❶ asp.net 編程有哪些重要的技術要點
高內聚低耦合，代碼優化清晰。面向對象的掌握其含義。多態，封裝，繼承
❷ 與新手分享為什麼要學習.NET
為什麼微軟設計和發布 .NET? 相信大多數人都會認為微軟推出 .NET 是為了與 java 正面競爭，不可否認這是原因之一，但是如果你回顧 Windows 下微軟技術的發展歷史，你就會發現，幾經歲月的微軟技術已經顯得越來越壅腫 , 無論在易用性、開發效率和安全性上都積累了諸多詬病，很多技術都是在需求的驅動下誕生的，都缺乏整體規劃，微軟迫切地需要對其所有的技術進行一次重構，現在就讓我們一起回顧一下微軟技術的發展歷史，來認識 .NET 技術誕生的必要性：
在 .NET 之前， Windows 平台下的編程技術主要是 Win32 SDK, ASP,COM, DCOM, ADO 等技術，這些技術在後來也有了一個統一的名字叫 Windows DNA ，和 .NET 是一系列技術的集合一樣， Windows DNA 是這些一系列技術的統稱，為了加快軟體開發，微軟為 C++ 程序員提供了 VC/MFC 開發工具，為 Basic 程序員 提供了 VB 等，由於語言本身存在的先天差異 ( 例如數據類型不相同，內存管理也不同等等 ) ，微軟沒有辦法做到 VB 和 VC 程序引用同一套類庫，所以微軟為每一種語言都提供其單獨的 Runtime 類庫、單獨的資料庫類，不同的 GUI 構建方式等。由於類庫的大部分功能都基本相同，因此，為不同的語言設計和維護不同的類庫是一件很沒有效率的事情。（後註： .NET 是所有 的 .NET 語言都引用同一套 .NET Framework ）
值得一提的是， Borland 公司的 C++ Builder 與 Delphi 共同使用的是同一套類庫，這個類庫就是 VCL ，為什麼 Borland 做到兩個不同的語言引用同一套類庫呢？ 因為 Borland 擁有 Pascal, Borland 通過修改編譯器來修改 Pascal 語言使得它在數據類型和內存管理方面與 C++ 相擬，使得用這兩種語言編譯出來的程序能二進制兼容。雖然微軟擁有 Basic, 但是 Basic 的先天優勢是易學易用，微軟無意去修改 Basic 使得 Basic 變得復雜。
微軟使用 COM 來解決語言間的組件重用問題，並提出組件編程模型的概念， COM 的基本原理是通過定義一些編程契約，使得按照這些契約編寫出來的組件 ( 以 dll/exe 的形式存在 ) 可以跨語言和跨平台地進行重用。
在 COM 推出之前，微軟和 Borland 在開發工具的戰場上斗得你死我活，而微軟憑靠著 OLE 技術贏得了重要的一役勝利，微軟在 OLE 的基礎上創造了 COM 技術，並大幅地使用 COM 技術來構建 Windows 下的軟體組件，其中， ADO 就是一個常用 COM 組件，不同的編程語言都可以調用 ADO 來訪問和操 作資料庫，因此， ASP 程序員會驚呀地發現，他用 ADO 編寫的訪問資料庫的代碼看起來與 VC 程序員訪問資料庫的代碼是如此的相擬。
通過對微軟技術歷史的分析，可以發現 COM 的產生是一個偶然，當時微軟為了對搞 Apple 的文件技術，從而推出 OLE(Object Linking and Embedding ，對象連接與嵌入 ) ， OLE 的目的是讓文件可以即時編輯，例如 Word 文檔可以嵌到 Excel 中編輯， Excel 表格也可以嵌到 Word 中編輯， OLE 的成功使得微軟察覺到跨語言組件重用的重要性，於是微軟從 OLE 中抽取出一些重要的特性，並實現了 COM ，然後再用 COM 重寫了 OLE 組件，所以可以說， COM 是在缺乏整體規劃的情況下設計出來的，加上 OLE 龐大和復雜（當年 Borland 與微軟的開發工具大戰， Borland 在 OLE 上面吃了大虧），再加上隨著需求的不斷增加和修補， COM 並不易用，但這並不防止 COM 組件的成功，在 .NET 之前， COM 已經成為 Windows 下重要的組件編程技術，很多重要的組件 ( 如 ADO, ActiveX 組件 ) 等都是基於 COM 技術開發的，當時業界較流行的做法是 VC 程序員編寫 COM 組件，然後由 VB 程序員或 ASP 程序員來將 COM 組件組裝成提供給最終用戶的軟體產品， .NET 之前， COM 就是這樣很好地解決了多種語言之間的組件重用問題。
以 Win32 SDK, COM 技術基礎組成的 Windows DNA 技術經歷了整個 90 年代的發展，期間根據市場需求不斷的修修補補，已經非常壅腫，且積累了諸多詬病，某些技術過於復雜，開發效率低等，這些問題都成為了設計 .NET 的背景，下面我試圖羅列出一些主要需要改進的地方 ( 列個大概，肯定不全，希望大家幫忙補充 ) ：
1) COM 並不支持面向對象的諸多特性，例如不支持介面、繼承等，在面向對象流行的今天已顯得非常落後，目前大部分的生產力工具都是以面向對象為基礎的（例如 UML 建模工具）。
2) 編寫 COM 組件對於新手來說比較復雜，必須要遵守一些較為繁瑣的規則，安裝和部署需要修改注冊表，不便於測試和部署。
3) COM 組件基於 exe/dll 的形式存在，而 dll 是 Windows 下重要的組件存在形式，但是 dll 也成了 Windows 下軟體不穩定的罪魁禍首，原因 是大部分主要的 dll 都存放在一個統一的目錄： Windows/System32 ，當安裝一個新軟體或者升級軟體到新版本時，新的 dll 會覆蓋舊的 dll 文件，從而可能會導致現有的軟體無法工作或者不穩定，這是大名鼎 鼎 的Dll Hell (Dll 地獄 ).
4) COM 組件雖然可以跨語言進行調用，但是沒有辦法進行跨語言調試，例如在 VB 中調用 VC 編寫的 COM 組件時，這個組件不能在 VB 中調試，造成軟體調試困難。
5) 安全性方面，軟體沒有辦法知道自已所引用的組件是否已被非法修改，安全控制也只停留在用戶級別的控制上，沒有辦法做到代碼級別上的安全控制，例如沒有辦法做到限制某個組件只能讀取文件內容，但不能將內容寫入文件。
隨著信息化的需求不斷演進，以及 JAVA 的流行，以及雲計算等一些概念的提出，微軟迫切需要修改自身的技術來適合市場的需求，顯然，微軟有兩種解決方案：
1) 繼續對 Windows DNA 的相關技術進行修修補補，在上面增加新功能，改進並修復錯誤。
2) 重新規劃一套新技術，解決現有技術存在的問題。
微軟選擇了第 2 種方案，即重新規劃一套新技術，在微軟內部，新技術作為 COM 的更新版本被命名為 COM 2.0 （來源於 <<.NET 本質論 >> 一書），後來才改名為 CLR, 和 Windows DNA 以 COM 技術為基礎一樣， .NET 以 CLR為基礎 ，而 CLR 顯然可以看作是經過重構的、新版本的 COM ，只是新版本的 COM 比它的舊版本增強太大從而使 得它應該換個名字。微軟用 .NET 這個名字來代替 Windows DNA ，來表示一系列新技術的統稱 ( 其實就是一個商標 ) ，至於為什麼使用 .NET 這個名字， NET 是網路的意思，微軟使用 .NET 這個名字是預見未來將是網路應用、分布式計算的天下，而微軟，已經做好了准備。
.NET 設計的首要目標，就是要解決舊技術中的諸多問題，針對上面對舊技術需要改進的一些問題，我們再回頭來看看 .NET 是如何改進這些問題的：
1) 引入中間語言技術，程序在編譯後產出中間語言而不是機器碼，在中間語言這一層直接支持面向對象技術，並定義常用數據類型，最大限度地縮短不同編程語言之間 的差異，使得不同編程語言編寫的代碼可以無縫集成起來，例如 VB 編寫的類可以在 C# 中繼承、創建實例等等，這在以前是無法想像的。
2) 引用程序集的概念來解決 dll 地獄問題，安裝新程序集不需要修改注冊表，部署簡單，不同的程序集版本可以同時存在，有趣的是，這個特性使得微軟在推 出 .NET 新版本時，不用頭痛去考慮舊 .NET 程序的兼容 (.NET 程序員也因為這個原因而對微軟抱有不滿 ) ，因為 .NET 的新舊類庫可以相互共存，因此你的程序可以引用舊版本的 .NET 類庫中的一部分，同時還可以引用新版 本 .NET 類庫的另一部分，當然，這樣的話，最終用戶需要同時安裝兩個版本的 .NET Framework 。
3) 引入 Click One 技術使軟體的安裝和更新更簡便 。
4) 支持代碼級的安全控制。
5) 中間語言技術使得跨平台成為可能，目前 MONE 項目已使得 .NET 程序可以運行在 Linux 下，甚至 iPhone 手機上。
總之， .NET 技術是微軟技術一次全面的重構，所以要在 Windows 下進行程序開發，學習 .NET 是大勢所趨，雖然舊的技術 (COM/MFC 等 ) 還將存活一段時間，但微軟保留這些技術更多是為了兼容舊的程序， Windows 下要使用新的技術和新的功能，首選還是 .NET
❸ 學好.net web開發必須要掌握哪些技術
一樓說的太范泛了，具體說，語言上要掌握C#，SQL，javascript,網頁製作上，要掌握html,css,silverlight,美工上要掌握photoshop,flash在.net上要掌握的東西就多了，如三層架構與工廠模式，緩存與依賴，全球化與本地化，委託與事件等諸多.net編程技術內涵，還有如頁面優化，性能優化等開發者進階技術等等。
❹ 如何提高.net的編程能力
呵你可以多上CSND 或者說CNBLOGS多看看別人寫的代碼啊!還有平時有空自個也要多做點項目啊!實踐其實還是最重的!在做的過程中發現問題解決問題!嘿我也是學NET的!有空可以到我的網路空間多看看的!裡面有寫的很多平時遇到的問題還有功能的實現的
❺ 怎樣才能提高編程技術
1. 扎實的基礎。數據結構、離散數學、編譯原理，這些是所有計算機科學的基礎，如果不掌握他們，很難寫出高水平的程序。學計算機專業的人比學其他專業的人更能寫出高質量的軟體。程序人人都會寫，但當發現寫到一定程度很難再提高的時候，就應該想想是不是要回過頭來學學這些最基本的理論。不要一開始就去學OOP，即使再精通OOP，遇到一些基本演算法的時候可能也會束手無策。
2. 豐富的想像力。不要拘泥於固定的思維方式，遇到問題的時候要多想幾種解決問題的方案，試試別人從沒想過的方法。豐富的想像力是建立在豐富的知識的基礎上，除計算機以外，多涉獵其他的學科，比如天文、物理、數學等等。另外，多看科幻電影也是一個很好的途徑。
3. 最簡單的是最好的。這也許是所有科學都遵循的一條准則，如此復雜的質能互換原理在愛因斯坦眼裡不過是一個簡單得不能再簡單的公式：E=mc2。簡單的方法更容易被人理解，更容易實現，也更容易維護。遇到問題時要優先考慮最簡單的方案，只有簡單方案不能滿足要求時再考慮復雜的方案。
4. 不鑽牛角尖。當你遇到障礙的時候，不妨暫時遠離電腦，看看窗外的風景，聽聽輕音樂，和朋友聊聊天。當遇到難題的時候會去玩游戲，而且是那種極暴力的打鬥類游戲，當負責游戲的那部分大腦細胞極度亢奮的時候，負責編程的那部分大腦細胞就得到了充分的休息。當重新開始工作的時候，會發現那些難題現在竟然可以迎刃而解。
5. 對答案的渴求。人類自然科學的發展史就是一個渴求得到答案的過程，即使只能知道答案的一小部分也值得我們去付出。只要堅定信念，一定要找到問題的答案，才會付出精力去探索，即使最後沒有得到答案，在過程中你也會學到很多東西。
6. 多與別人交流。三人行必有我師，也許在一次和別人不經意的談話中，就可以迸出靈感的火花。多上上網，看看別人對同一問題的看法，會有很大的啟發。
7. 良好的編程風格。注意養成良好的習慣，代碼的縮進編排，變數的命名規則要始終保持一致。大家都知道如何排除代碼中錯誤，卻往往忽視了對注釋的排錯。注釋是程序的一個重要組成部分，它可以使代碼更容易理解，而如果代碼已經清楚地表達了思想，就不必再加註釋了，如果注釋和代碼不一致，那就更加糟糕。
8. 韌性和毅力。這也許是"高手"和一般程序員最大的區別。A good programming is 99% sweat and 1% coffee。高手們並不是天才，他們是在無數個日日夜夜中磨練出來的。成功能給我們帶來無比的喜悅，但過程卻是無比的枯燥乏味。你不妨做個測試，找個 10000以內的素數表，把它們全都抄下來，然後再檢查三遍，如果能夠不間斷地完成這一工作，你就可以滿足這一條。
❻ .net方向的編程 應該怎麼學習 多謝指教！
想找個工作的話你的這些書已經夠了，但你最好再買本.net的開發實例相關的書，然後再平時多做些拿的出手的軟體（或網站）。這樣在面試的時候會比較有底氣。估計你要學會這些東西大概要半年以上。
現在web軟體是軟體的發展趨勢，因為不用裝客戶端，不用專門寫伺服器。所以目前一些中小型IT公司比較傾向於web
❼ 如何提高asp.net編程技術
asp.net自學的話非常難,因為asp.net需要學習的東西很多而且很難,如果你沒掌握學習asp.net的方法的話,可能1-2年都只能入門,如果你掌握asp.net的學習的方法的話,半年就能學會asp.net。 …………………………………...
❽ 如何學習網路編程
具體到編程，用java來實現網路編程是很容易的，可以作為網路編程的入門。使用C＋＋和winsock相對復雜一些。
總之看實際需要了。
你好初學網路編程者可以從以下幾個步驟開展：
1）下載一個可以互動的學習工具，通過這個與這個工具互動，我們可以及時的學到每個api的結果如果。
對於有c/c++或java基礎的朋友通過一兩個禮拜的時間就可以上手了，另外個人建議初學者可以學習dive into python。
2）掌握網路編程中會用到的幾個基本概念和內涵，比如IP地址，port號，socket等
3）記住和消化網路編程C/S模型，把server和client端編程的常用模式理解和消化
4）花幾天時間學習socket api集，api集可以分為下面幾大類：創建 socket bind listen accept收發 read/recv/recvfrom write/send/sendto關閉 close shutdown參數 getsockopt/setsockopt地址 gethostbyaddr getaddrbyhost,...在學習這些api時候，可以先關注在函數功能，參數意義上
5）結合python互動平台，實踐socket api的用法，比如socket函數怎麼使用，bind怎麼使用等等。在互動過程中，我們可以變換參數，看看調用結果如何。比如，創建一個tcp socket的語法如下：socket(AF_INET,SOCK_STREAM)創建一個udp socket的語法如下：socket(AF_INET,SOCK_DGRAM)
6）學習socket server端編程實現簡單規約比如echo，time等，然後通過cmd中的telnet來測試。
7）學習I/O模型，比如阻塞、非阻塞和反應式（select,poll,WaitForMultipleObject)等
8）學習Richard Stevens的《Unix網路編程》，深入學習其中的api原理以及服務端設計原理，並通過代碼編寫。
9）下載高性能網路編程框架twisted，筆者強烈推薦，它將使你的網路編程效率提高10倍以上。
10）學習設計模式、操作系統知識比如線程、進程、同步等。
要想真正掌握計算機技術，並在IT行業里干出一番事業來，有所作為，具有一定的編程能力是一個基本條件和要求。打好基礎學編程要具備一定的基礎，總結之有以下幾方面：
（1）數學基礎 從計算機發展和應用的歷史來看計算機的數學模型和體系結構等都是有數學家提出的，最早的計算機也是為數值計算而設計的。因此，要學好計算機就要有一定的數學基礎，出學者有高中水平就差不多了。
（2）邏輯思維能力的培養 學程序設計要有一定的邏輯思維能力，「邏思力」的培養要長時間的實踐鍛煉。要想成為一名優秀的程序員，最重要的是掌握編程思想。要做到這一點必須在反復的實踐、觀察、分析、比較、總結中逐漸地積累。因此在學習編程過程中，我們不必等到什麼都完全明白了才去動手實踐，只要明白了大概，就要敢於自己動手去體驗。誰都有第一次。
有些問題只有通過實踐後才能明白，也只有實踐才能把老師和書上的知識變成自己的，高手都是這樣成材的。
❾ 我現在很迷茫，我是學習軟體的在從事.net編程但是自己的技術一點也不怎麼好，也就不怎麼喜歡這個行
工作經驗也不是一朝一夕之功。目前做開發人員的著實不少，但能做設計人員的真沒幾個。我就經常碰到這樣的情況，有時候是我自己需要人，有時候是別人找我要人，前提條件就是能頂住一塊需求或者有設計思維。目前絕大部分新參加工作的（指的是2年以內的工作經驗者）都只是按自己的思維或完全沒有設計思維在幹活，但市場上奇缺有相當豐富的設計應變能力和需求控制能力的人。這種人員往往都是需要少則五六年工作經驗者。
工作有時候也是需要看自己的興趣發展的，如果自己對該行業完全沒興趣，也沒必要把一生中的光陰的幾分之幾耗費在上面。樓主可以仔細思考一下自己的興趣所在，然後再設想轉行的事情。
❿ net程序員怎麼提升自己的技術能力
一、先列三個常見的開發場景：
1、拿到一個模塊詳細設計文檔，大部分程序員的通常做法就是開始搭建界面代碼，然後從第一個按鈕點擊事件或頁面Load事件開始寫第一行業務代碼。寫的差不多了，就運行一下，發現哪裡不是自己想的那樣，就改改，直到改到是自己預想的那樣。
2、做完了一個功能模塊或幾塊相關聯的功能模塊，輸入111asd，發現新建正常、保存正常，就提交給測試人員。測試員用測試用數據、測試場景用例來測試，發現有問題，就登記bug。對於嚴重的影響下一步測試的BUG，測試員就用內部IM通知這個開發人員。對於不影響繼續往下測試的BUG，測試員就登記下來，等程序員有空時處理。
3、程序員一般工作不希望大家打擾，所以開發起來就是開發。等手頭開發告一段落，就看看BUG庫。發現有與自己有關的BUG，就從第一個BUG開始看起。就開始通過IM和測試員掰扯起來（這不是個BUG啊、業務邏輯不是你想的那樣啊、我這里不能重現啊、你給的信息描述不清晰啊），於是IM幾來幾往，甚至跑過去當面交流一番，甚至會拉扯上產品經理一起討論，更甚者需要項目經理或產品經理發起一個會議來集體討論一下
這是不是很熟悉呢？這就是大部分程序員開發的三個步驟：寫代碼、自測、修復BUG。
二、說好的代碼設計、代碼測試呢？
代碼設計？那不是都有開發平台么，已經固化了啊。那不是維護舊功能做完善修改呢么，又不是寫新代碼，只能在現有代碼基礎上修改啊，你又不能大幅重構。
代碼測試？你丫需求討論期、產品設計期、設計評審期那麼長，都把研發項目時間佔光了，就留下2個星期讓我們寫代碼，我們哪裡有時間搞那麼深的測試。還想讓我們搞結對編程？還想讓我們搞測試驅動開發？
而且你看測試，什麼功能測試、集成測試、性能測試、安全測試、安裝部署測試、升級測試、遷移測試、UAT測試，一大堆測試，測試也需要很多時間。
一個項目，需求討論、產品范圍規劃與評審、產品設計與設計評審佔了一個半月，開發+自測就一個月，測試佔了一個半月，這就4個月了啊。
三、為啥程序員寫代碼總是寫寫測測？
剛才大家也都看到了，大部分程序員都是從界面代碼開始寫起，而且寫一寫，就運行一下看看。為什麼會是這種開發方式？
那是因為大部分程序員缺乏在腦子中的整體建模能力。只能做出來一點，真實的感覺一下，然後再往下。
有些是產品經理的上游就有問題，沒給出業務流程圖（因為產品經理也沒做過業務），也沒畫清楚產品功能操作流程圖。
為啥沒給出業務流程圖？因為產品經理不熟悉業務，另外，產品經理也沒有流程建模能力啊。為啥沒畫清楚產品功能操作流程圖啊？因為不會清晰表達流程啊。
很多產品經理、程序員，都缺乏分類、分層、相關、先後能力，更別說總結、洞察能力。
這是基本訓練，是一個做事頭腦清醒的人必備的技能，這不是一個程序員或產品經理或測試員的特定技能要求。
我經常看書就梳理書的脈絡，每看一本就寫一篇總結。我過去閑扯淡還梳理過水滸傳、紅樓夢的人物關系圖呢，其實就在事事上訓練自己的關聯性、層次性、洞察性。
我經常面試一個人時，我會問這樣的問題：「你把我剛才說的話復述一遍，另外你再回答一下我為什麼會這樣？」，其實，我就在看一個人的細心記憶、完整梳理、重現能力，我也在看一個人的梳理、總結、洞察能力。
我個人寫代碼就喜歡先理解業務流，然後理解數據表關系，然後理解產品功能操作流，大致對功能為何這樣設計、功能這樣操作會取什麼表、插入或更新哪些表，哪些表的狀態欄位是關鍵。
然後我寫代碼的時候，就根據我所理解的業務流、功能操作流、數據輸入輸出流，定義函數，定義函數的輸入與輸出。
然後，我會給函數的輸入值，賦上一些固定值，跑下來看看能否跑通這幾個關聯函數，看看還需要怎樣的新增函數，或者看看函數的輸入輸出參數是否滿足跑通。
剩下的事，就是我填肉寫詳細邏輯代碼了。
當然，大部分人沒我這樣的邏輯建模能力。怎麼閱讀理解也想像不出來，也沒法定義函數。畢竟有邏輯建模能力的程序員都很少，100個人里有10個，已經是求爺爺告奶奶好幸運了。
那怎麼辦呢？
我建議是分離分工配合，這就是現實中沒辦法的辦法。讓有邏輯建模能力的人來設計函數框架、來設計工具來設計代碼模板，然後讓沒有邏輯建模能力的人來填肉寫詳細邏輯代碼。
我們可以先從最緊要的模塊開始這么做。不緊要的模塊，還讓它放任自流，讓熟練手程序員繼續塗抹。
我曾經還讓有頭腦的程序員做榜樣，給大家分享他是怎麼規劃函數的，怎麼做維護性代碼的代碼結構改善的。但是發現效果並不佳，其他人並沒有因此能做代碼設計。可能邏輯建模能力是個人的基本素質，是從小到大訓練成型的，不是你一個大學已經幾年的人能夠短時間內可以訓練的。
所以啊，還是讓能走的人先走，讓從最緊要的模塊開始這么做。
不必擔心這樣做後，因為過去一件事被分工（一個做代碼框架一個填肉）成兩個人做了會降低工作效率。我們很多的工作效率低就是因為半瓶子醋搞出來的，來回反復修改。
真是應了劉德華在電影里說的那句話：說你又不聽，聽又聽不懂，聽懂了又不做，做又做不好，做不好還不服氣。
四、為什麼大部分程序員不做代碼測試或白盒測試或單元測試呢？
還是因為沒有代碼設計。因為沒有函數啊。所以，一個按鈕功能有多復雜，代碼就有多長。我見過2000行的函數，我也見過1000多行的存儲過程和視圖SQL。怎麼做白盒測試啊，這些代碼都粘在一起呢，要測，就得從頭到尾都得測。
所以啊，先學會設計函數，先寫好函數，這就求爺爺告奶奶了。很多開發了5年的熟練手程序員，可能都未必會寫函數。
函數的輸入輸出值就很有講究。很多人都寫死了，隨著版本迭代，發現過去定義的函數參數不夠用了，於是就新增了一個參數。然後，相關性異常就爆發了，其他關聯的地方忘改了，到底哪些有關聯，怎麼查啊，本系統沒有，沒准其他系統就調用你了，你根本不知道哪個神經人曾經COPY過你的代碼修吧修吧就改成了他的功能呢，而且裡面的很多代碼他看不懂也不敢刪，只要他實現的功能正常了他也不管了。於是，你改了你這個函數，他的系統就莫名出錯了。
所以，我一般會定義幾個對象來做參數。另外，我也很注重函數的日誌、函數的異常保護、異常拋出、異常返回。另外，我也很注重參數輸入值的合法性校驗。
所以啊，應該開發Leader們先制定函數編寫規范最佳實踐，輸入輸出參數怎麼定義比較好，函數的返回值如何定義比較好，函數的日誌記錄應該怎麼寫比較好，函數的異常保護、異常拋出、異常返回如何寫比較好。先教會一般程序員，先從會寫函數開始啊。
當然，你光有一份規范，程序員們還是不理解、不實際應用啊。所以，還得Leader們做好典型的代碼模板，裡面是符合函數規范的代碼框架，只有這樣，一般程序員們才會照貓畫虎適應了函數設計的編程習慣。
所以啊，我專門重新定義了leader的明確職責，其中第一個重要職責就是：負責工具/框架/模板/規范的制定，並且負責推廣且普及應用落地。
你不明確定義Leader的這個重要職責，你不對這個職責做明確的KPI考核，誰尿你啊。你以為好的工具/框架/模板/規范是靠人們的熱情、自發產生的么？我們還沒有那麼自覺高尚啊。
五、為什麼大部分程序員不寫注釋啊？
我經常說一句話，千萬別多寫注釋。為啥？
因為我們經常遇到的問題不是沒有注釋，而是更糟的是，注釋和事實代碼邏輯是不相符的。這就出現常見問題了：殘存下來的設計文檔是一個邏輯、注釋是一個邏輯說明、真實代碼邏輯又是一個，鍾表多了，你也不知道正確時間了。
所以啊，產品文檔、注釋、真實代碼，三者總是很難一致同步。我為了幾百人研發團隊能做到這個同步花了大量心血和辦法，但我最終也沒解決了這個問題，還把Leader們、總監們、我都搞的精疲力盡。
索性回歸到一切一切的本源，代碼，就是程序員的唯一產出，是最有效的產出。那麼，讓代碼寫的不用注釋也能看懂，咱得奔著這個目的走啊。
為啥看不懂，不就是義大利面條式代碼么，又長又互相交雜。
OK，我就規定了，每個函數不能超過50行。用這一個簡單規定和靜態代碼檢查插件，來逼迫大家嘗試著寫函數。有的函數屬於流程函數，是串起其他函數的，有的函數就是詳細實現函數，實現一個且唯一一個明確作用的。
有了流程函數和功能函數，而且每個函數不超過50行，這就比過去容易看懂了。
六、為什麼大部分程序員不抽象公共函數啊？
我經常說一句話：千萬別抽象公共函數啊。為啥？
因為大部分程序員缺乏抽象洞察能力。特別是有些積極熱情有餘、愛學習愛看書、半瓶子醋晃悠的二桿子，看了幾本UML、重構、設計模式、整潔代碼之道，就躍躍欲試了，還真敢給你抽象公共函數了。
一開始，他覺得80%相似，20%不相似，於是在公共函數裡面簡單寫幾個if..else做個區隔就可以。沒想到，越隨著版本迭代，這些功能漸漸越變越不一樣了，但是這個代碼已經幾經人手了，而且這是一個公共函數，誰也不知道牽扯多少，所以誰也不敢大改，發現問題了就加一個if..else判斷。
沒想到啊沒想到，這個本來當初公共的函數，現在變成了系統最大的毒瘤，最復雜的地方，誰也不敢動，除非實在萬不得已，手起刀落。
所以，我平時告誡程序員，純技術的、純通用的，你們可以嘗試搞搞抽象公共函數，對於業務的，你們還是簡單粗暴的根據Leader們做的代碼模板代碼框架，乖乖的復制、修改、填肉吧。
你們啊，先從做模板做代碼片段開始吧，咱們放到咱們內部代碼片段開源庫里，看誰的代碼片段被別人復制的多，說明你的代碼抽象設計能力越好了。那時候，我就大膽放心讓你撒丫子跑了。在沒有學會跑之前，給老子乖乖的復制、修改、填肉吧。