已經鑽DELPHI很深了，當然現在DELPHI是過了最輝煌的時代。但為什麼要繼續下去，而不轉向其它的?這是不是死腦筋？ 我看了一下C#的LINQ的產生，然後又被實體框架所代替。思考了一下： 1）LINQ的確是有好處，但是所用的場景又不多，這樣就會變得很雞肋。所以說學新的東西，有時對自己來說不一定有相 ...
已經鑽DELPHI很深了，當然現在DELPHI是過了最輝煌的時代。但為什麼要繼續下去，而不轉向其它的?這是不是死腦筋？
我看了一下C#的LINQ的產生，然後又被實體框架所代替。思考了一下：
1）LINQ的確是有好處，但是所用的場景又不多，這樣就會變得很雞肋。所以說學新的東西，有時對自己來說不一定有相當大的好處。
2）軟體編程發展現在，會有很多花巧的小東西，這些小東西可能帶給你好處，但也不一定。只要你用不上，就沒有好處。而且有些東西只是過渡性，嘗試性，上家覺得不好又可能把它放棄，這的確對開發員很忌的事情，不跟M$也是這個原因。C語言很老，但到現在還是排第2，可以說明這些問題。因為C什麼都可以自己做，自己做上家做輪子。它功能夠單一，不需要太多東西也能排第2。
3）框架問題，其實深入一件事，在長時間編程中，會積累對自己工作有利的框架。這樣自己的工作效率也會不斷提高。如果跳到另一個坑，又得重新積累，所以這樣不一定划得來。而框架積累到一定時，效率不一定比新玩意差多少。
4）客戶要求，大部分都對語言沒有要求。只要方向不變，何苦要折騰自己。也許有些客戶是有要求，但這樣的單子可以不做。如果對語言有要求，同理又可以要求使用什麼框架，什麼結構等。但是框架是千變萬化，編碼風格也是。一份源碼，就算是最熱門的語言，給另一個人維護也不容易。
5）D繼續發展，不怕小眾。只要還是自己用，就不怕小眾。一個人只能做好自己的本份事。自己寫得舒服，客戶用得舒服就行。知足常樂，不必什麼事都要爭第1，騰出的時間可以做好其它東西。其它的事情也很重要。人就是要平衡好，如果人太苛刻，事事求最好，事事反做不好。
6）善用不起眼的小東西，思考問題。升提自己。之前我有點抱怨DELPHI分實現部分和定義部分，改代碼不方便。後來用了MMX,發現這個缺點沒有這麼明顯了。工作起來也舒服得多。最新的DELPHI XE IDE,CNPACK,MMX各種小東西不斷深入再深入，發現用得好，也是不錯。雖然總體和最熱門的C#總有些差別，但總體問題不大，可以接受。
調試代碼也是，覺得VB一類的語言可以邊調試邊改代碼，D不能。但後來改進了調試技術和調試習慣，發現問題也不算非常大。
其實這也是處人處事的哲理，一個人也是，不必因為小小的事情，就抱怨自己的所處環境如何不好，要換這個換那個。其實生活和工作，只要用心分析，就算是在有限的資源下，不斷的進行小改進，也會取得好的結果。
以上幾點只是針對自己個人情況所思所想的交流見解，也許讀者來說，會有另一番不同想法。
