[作者袁永福，微軟MVP，從業13年，南京都昌資訊科技有限公司創始人，南京都昌公司專業從事於電子病歷編輯器、電子病歷文件技術、時間軸等國際化醫用UI層控制元件軟體產品。聯絡郵箱[email protected]，網址www.dcwriter.cn]
     如何開發出好HIT軟體是諸多HIT公司孜孜不斷的追求，軟體開發涉及方方面面，既有巨集觀戰略，也有中層執行，最後還要落實到微觀的程式設計。
     我作為電子病歷編輯器的供應者，和行業內很多軟體公司有著諸多交流，接觸到大量的一執行緒序猿和許多實際程式碼，這些程式猿代表了HIT行業的真實生產力，這些程式碼代表了各家公司的真實水平。在和他們的交流中就萌發了這個主題：“關於程式設計，你知道嗎？”。
     首先解釋下，這個主題中的“道”就是程式設計之道，“知道”就不是傳統的知道的意思，而是“知曉程式設計之道”的意思。
     “道”這個詞高深莫測，我並沒有深入研究過，各人有各人的理解。我覺得簡簡單單，起源於實踐的就是我所理解的“道”。我本身就是道的一部分，萬事萬物都是道的一部分。吃飯喝水都有其中的道，程式設計也有道可講。每一行程式碼都是一條小道，許多小道整合在一起就是大道。結合我十多年的程式設計實踐，談談我所理解的程式設計之道。
任何道都講究天時地利人和，結合HIT軟體程式設計的現狀，談談這個天時地利人和。
     天時，就是高高在上的大環境，淺顯的理解就是雲端計算、大資料、移動計算、居民健康檔案這些高大上的東西。
     天空烏雲密佈，風起雲湧，但未必立即下雨，不過此時出門認為沒下雨就不帶傘，那是不講天時，逆天而行，必然會淋雨的。因此天時是任何位置上的任何人必須要考慮的。
地利，就是各人所處的小環境，比如在某個公司、某個醫院中。

     人都有惰性，不敢改變懶於進步，只想固守現狀而不管天時。[袁永福原創]

     燕雀可以在風雨來臨時依靠地利仍然可能固守在片瓦之下，而鴻鵠知天時、用地利，就可以遨遊於九天之上。
     毫不客氣的說，HIT行業中存在著不少燕雀，還有一些是鴻鵠身燕雀心的，典型現象就是一些公司和醫院IT人士還在抱著PB/DELPHI等老技術生存著。一些用PB的也敢自稱雲端計算、大資料實在是忽悠人。醫院人士由於體制原因固守老技術那是可以理解的，自生自滅的公司不與時俱進那是有些不應該的，公司不光是老闆的賺錢工具，還擔負著手底下弟兄們生存發展的良心。
     究竟要做燕雀還是鴻鵠，人各有志，各有各的幸福，不必勉強，不過想做鴻鵠的還是需要知天時、用地利，利用現有條件，拿出決心和執行力，順應天時做出改變。PB的衰亡是必然的，一些沒有斷決的公司將跟著它溫水煮青蛙式的陪葬。[袁永福原創]
     人和，也是軟體的基礎。一些公司具有很好的商業執行力，但缺乏技術力量，導致專案沒有賺到該賺的錢，或者外包轉包。即使是大的老牌公司也會出現這種情況。沒有人和就沒有執行力，天時地利等等嚴重受損。
     其實天時地利人和三者是相互影響的，沒有規定前後關係。所謂戰略和戰術那個在先也是和雞和蛋的問題那樣無解。
天時就是眾生的意志的加權和，地利是圈子裡的一群人的加權和，人和就是更小的一群人的加權和。歸根結底都是一群人的加權和，科技以人為本嘛。作為企業，三者都是要並行考慮的，比如對於一個公司，是誰當縣衛生局長可能比誰當國家主席更重要，因此沒有規定先後輕重，一切按需變化。
     天時地利人和是高階程式設計道，而具體的編碼就是高階程式設計道，兩者那個更重要也是沒有規定的。
說到編碼，可以說我接觸的程式猿的編碼水平和公司大小無關。大公司在軟體開發流程管理上有些講究，但仍然能盛產垃圾程式碼。舉個例子，某公司的顯示對話方塊的C#程式碼大致如下：
frmDialog frm = new frmDialog();
frm.ShowDialog();
就這麼簡單的兩句話，非常的隨意，基本上就能導致記憶體洩露，經過指導修改如下：
using( frmDialog frm = new frmDialog())
{
     frm.ShowDialog();
}
      經過詢問，他們表示公司裡寫程式碼基本上不用這種using()語法結構，對此我表示無語。這就引出了程式碼質量的話題。
     現在醫院的病歷質控，病歷書寫時間和文件完整性控制大家都能做了，但是病歷內容質控還正在發展中。[袁永福原創]
類似的，現在正規的軟體公司已經能使用SVN等工具進行原始碼版本管理，有部分公司也能參考CMMI的思想來進行文件控制了。不過對於程式碼的質量還是缺乏管理和干預的。
對於提高軟體穩定性方面，我在實踐中總結了幾個原則，包括：
1. 最小許可權原則。編碼時讓程式保持高風亮節，僅僅向系統申請操作所需的最小許可權。比如讀取檔案內容那就以只讀模式開啟，而不是可讀寫模式開啟。
2. 盡晚建立儘早釋放原則。對於檔案、資料庫連線、網路連線等等資源儘可能晚的例項化，儘可能早的釋放。即使稍微增加程式碼量也是值得的。
3. 儘早暴露錯誤原則。在軟體的開發和除錯階段，儘量少使用try-catch結構，儘可能的暴露出程式的錯誤，而不是一味的和諧來掩蓋錯誤，當然在釋出正式版本時還是需要和諧的。
4. 資源共享原則。在商業運作上，大家都想自己的系統獨佔客戶，但在編碼時要時刻記住電腦不是程式獨佔的，還執行著其他程式，不能霸道的佔據著系統資源，否則容易產生相容性問題，甚至會大水衝了龍王廟。
     此外還有一些其他原則。時刻謹遵這些原則，就能較好的提高編碼質量，產生高質量的軟體。
     不過發現大多數程式猿是不會自發的總結出這些原則的，只有經過培訓才能引起他們的關注，提升他們的思想。因此培訓是一個必要的提升程式設計質量的手段。
     其實也沒有必要請外來人員培訓，正規的軟體公司大多有那麼幾個高手，給這些高手安排些時間做員工培訓工作就足以改進不少。[袁永福原創]
     可以說程式猿寫出的每一行程式碼就蘊含著程式設計之道，寫出高質量的程式碼，滿足業務需求，這就是正道；寫出低質量的程式碼，不能滿足業務需求，這就是斜道。理解程式設計之道需要別人引導，更需要獨立思考摸索總結，既能沉浸於無邊碼海，又能跳出來高瞻遠矚，這才是較為理想的程式設計之道。達到這種程度需要長期而廣泛的程式設計實踐加上每天的勤于思考，真是人間正道是滄桑啊。