最近應朋友的需要，幫忙寫了個日常賬本管理的小程序，并且在寫程序過程中有了點心得，心得很雜亂，涉及到軟件開發的不同方面，因此統一稱之為“小小軟件工程”。
● 電腦不是萬能的。
無論是客戶還是工程師都覺得計算機可以幫助人做許多事情，對應用程序有著“不切實際”的期望，希望程序要簡單好用、同時又是準確無錯、及時響應使用者需求等等，在這樣的目標驅動下結果往往是程序一點都不好用（有的時候覺得還沒人來得簡單），大部分時候不出錯（但不是100%，還是有時候會出錯，并且不知道什么時候發生，錯在哪里），程序反應越來越慢（不知道電腦到底是節約時間，還是在浪費生命…）。
其實，計算機就如其他工具一樣只是幫助人延伸自己的能力，只是他們更加像人，因為他們有很強的計算能力。人因為受生物功能的限制，管理百條、千條數據、計算幾千、幾萬都還可以應對，但是信息爆炸造成數據量越來越大，人們關注的事情越來越精細，因此通過計算機可以幫助人面對更大的計算量，管理更多的數據。但是計算機本身也受自身條件的限制，并不能解決所有的問題，作為工程師一定要去了解電腦與人之間的差異，哪些是人可以做的，哪些是計算機可以做的，這樣子寫程序時才不會陷入程序過度復雜的問題
● 程序不是用來簡化人的工作的。
這個想法肯定與許多人的觀點有沖突，想法來源于老婆（計算機人士）建議我把使用界面優化一下，使得最終使用者用起來更加方便，最后被我否決了。原因是這里的一個功能的優化可能要寫幾十行代碼，而使用者（只有一個）只在輸入過程中使用一次，而幾十行代碼還會給我的程序本身增加復雜性，而使用者完全可以人為調整一下就能很好的適應。
其實，這里也是個投入產出比的問題，這里的優化對于使用者來說價值不大，而應用的首要目標是快速交付，因此所有的優化工作我只選擇了為增強數據正確性而做的一些優化，其他使用中不適的地方全部請人來適應計算機。
聽起來，我做的事情不符合以往的思維，但是這個想法與上個想法一樣都認為電腦的根本作用是幫助人解決人所不能做的事情，而不是一味的去解決人已經擅長的事情，比如說：讓程序提供各種功能去支持與未來的兼容，因為人比電腦更能適應變化，著眼于現在才是程序開發的根本。
于是，一周以內我就交付了程序，并且將對方大部分需求都給予了否決，只提供了最基本的功能就是原始數據的輸入和明細表輸出，并建議對方在使用過程中思考一下還需要哪些功能，當使用者對這些需求有了足夠的認識，并且現有的數據使用者已經無法手工處理時，我再為之提供新的功能，降低了開發成本，同時也降低了使用成本，因為我所有的數據全部是開放的，如果他需要修改直接在數據上就可以完成。
在開發過程中，我也受到了更好用的誘惑，因為有數據就很容易想到用數據庫來做，這樣子操作數據會覺得更加容易，但是后來還是只用Excel就實現了，根本原因是使用者對計算機非常不熟悉，也就是對Excel有所了解，如果我更換了使用習慣以后，光學習新的東西就會給使用者帶來成本，學習新的工具也會增加錯誤的機率，如果為了保證數據準確性又會增加開發的工作量，因此我放棄了數據庫的誘惑，仍然使用Excel保證了功能簡單，數據開放。
● 需求采集時要將人的思維模式轉化成電腦的思維模式。
需求采集是應用成功的關鍵，但是客戶大都沿用傳統工作中的思維模式，必須通過交流轉換客戶傳統的思維模式，使之向計算機的方式靠攏。比如：這次的客戶他需要謄寫原始賬到好幾個本子，于是他總覺得數據也需要在表單中重復錄入，因此我向他解釋計算機里面所有數據最好是統一出口，計算機復制生成這些數據都會非常簡單。他理解了我的說法，自然這個需求就不用投入開發的精力了。
● 程序再好的靈活性也比不上人。
這個問題如前面所說的，不要找計算機來代替人，如果人可以解決的問題，千萬別急著用計算機來實現，成本高不說，可能投入產出比不值得才是根本。
● 代碼應該通過重構提升優雅性和性能。
不想考慮第一次代碼就寫得多漂亮，要遵守多少嚴格的約定（當然這不是說沒有規范，重要的是規范應該遵守最大公約數，只有能夠為大家協作帶來便利的規范才是必須的）。相反不斷的重構才是代碼優化的最佳辦法，重構一定是為滿足更好的管理代碼而做的。