茶歇 #13：每個程式新手都應該知道的內容；將設計思維融入開發流程的 4 種方法

每個程式設計新手都應該知道的事情

來源：Stackoverflow 身為開發人員，您會聽到許多關於程式碼應該是什麼樣子的不同理論。有些人認為應用程式的程式碼行越少，就越容易閱讀。但這只是部分正確。我更喜歡使用以下標準來評估程式碼品質：

1. 代碼應該一致、資訊豐富且有據可查。
2. 程式碼應該使用穩定、現代的功能。
3. 程式碼不應過於複雜或損壞。

如果您決定以犧牲上述標準之一為代價來減少程式碼行數，這將成為一個問題。不要那樣做。

閱讀別人的程式碼很困難

確實，閱讀和編寫程式碼所花費的時間比例超過10比1。但是你不能不閱讀別人的程式碼。您將必須閱讀別人的程式碼。越早提高技能越好。嘗試使用開放的 GitHub 儲存庫研究其他人的程式碼。你可以隨時練習：找到一個適合你的項目，深入每一行。提高閱讀他人程式碼能力的另一種方法是開始複製樣式。當你以別人的風格編寫程式碼時，不僅可以提高你的閱讀能力，還可以讓你更熟悉程式碼。試一試。

你永遠不會寫出「完美」的程式碼

在開始團隊工作之前，我擔任了四年的獨立開發人員。在大部分時間裡，我相信任何有經驗的程式設計師都會寫出完美的程式碼。在我看來，學習編寫完美的程式碼只是時間和精力的問題。但當我加入團隊時，我發現沒有人能編寫「完美」的程式碼。確實，最終包含在系統中的程式碼幾乎總是「完美的」。為什麼會發生這種情況？這都是關於程式碼分析的。我與一群真正才華橫溢的工程師一起工作。這些是金錢可以僱用到的最有能力、最有信心的程式設計師。但如果有人建議在應用程式中包含未經測試的程式碼，他們每個人（包括我）都會感到真正的恐慌。即使你認為自己是下一個比爾蓋茨，你也會犯錯。我甚至不是在談論邏輯錯誤，我是在談論拼字錯誤、缺少字元。您的大腦有時無法捕捉到的事物。只有用新鮮的眼睛才能注意到的事。努力與注重細節並願意批評你的工作的人一起工作。一開始很難接受批評，但這是提高程式碼品質的唯一可靠方法。在審查程式碼時盡量不要採取防禦態度，也不要把批評當成是針對你個人的。你不是你的程式碼。

你不應該每天寫8小時程式碼

沒有人可以準確地告訴您他們每天花多少時間編寫程式碼。但現實中，很少人每天寫程式超過 4 小時。不同意這一點的人要不是規則的例外，就是在對待員工不好的公司工作。程式設計是一項強度大、耗費腦力的工作。認為有人會每週 5 天、每天 8 小時編寫程式碼的想法是完全錯誤的。在極少數情況下，您需要在截止日期前完成工作，但當我說很少時，我的意思是幾乎從不。不要讓工作壓垮你並迫使你加班。我並不是建議你每天只工作四小時。剩下的四個小時通常最好花在以下事情上：

• 學習新的工具、功能、應用；
• 與同事討論工作流程；
• 幫助工作上遇到困難的同事；
• 任務規劃；
• 代碼分析；
• 商務會議/會議。

我還強烈建議全天定期休息並鍛鍊身體（至少一點點）。運動的正面作用早已被證明。

將設計思維融入開發流程的 4 種方法

Source Tech Beacon 要創建滿足客戶需求的產品，您必須考慮他們的需求。如果您編寫的應用程式具有令人困惑的導航或不必要的長加載介面，請為未來的失敗做好準備。作為一名程式設計師，您可能必須更深入地研究您的團隊正在開發的產品的設計。這種協作非常有用，因為每個人都會注意到對方可能沒有註意到的事情。我為您提供 4 個關於開發人員和設計師如何合作的技巧。

1. 從一開始就參與

不要認為設計總是第一位的，開發是第二位的。這可能是真的，但這並不意味著開發人員不應該參與設計過程。程式設計師能夠提供有關如何實施專案的重要技術信息，而設計師則能夠更好地了解使用者的需求。最好儘早找出哪些功能在技術上是不可能的或不能滿足使用者的要求。如果設計人員和開發人員一起工作，可以立即發現並解決問題，而不是在設計批准之後。許多公司採用協作方法進行軟體開發。這意味著團隊成員不僅要對自己的階段或程式碼片段負責，還要對從設計到測試的所有事情承擔集體責任。

2.了解使用者體驗流程

那些不熟悉 UX（使用者體驗）的人可能不明白為什麼團隊會為了看似微不足道的細節而一遍又一遍地改變設計。使用者體驗流程中的每一步都有一個原因：為使用者提供盡可能最佳的體驗。因此，從一開始就注意創建使用者體驗流程非常重要。它可能包括：

• 研究項目的目的；
• 建立線框 - 一個簡單的設計，可讓您確定產品的主要特徵；
• 為專案設計添加更精細的細節，例如使用者介面；
• 用戶測試設計。這可能是使用者體驗開發最重要的階段。在您花時間開發產品之前，這可以提供有關該產品的寶貴資訊；
• 迭代：透過測試結果的分析，迭代設計以改善使用者體驗。

團隊多次重複設計和測試步驟，直到沒有任何變更或時間允許為止。這通常意味著您將擁有設計的多個版本。

3. 追蹤設計開發

當設計師在沒有諮詢開發人員的情況下創建專案時，這是非常糟糕的。這是適得其反的。對於 DevOps 來說，設定規則非常重要，以便開發人員能夠以易於存取的格式（例如 PNG 或 PDF）存取設計藍圖。開發人員和設計人員之間的有效協作對於應用程式的成功實施至關重要。不惜一切代價避免盲目地交付完成的設計。最好在開始時糾正錯誤，而不是在最後糾正錯誤。

4. 同意專案將在哪個階段向您展示

當開發人員被要求創建產品的最小可行版本（MVP）時，他們需要從一開始就了解最終版本的要求。這是避免不合理期望出現問題所必需的。設計人員必須向開發人員展示設計的兩個版本：MVP 和最終版本。這將有助於實現 MVP，同時考慮到客戶期望在最終版本中看到的內容。當設計師和開發人員一起工作時，他們可以獲得很多好處。他們每個人都有可以應用於另一個人的經驗的知識。開發人員可以提供有關設計中無法實現哪些功能的寶貴見解。另一方面，與程式設計師的協作將使設計師免於重做項目，從而節省整個團隊的時間。