作為首席軟件開發(fā)人員，我收集了一些我經(jīng)常在日常工作中積極使用的原則。這些原則是隨機列出的，有些甚至可能相互矛盾，然而，它們都是有幫助的，并且易于應用。

成為域名專家。

你知道在不成為你編寫代碼的業(yè)務專家的情況下，生產(chǎn)有效的優(yōu)質(zhì)軟件有多難嗎？

你可能確實知道。開發(fā)人員經(jīng)常與他們一無所知的企業(yè)和領域合作。但讓我告訴你，在大多數(shù)情況下，領域?qū)I(yè)知識勝過技術知識。

只有技術知識，你才能在技術上正確地做錯誤的事情，這比什么都不做更糟糕。

盡你所能尋求所有的領域知識。吸收它。把它寫下來。隨時把它放在手邊。

想要更多這樣的文章嗎？在這里注冊。

小而大。

這適用于很多事情。構建小功能比構建大功能要容易得多。在小團隊中發(fā)展比在大團隊中更容易發(fā)展。三個人比六個人協(xié)調(diào)得更好。比起少數(shù)大類，小班級系統(tǒng)更受歡迎。

小通常是要走的路，有時制作一口大小的碎片也更難。復雜性很難隱藏在小地方，但原生于大。

擱置新的，以修復舊的。

不可否認，從頭開始構建綠地項目和全新的功能比修復一些舊的性能問題或古怪的界面更令人滿意。

我明白了。

新是有趣的。正是它吸引了所有的注意力。但是，修復舊代碼中的東西，即通常是生產(chǎn)軟件，通常比構建新功能更重要?？蛻粽谫徺I已經(jīng)在那里的東西，如果那里的東西壞了，那么客戶就會離開。

您可以從錯誤修復和性能優(yōu)化中獲得很好的學習，確保您將構建的新東西在這些學習的基礎上變得更好。

創(chuàng)建測試，證明錯誤已修復。

修復任何錯誤的第一步通常從創(chuàng)建一個測試開始，該測試使用導致程序失敗的確切數(shù)據(jù)。您會想自信地重現(xiàn)錯誤。如果你做不到，你怎么能確定你正在修復正確的事情？

每當我修復生產(chǎn)中發(fā)現(xiàn)的錯誤時，我都會盡可能地模仿實際情況。我們是否從數(shù)據(jù)庫中獲取數(shù)據(jù)？確保使用真正的數(shù)據(jù)庫，例如使用測試容器。我們是否調(diào)用了外部HTTP API？發(fā)出與API返回的實際響應相同的調(diào)用。文件是從磁盤加載還是寫入磁盤的？做同樣的事情。

更進一步。調(diào)查導致錯誤的原因。是疏忽嗎？分配的開發(fā)人員是否不夠熟練？我們做了草率的代碼審查嗎？這是一個寫得不好還是模棱兩可的用戶故事？接受標準不完整嗎？

如果您不知道導致錯誤的根本原因，您將如何防止未來的錯誤？錯誤不僅僅是因為開發(fā)人員搞砸了。

假設人們盡其所能。

假設軟件開發(fā)中的任何事情都是一個壞主意。然而，有一個例外?？偸菑募僭O開始，即人們用他們擁有的時間、知識、資源和能力，盡其所能地完成工作。人們通常不喜歡做出錯誤的決定、編寫錯誤的代碼、從事惡意行為和忽視。

一定要認識到錯誤和缺點源于時間限制、知識差距和有限的資源。

這不是借口高級或首席開發(fā)人員不知道自己在做什么。這只是試圖強迫細致入微的思考，而不是公然批評他人的作品。

在極少數(shù)情況下，我聽到開發(fā)人員說類似“我不確定這應該如何運作。如果錯誤，我們將讓QA創(chuàng)建一個錯誤票?！辈灰屜衲菢拥脑u論滑動。如果你需要在那里進行一次不舒服的談話，那就進行吧。沒有這種愚蠢的空間。

我明白你可能想把它推到QA來弄清楚。也許甚至經(jīng)常。但是，退后一步，做點別的事情?；貋砗螅欢ㄒ獙で竽阈枰乃谐吻?。問問你需要的人。展示示例。演示不同的方法，做任何你需要做的事情來灌輸你所做的事情的確定性也是正確的事情。

想要更多這樣的文章嗎？在這里注冊。

不要解決模糊的問題。

始終在開發(fā)過程的早期尋求澄清。這一核心原則是一個至關重要的價值觀，它強調(diào)在開始實際開發(fā)工作之前，需要深入了解需求、制約因素、期望、質(zhì)量水平和時間框架。

了解任務或功能的重要性，并確定能夠幫助您的最有知識的人。認識到您經(jīng)常會遇到未知的未知情況，特別是在進入新域時。通過在整個開發(fā)過程中不斷尋求澄清來保持積極主動的方法。在您開始實施潛在解決方案之前，請花點時間考慮以下問題來評估您的準備情況：

• 我知道該向誰尋求幫助嗎？
• 我知道什么時候該尋求幫助嗎？
• 當不確定功能及其所需功能時，我知道請求澄清的有效方法嗎？

我喜歡問業(yè)務分析師或產(chǎn)品負責人“你沒有問我什么問題來表明我理解這一點？”

擁抱約束。

我知道我剛剛說了，但我會再說一遍：在沒有限制的情況下編寫任何好的軟件都非常非常困難。

制約因素阻止我們過度工程、鍍金、專注于所有錯誤的事情，以及制造不可理解的架構和系統(tǒng)。了解功能的約束使設計、實現(xiàn)和評估變得容易得多。你知道它的界限，以及應該有什么可能。測試和驗證很容易。

當涉及到構建一個功能時，情況正好相反，你不知道它的邊界在哪里。你會如何測試它？

殺了你親愛的。

據(jù)我所知，一個植根于寫作的原則。我第一次聽到這個表達是在本科學習時。

對我來說，在軟件開發(fā)中，這意味著刪除任何不符合目的或不必要的代碼或評論。這也許是你最好的作品。你寫的最有創(chuàng)意的代碼。但是，如果它只是為了你的自我放縱，那么它必須離開。

盡早為進化而構建。

提前考慮。這個功能將如何演變？我們有可能把這個換掉嗎？我們稍后會添加更多選項嗎？

提前思考是便宜的。構建進化比重新利用現(xiàn)有代碼更容易、更安全?？紤]可擴展性點和實現(xiàn)功能，以便它們可以交換、擴展或修改，通常是一項不錯的投資。

我鼓勵每個開發(fā)人員獲得良好的商業(yè)政策和規(guī)則。雖然政策通常保持相當穩(wěn)定，但構成政策的規(guī)則經(jīng)常變化。

這不是金盤所有東西的免費通行證。構建靈活的代碼是關于預測，并最終允許改變，也是關于深思熟慮地權衡不允許改變的后果。

做一個專業(yè)人士。

始終以專業(yè)的方式展示自己，展示自己的行為和技術能力。不要從事單身或競爭性講故事。根據(jù)客戶的條件與客戶溝通。永遠不要垃圾談論現(xiàn)有代碼、前同事和工作場所。避免參與指責游戲、指責轉移和替罪羊。

分享戰(zhàn)爭故事是可以的，但不要在上面寫上名字。

作為一名專業(yè)人士顯然不是軟件開發(fā)所獨有的事情，但不幸的是，我確實認為許多軟件開發(fā)人員具有獨特的能力，可以在工作場所表現(xiàn)得非常不專業(yè)。