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

成為域名專家。

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

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

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

盡你所能尋求所有的領(lǐng)域知識(shí)。吸收它。把它寫下來。隨時(shí)把它放在手邊。

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

小而大。

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

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

擱置新的，以修復(fù)舊的。

不可否認(rèn)，從頭開始構(gòu)建綠地項(xiàng)目和全新的功能比修復(fù)一些舊的性能問題或古怪的界面更令人滿意。

我明白了。

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

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

創(chuàng)建測(cè)試，證明錯(cuò)誤已修復(fù)。

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

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

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

如果您不知道導(dǎo)致錯(cuò)誤的根本原因，您將如何防止未來的錯(cuò)誤？錯(cuò)誤不僅僅是因?yàn)殚_發(fā)人員搞砸了。

假設(shè)人們盡其所能。

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

一定要認(rèn)識(shí)到錯(cuò)誤和缺點(diǎn)源于時(shí)間限制、知識(shí)差距和有限的資源。

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

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

我明白你可能想把它推到QA來弄清楚。也許甚至經(jīng)常。但是，退后一步，做點(diǎn)別的事情?；貋砗?，一定要尋求你需要的所有澄清。問問你需要的人。展示示例。演示不同的方法，做任何你需要做的事情來灌輸你所做的事情的確定性也是正確的事情。

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

不要解決模糊的問題。

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

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

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

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

擁抱約束。

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

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

當(dāng)涉及到構(gòu)建一個(gè)功能時(shí)，情況正好相反，你不知道它的邊界在哪里。你會(huì)如何測(cè)試它？

殺了你親愛的。

據(jù)我所知，一個(gè)植根于寫作的原則。我第一次聽到這個(gè)表達(dá)是在本科學(xué)習(xí)時(shí)。

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

盡早為進(jìn)化而構(gòu)建。

提前考慮。這個(gè)功能將如何演變？我們有可能把這個(gè)換掉嗎？我們稍后會(huì)添加更多選項(xiàng)嗎？

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

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

這不是金盤所有東西的免費(fèi)通行證。構(gòu)建靈活的代碼是關(guān)于預(yù)測(cè)，并最終允許改變，也是關(guān)于深思熟慮地權(quán)衡不允許改變的后果。

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

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

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

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