吳旻泰巖網路工作室
佛說：軟體開發之苦，緣於不能永生。輪迴是眾難之源。
brooks
說：沒有銀彈。
我說：超脫、彼岸從來就沒有出現過，信什麼哥都沒用。
（一）「先汙染，後治理」是落後地區為了發展經濟而經常使用的辦法。對於急於顯示政績的**們來說，如果在他的任期內汙染還沒達到不可忍受的地步，那就汙染好了。要不要治理，如何治理，下一任**會根據情況來處理的。
不幸的是，軟體開發中也這麼幹的，竟然是絕大多數。為什麼一定要先「汙染」呢？大多數原因，或是想摸著石頭過河，卻沒想到河水越摸越深；或是想眼下先能解決哪些算哪些，包袱和問題將來再說，卻沒想到將來對這些問題的處理成本更是高得離譜。
實際上我自己接手了不知有多少這樣的專案或程式。深刻的反思後讓我覺得，軟體開發其實是一項複雜的系統工程，砌個狗窩確實不難，但建一幢高樓大廈就必須深思熟慮！基本上這類事情都是因為開始的時候想得太少，而到了後來，事情就會發展成誰也無法掌控的局面。
（二）技術不是問題，需求才是關鍵。專案相關方的利益過於複雜，導致需求不明確，而不是技術無法實現。這一點在過去的
erp實現中尤其突出，不同科室的利益衝突的在技術人員看來就是需求不能確定。如果是乙個數字，它即可以大於
0，也可以小於
0，但它就是不能在大於
0 的同時又小於
0。軟體實施解決不了利益衝突。
前幾天我也碰到過類似這樣的需求不明確的情況。有人來找我談，說是某些為
0的資料應該濾掉，某些為
0的資料則不應該濾掉。我對他講，這個在技術上不存在任何問題，但規則應該是需求方給出。他回答說，那好，我去找專案經理。然後專案經理就再沒找過我。在我看來，我如果按他說的做，不一定什麼時候又會跳出乙個人來說我做的根本不對。
（三）大領導重視什麼，什麼才能做好。這句話是業內同行們的血淚總結。兩個級別對等的部門還只是會吵架，多個部門之間簡直就是在扯皮。要麼事情沒著落，要麼越做越走樣。某些中層幹部為了眼前的任期利益，會大量地把問題留給將來。如果很多方案都是臨時的，但未來根本就不會整理時，「破窗理論」就是對專案的最好總結。
有大領導在的好處是，他能夠協調各方立場，平衡各方利益，從而可以使專案正常推進。工作一旦走上了正軌，後面的事情大多都好解決了。
（四）理性的計算機，任性的程式設計師。前兩天面試了乙個程式設計師，我說：
c裡面有指標，
c++裡面有引用。對方馬上接道：
c裡面也可以有引用。我的頭當時就大了，不是說不能答錯，而是說對方當時自信滿滿的態度，根本就是在向我暗示其有多聰明和多專業。我發現某些技術人員對自己的一知半解很自負，甚至對自己根本不了解的地方，也敢說話。技術人員應該很聰明，但技術人員的目的不是為了證明自己比別人更聰明。
前幾天我讓乙個程式設計師完成乙個任務，後來我問他對那個任務有什麼困難，結果他轉給我乙個
bug，並說問題很嚴重。我仔細看了半天，發現那個
bug和他的工作根本沒有任何聯絡。我問：這個
bug和這個任務沒有任何關係呀。他說，是呀。我說，那你轉給我幹什麼？他不做聲了。
我後來想了很久，估計他當時僅僅是想迎合一下我，而根本還沒有認真看那個
bug是什麼呢。
軟體開發中的併發
併發作用 1.在互動式應用中，快速響應使用者的請求，提高感知響應的時間 2.充分利用硬體資源，計算資源 3.簡化應用設計 併發壞處 1.難於測試 2.併發應用執行在複雜的環境下，軟體不確定性增多 3.處理同步，通訊的問題，增加程式設計複雜性 4.併發開銷對效能的影響，包括上下文環境切換，同步等 併發...
軟體開發中的「格調」
在三年之前，我從學校畢業，進入公司，正式開始了軟體開發工作。我從完成第乙個開發任務的過程中學到了很多東西，包括 1 編寫程式只是軟體開發中的乙個流程，並非全部 2 程式編寫需要遵循一定的規範，遠遠不只是實現功能那麼簡單 3 程式編寫者是程式的第一負責人，要對自己的程式進行充分的自測，而非只要程式編寫...
自上而下的軟體開發和自下而上的軟體開發
自上而下 top down 開發模式是指從乙個應用的最高點開始開發。從最高點逐步往下層編碼，直到開發完所有的任務。一旦寫完了最下層的 開發任務就完成了。使用這種方式，你需要設計 編寫出所有你需要的但還沒有實現模擬介面 服務 偽 自下而上 bottom up 開發模式是指從乙個應用的最底層開始開發。這...