發出開發者的聲音：開發人員常說的謊言有哪些？

筆者就是一個開發人員。對我來講，開發者不僅僅是一份工作，更是一種心態，不能輕易放棄。對於那些滿懷激情地從事這個職業的人來說，做開發可能會上癮。

作為一名開發人員，我在職業生涯中遇到過許多挫折，處理過很多棘手情況。我承擔過團隊領導的角色，後來又擔任了首席技術官（CTO）。這些都曾改變了我的一些觀點，在觀察團隊成員的過程中，我也很快開始審視自己。

如何證明自己能夠避免錯誤，並促使人們找到正確的解決方案，從而避免陷阱，這是一個有趣的話題。這並不是因為我有什麼超能力，只是由於犯的錯誤比他們多。本文中，筆者將直面每個開發人員無意中對他人（但首先是對自己）說的小謊言。

筆者不是要評判任何人。開發是世界上最複雜的工作之一，特別是對一個初級人員而言，或者對在一個結構不太完善的團隊而言。開發人員的小謊言來自於這項工作的難度。

“成功了”

這個藉口有很多種變體，但都會導致相同的情況：測試好的東西在別人使用時不起作用。這可能是因為測試時不夠準確，也可能是由於測試過程中的兩極分化，即開發者建立了一種功能，但只使用了一種直接的方式，而終端使用者使用時需即興發揮。

問題不在於為什麼本應起作用的東西失靈了。開發人員無法相信——他測試時是奏效的，為什麼現在無法工作了?沒人否認這個功能在某個時候起過作用，問題在於，這兒確實有一個漏洞需要解決。

軟體是問題的解決方案

我們生活在一個任何事情都可以用軟體來完成的世界，軟體是我們的良藥。需要時間表怎麼辦？開啟的標籤太多怎麼辦？使用軟體就OK。

我們試圖用應用程式或軟體去解決生活中的任何問題。這個過程是數字轉換的一部分，但軟體只是一個工具。用Dijkstra的話來說，要求軟體解決企業問題就像要求潛艇游泳一樣。年輕的開發人員看到了CRM或任何SaaS解決方案等軟體的威力，認為它們可以解決所有問題，但實際可能比想象的要難得多。

這並不是工具的問題。最商業化的解決方案所提供的比普通需求多得多。問題是來自於公司的。在採用工具之前，必須調整流程，並透過培訓和文化培育來支援這種變化。

如果產品不好或者品牌太弱，那麼沒有任何電子商務解決方案可以提高銷售額；如果銷售團隊不瞭解正在銷售的產品，那麼沒有任何CRM能有助於銷售的推進。軟體解決方案是一種推動力，所以當開發人員提出一個解決方案時，請思考一下需要付出哪些努力才能使這種無用的東西開始生效。

“我們什麼都能做，只是時間問題”

當需要設計複雜的解決方案時，時間是一個關鍵的點。例如，建立Facebook顯然比建立一個簡單的網站需要更多的時間。

但問題是，時間不是唯一重要的東西。正確的答案應該是“如果我們有時間、能力和經驗的話，我們可以做到。”但我們往往不願意承認有些事情對我們來說太困難了。

“別擔心”

聽到“別擔心”或“相信我”之類的話時，你應該敲響警鐘。

我們總是思考因果關係的邏輯。事情不發生，就不會有任何後果嗎？觀點會受到個人經驗和認知的限制，在複雜的情況下，我們很難有更寬範的見解。而解決方案恰恰需要更深入的解釋。

這有助於細節的深入，讓真正的問題浮出水面。問題不在於信任，我們必須信任從資歷最淺的到即將退休的每一位同事，問題在於回答太迅速或將問題最小化。

“更乾淨了”

當有人想說服開發人員選擇一個長度選項或複雜選項時，通常會得到這個答覆。軟體與乾淨與否無關，有使用正確程式碼實現的穩定、可靠的解決方案，也有讓開發人員暴露於範圍蔓延的、不穩定的、棘手的軟體。

說服某人走一條路而不是另一條路，是因為這條路即使實現時間更長，但會更好，你需要給予其動力。

“責任由另一個團隊/人/物承擔”

“這是別人做的”，“這是硬體問題”，“這是後端問題”，筆者聽過太多次這樣的話了。

這是完全錯誤的軟體開發方法。在多團隊專案中工作時，開發出可工作的軟體是共同使命。及時完成專案，產出可靠，是大家共同關心的問題。簡單地把責任推卸到另一個部門並不是什麼好辦法。一個高階開發人員不會讓別人沉迷在錯誤中，而是幫助他們快速理解問題所在。

大多數專案是使用兩個獨立的團隊（前端和後端）實現的，其實這種情況很普遍。筆者相信別人說“不是我的錯”，但我們需要向前邁進一步，需要把目前得到的資訊傳遞給另一個團隊，然後一起進行測試。這不是責任問題，而是承諾問題。

當不確定問題出在哪裡，而只是指出硬體的時候，也是一個意思。如果沒有正確的資訊，系統管理將如何提供幫助？如何確定這些問題是由於客戶端螢幕解析度而不是一個漏洞造成的？如何處理這個棘手的螢幕解析度問題？

也許只要透過一些努力，就可以解決這個問題。

永遠不要相信開發人員，要相信可工作的程式碼

作為一個開發者，筆者可以告訴大家：永遠不要相信開發人員！這不是誠信問題，這只是開發人員工作的難度使然。在理論和實踐之間，任何事情都有可能發生，特別是對於初級開發人員而言。

在大專案中，沒有人能完全知道所有需要了解的事情。通常，開發人員可以根據任務中編寫的內容來執行任務，因為他對業務邏輯一無所知。這意味著每次誤解都會導致錯誤。

要信任開發人員並與他有效地工作，最好的方法是理解他的工作，並向他解釋你的需求，告訴他為什麼需要做一些事情。在一個具有防錯指南的非常結構化的專案裡，以任務為導向的方法（現在就做）十分奏效。

請相信程式碼！

開發工作的難度導致了上述這些小謊言有時是不可避免的，意識到它們的存在是改變的第一步。