今天開會，領導下達了一道指令，需要對某個服務進行關閉。需要在夜間進行操作，需要投入的人手有：各個產品線的測試人員、不同組的開發人員、運維、dba。
此件事情是否優先順序較高，以目前專案上的緊急程度來看，是屬於優先順序較低的。投入這種的人手和物力，消耗有點大，投入產出比不高。
如果由我來做相應的決策的話，我會採取的方式是：
1、推遲服務關閉的處理，可放到下次發版或維護的時候統一處理。
2、採用其他測試方案，如預發布環境先行驗證，逐步替換，根據不同產品的發布時間，逐步完成。
通過此事情，也反饋了另外乙個問題，底下的人沒有給出其他的建議，完全是領導的一言堂管理。這種管理方式，有利亦有弊。當決策正確時，效率較高；當決策出現偏差，會出現致命性錯誤（如某東）。
對於優先順序，可以採用四象限法則：緊急而且重要、重要但不緊急、不重要但是緊急、不重要且不緊急。
上述的事情，屬於第三（不重要但是緊急）。可以先緩一緩。
關於makefile的一點思考
在gnu編譯工具軟體中，如果對單一的原始檔進行編譯，可執行指令如下 gcc o x x.c 此指令會將原始檔編譯為目標檔案。若是對執行緒類檔案進行編譯，則在末尾加上 lpthread指令。但若是對多檔案進行編譯，即若是編譯的目標檔案同時包含另一檔案中的函式。則在編譯的時候需將另一檔案加到編譯原始檔中...
關於指標的一點思考
指標是乙個變數，所不同的是，它存的是位址。因為資料型別決定著如何解釋這個位址 位元組數和操作 因此根據的資料型別的不同，指標又有不同的型別。某個物件 a 的位址範圍為 a,a size n 其中size n是a所佔的位元組數 比如乙個一維陣列int a 10 位址範圍為 a,a 10 sizeof ...
關於演算法的一點思考。。。
關於演算法的一點思考。在實踐過程中，我發現 有時候要解決乙個問題，可以設計幾個演算法分步完成任務，這樣處理起來比較簡單，但是情況並非總是如此，有時，我們需要將幾個步驟放在同乙個演算法內連帶處理，這樣才比較容易處理問題。我還發現，有時候，解決問題的演算法，是被發現出來的，並加以一步一步的檢驗才得以確定...