最近總有一些問題困擾著我，而這些問題又是那麼的相似。所以我決定要在這裡把它記錄下來，順便再把自己的想法清清楚楚的表達出來。
這個問題源自於一次和同事的閒聊。他以前所在的組是做乙個基礎的通用元件，這個元件維護起來甚是心累。不僅要修以前的bug，還要為使用方增加新功能。我當時一聽，就忍不住和他吹噓了一下vs code的做法。vs code做法的核心思想就是：縱使是再完備的ide也難以覆蓋每乙個開發者的需求，因此它選擇把皮球踢給開發者自己，讓他們自己實現自己想要的功能：搞外掛程式商店，完善外掛程式生態，優化開發外掛程式的體驗、降低門檻。這種就是我想要說的，一種徹底解決問題的解決方案。
與之類似的，我還想到了wsl的例子。最開始微軟通過在windows nt核心上完全實現一遍linux system api的方式來實現linux子系統。結果就是那邊linux每增加乙個特性/功能這邊wsl都要去用windows nt適配一下，工作量可想而知。於是乎，像這種問題[點選這裡]從2023年一直拖到了現在...這次wsl2就學乖了，換了一種方式：用虛擬機器跑linux，以此來替換掉原來的wsl。想必他們的開發終於可以為不用修bug而松一口氣了 :-p
這次寫這篇部落格，還有乙個原因就是，我發現身邊也有一些這樣的例子。比如說，我們有乙個檢查配置表的程式使用vc++ 2008編譯的，而我們伺服器的**是g++ 4.8.4並且支援c++11標準。最致命的是，這兩個專案是公用**的，通過不同的編譯方式來做到在windows上執行這個程式。於是乎，在寫檢查配置表相關**時，我需要：
（1）小心翼翼的編寫相容vc2008的**，不能引人c++11相關的**；
（2）小心翼翼的維護引入的標頭檔案、需要鏈結的庫檔案；
上述第(2)點尤其難受。一般情況下引入乙個新的標頭檔案還需要考慮是不是在標頭檔案裡是否還簡潔的隱含了其它標頭檔案，因此標頭檔案搜尋目錄的複雜度是不可控制的。引入新的標頭檔案帶來的修改是沒有邊界的。
可以看到，上面就是乙個典型的反例。每當有**修改時都需要去「照顧」一下這個檢查配置表的程式。這個程式的維護完全就是補丁式，哪次改了不相容就打打補丁修改一下編譯引數。
相比而言，我覺得一種比較好的做法應該是，在linux上把這塊**編譯成乙個庫檔案。在編譯伺服器和配置表檢查程式時引入這個庫檔案，來做到**級別上的復用（類似於pythoncore工程和python命令列工程那樣） 。為了跑在windows上可以使用虛擬機器執行，win10系統可以用wsl，win7就裝乙個別的：p
想起同事說的一句話：有問題就改，有bug就修。沒做過、沒試過、沒見過這種不應該成為我們不追求更好更優的藉口。
什麼是冪等性解決方案
今天看到一篇講冪等的文章，想起來上次面試的時候有問過，記錄一下，加深印象。首先說一下冪等的概念，官方一點的說法是 在程式設計中乙個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。其實可以簡單理解為多次操作和一次操作的結果是一樣的。一般情況下介面正常呼叫的時候返回資訊不會重複提交，但...
解決方案是什麼
在it界，人們經常會談到 整體解決方案 很多公司宣稱可以向使用者提供整體解決方案，並把它作為乙個重要的發展策略公之於眾。甚至有些公司將乙個產品如 印表機也稱為整體解決方案。解決方案是乙個筐，什麼都可以裝？解決方案是否有評價標準？最近接受記者採訪的陳曉燕女士提出了康柏對解決方案的認識，讓我們 了解 解...
是誰養魚的解決方案
誰養魚這個題目，我把題目截屏保存在這一篇裡，就不再一一敲鍵盤了，方便大家邊看題目邊看解析。本次根據自己的想法將這個問題的邏輯思維順序寫一下，感覺挺有意思的。如果有興趣可以試一下。根據最上邊的五個條件，首先畫出乙個六行六列的 1 從條件8可知，喝牛奶的人住在中間的房子裡，b3 milk 2 從條件9可...