全文共2350字，預計學習時長8分鐘
圖源：unsplash
筆者就是一個開發人員。對我來講，開發者不僅僅是一份工作，更是一種心態，不能輕易放棄。對於那些滿懷激情地從事這個職業的人來説，做開發可能會上癮。
作為一名開發人員，我在職業生涯中遇到過許多挫折，處理過很多棘手情況。我承擔過團隊領導的角色，後來又擔任了首席技術官（CTO）。這些都曾改變了我的一些觀點，在觀察團隊成員的過程中，我也很快開始審視自己。
如何證明自己能夠避免錯誤，並促使人們找到正確的解決方案，從而避免陷阱，這是一個有趣的話題。這並不是因為我有什麼超能力，只是由於犯的錯誤比他們多。本文中，筆者將直面每個開發人員無意中對他人（但首先是對自己）説的小謊言。
筆者不是要評判任何人。開發是世界上最複雜的工作之一，特別是對一個初級人員而言，或者對在一個結構不太完善的團隊而言。開發人員的小謊言來自於這項工作的難度。
“成功了”
這個藉口有很多種變體，但都會導致相同的情況：測試好的東西在別人使用時不起作用。這可能是因為測試時不夠準確，也可能是由於測試過程中的兩極分化，即開發者創建了一種功能，但只使用了一種直接的方式，而最終用户使用時需即興發揮。
問題不在於為什麼本應起作用的東西失靈了。開發人員無法相信——他測試時是奏效的，為什麼現在無法工作了?沒人否認這個功能在某個時候起過作用，問題在於，這兒確實有一個漏洞需要解決。
圖源：unsplash
軟件是問題的解決方案
我們生活在一個任何事情都可以用軟件來完成的世界，軟件是我們的良藥。需要時間表怎麼辦？打開的標籤太多怎麼辦？使用軟件就OK。
我們試圖用應用程序或軟件去解決生活中的任何問題。這個過程是數字轉換的一部分，但軟件只是一個工具。用Dijkstra的話來説，要求軟件解決企業問題就像要求潛艇游泳一樣。年輕的開發人員看到了CRM或任何SaaS解決方案等軟件的威力，認為它們可以解決所有問題，但實際可能比想象的要難得多。
這並不是工具的問題。最商業化的解決方案所提供的比普通需求多得多。問題是來自於公司的。在採用工具之前，必須調整流程，並通過培訓和文化培育來支持這種變化。
如果產品不好或者品牌太弱，那麼沒有任何電子商務解決方案可以提高銷售額；如果銷售團隊不瞭解正在銷售的產品，那麼沒有任何CRM能有助於銷售的推進。軟件解決方案是一種推動力，所以當開發人員提出一個解決方案時，請思考一下需要付出哪些努力才能使這種無用的東西開始生效。
“我們什麼都能做，只是時間問題”
圖源：unsplash
當需要設計複雜的解決方案時，時間是一個關鍵的點。例如，創建Facebook顯然比創建一個簡單的網站需要更多的時間。
但問題是，時間不是唯一重要的東西。正確的答案應該是“如果我們有時間、能力和經驗的話，我們可以做到。”但我們往往不願意承認有些事情對我們來説太困難了。
“別擔心”
聽到“別擔心”或“相信我”之類的話時，你應該敲響警鐘。
我們總是思考因果關係的邏輯。事情不發生，就不會有任何後果嗎？觀點會受到個人經驗和認知的限制，在複雜的情況下，我們很難有更寬範的見解。而解決方案恰恰需要更深入的解釋。
這有助於細節的深入，讓真正的問題浮出水面。問題不在於信任，我們必須信任從資歷最淺的到即將退休的每一位同事，問題在於回答太迅速或將問題最小化。
“更乾淨了”
當有人想説服開發人員選擇一個長度選項或複雜選項時，通常會得到這個答覆。軟件與乾淨與否無關，有使用正確代碼實現的穩定、可靠的解決方案，也有讓開發人員暴露於範圍蔓延的、不穩定的、棘手的軟件。
説服某人走一條路而不是另一條路，是因為這條路即使實現時間更長，但會更好，你需要給予其動力。
圖源：unsplash
“責任由另一個團隊/人/物承擔”
“這是別人做的”，“這是硬件問題”，“這是後端問題”，筆者聽過太多次這樣的話了。
這是完全錯誤的軟件開發方法。在多團隊項目中工作時，開發出可工作的軟件是共同使命。及時完成項目，產出可靠，是大家共同關心的問題。簡單地把責任推卸到另一個部門並不是什麼好辦法。一個高級開發人員不會讓別人沉迷在錯誤中，而是幫助他們快速理解問題所在。
大多數項目是使用兩個獨立的團隊（前端和後端）實現的，其實這種情況很普遍。筆者相信別人説“不是我的錯”，但我們需要向前邁進一步，需要把目前得到的信息傳遞給另一個團隊，然後一起進行測試。這不是責任問題，而是承諾問題。
當不確定問題出在哪裏，而只是指出硬件的時候，也是一個意思。如果沒有正確的信息，系統管理將如何提供幫助？如何確定這些問題是由於客户端屏幕分辨率而不是一個漏洞造成的？如何處理這個棘手的屏幕分辨率問題？
也許只要通過一些努力，就可以解決這個問題。
永遠不要相信開發人員，要相信可工作的代碼
圖源：unsplash
作為一個開發者，筆者可以告訴大家：永遠不要相信開發人員！這不是誠信問題，這只是開發人員工作的難度使然。在理論和實踐之間，任何事情都有可能發生，特別是對於初級開發人員而言。
在大項目中，沒有人能完全知道所有需要了解的事情。通常，開發人員可以根據任務中編寫的內容來執行任務，因為他對業務邏輯一無所知。這意味着每次誤解都會導致錯誤。
要信任開發人員並與他有效地工作，最好的方法是理解他的工作，並向他解釋你的需求，告訴他為什麼需要做一些事情。在一個具有防錯指南的非常結構化的項目裏，以任務為導向的方法（現在就做）十分奏效。
請相信代碼！
開發工作的難度導致了上述這些小謊言有時是不可避免的，意識到它們的存在是改變的第一步。
