🔍 搜尋結果:寫測試

🔍 搜尋結果:寫測試

德國資深架構師:給新手工程師的幾點建議

一名資深的德國軟體架構師 Jeroen De Dauw,寫了一篇很好的文章,給新手工程師一些寫程式的建議。 - 原文出處:https://dev.to/jeroendedauw/advice-for-junior-developers-30am --- ## 給新手工程師的一般建議 ### 1. 程式碼不是重點 作為開發者,我們喜歡寫程式。大多數工程師希望收到的任務明確,可以不用管技術之外的事情,專心解決有趣的技術挑戰。 請花足夠的心力去確認,您正在解決正確的問題。引用管理學大師 Peter Drucker 的話:高效率地去做一件根本沒必要的事情,結果依然是完全沒意義。儘早、經常去搜集回饋,透過「持續交付」來向真正的用戶互動,成為敏捷(Agile)的工程師。 軟體開發成本高昂,現實世界專案的絕大部份工作都是在維護而已。再加上目標應該是對用戶、對生意有幫助,所以結論就是:寫程式最好的方法,經常是完全不寫。引用比爾蓋茲的話:用程式碼有幾行來衡量工程進度,就像用重量來衡量飛機的製造進度。 另請參閱:YAGNI 原則、KISS 原則、The Last Responsible Moment 文章。 ### 2. 軟體設計很重要 在我開發生涯的前五年,我以為軟體設計是架構師或其他特殊職位的人在做的事。我以為開發者專注在完成任務即可,以為軟體設計、最佳實踐、寫測試這些,都不關我的事。我的程式能跑,我的生產力很高,我以為這樣就對了。 直到我閱讀了 Robert C. Martin 的 Clean Code,這書刺激了我對軟體設計的關注,並包含許多範例與啟發。其中最啟發我的是:走得快的唯一方法,就是走得好。也就是說,如果你把事情搞得一團糟,結果只會讓你速度更慢。 學習寫出設計良好的乾淨程式碼,需要時間和精力。而且剛開始的時候,會寫比較慢,並且會犯錯誤。 ### 3. 使用最佳實踐 寫測試通常會有幫助。雖有例外,但大多數時候,寫自動化測試會大有幫助。寫測試就是一種最佳實踐。 如果你不太會寫測試,請遵循最佳實踐並為所有內容寫測試。**開始時,盲目遵循最佳實踐比遵循自己弱弱的判斷要好**。一段時間之後,您將知道怎麼寫測試比較有效,並能夠區分您搞砸了和不值得編寫測試的情況。因為 bug 變少了、重構起來更輕鬆了,您將開始理解測試帶來的深入的價值。**到有了自己的判斷力後,您將能夠超越最佳實踐**。 此建議適用於您在學習任何最佳實踐的新手時期。自動化測試只是一個例子。 有個陷阱要注意,明智的最佳實踐,與荒謬、適得其反的做法之間,只有一線之隔。因為大多數程式碼都很亂,而且大多數開發者(包括資深人員)不了解軟體設計的基礎知識,因此事情就更複雜了。有一個好的指導者很重要。除此之外,根據我自己的經驗,要小心只存在您的語言、框架社群的最佳實踐。尋找那些已經存在了幾十年的長青建議比較好。 --- ## 給新手工程師的技術建議 ### 4. 寫測試 寫自動化測試。也許在寫程式之前先寫測試,例如運用測試驅動開發(TDD)。這讓您可以輕鬆反覆驗證幾段程式是否正確,而不用一直手動跑測試、除錯。 > 你覺得先寫測試很煩嗎?但之後再忙著抓 bug 有比較好? 更重要的是,測試為您重構時提供了額外保障。你需要持續重構來保持程式乾淨。沒有可靠的測試保障,程式碼就可能越變越亂。 如果您的程式碼設計不佳,例如使用繼承進行重用,或使用靜態函數,則編寫測試會很困難。另一方面,如果您有遵循 SOLID 原則、沒有全局依賴項,那麼寫出好的測試並不困難。 設計好測試也很重要,因為糟糕的測試只會拖慢開發速度。避免將測試綁定到被測程式碼的實作細節或系統結構。 ### 5. 不要用繼承來做到程式碼重用 這是讓人以為是最佳實踐的其中一個反例。我的建議是:剛開始時,根本就不要用繼承來做到程式碼重用。這通常都幫助有限,而且帶來一大堆麻煩。請多用組合、少用繼承(關鍵字:composition over inheritance)。 ### 6. 寫出 OOP 程式碼 學習 SOLID 原則,避免寫出 STUPID 原則的程式碼 ( https://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/ )。理解這些原則和反模式非常有價值。 創造一些真正的物件。只有靜態方法的類別,根本不算是物件導向。盡量避免完全使用靜態寫法。 ### 7. 寫出函數式程式碼 不要把函數式程式設計,跟指令式程式設計搞混了。 重點不是完全切換到函數式語言。而是學習使用函數式風格的優點。例如減少狀態、讓函數專心一件事。另請參閱:https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell ### 8. 程式碼稍微重複沒關係 將一大塊程式碼到處複製貼上當然很不好。有尊嚴的開發者很快就發現這一點,並開始遵循某種形式的:不重複自己原則 Don't Repeat Yourself (DRY)。不幸的是,對 DRY 的追求往往會導致過度工程和額外的複雜性。所以會有一條新原則:寫兩次原則 Write Everything Twice(WET)。也就是僅在第三次出現重複時,才動手改善重複段落。 ### 9. 型別、命名、註解 試著寫一些能夠表達自我的程式碼,避免寫註解。 > 每次寫註解時,都應該要皺一下眉頭,感受到自己的表達能力有點失敗。 —— Robert C. Martin 註解很危險,因為有可能說謊。程式碼可以不更新註解就修改,那一開始的註解就變錯誤了。這種情況下,註解不但沒幫助,還會誤導到別人。 要寫出能夠表達自我的程式碼: - **一個函數只做一件事** 因為只做一件事,就能給一個清楚的命名。 - **減少狀態** - **使用型別** 定義清楚的型別,加上跑測試,能讓系統更穩定。 - **減少混合型別** 避免可以同時是整數、布林值或字串的參數或回傳值。如果讓每個函數專心一件事,這自然會做到。 - **寫測試** 良好的全面測試,也同時會是程式碼的使用說明範例。 Robert C. Martin 的書 Clean Code 在命名和寫註解方面有提供一些很好的經驗法則。 --- 以上,希望對大家有幫助!

軟體工程師:面試的時候,你應該問公司的 36 個重要問題

面試的時候,通常面試官會問:你有什麼問題想問我們嗎? 就跟公司面試你一樣,其實你也在面試公司。應該把握機會問對問題。 這邊有幾個重要問題,給你參考,下次面試可以問問看。 - 原文出處:https://dev.to/semaphore/36-questions-to-ask-your-future-software-employer-552g --- # 可以問人資的問題 面試通常會先跟人資聊聊,有些問題可以先問他們。建議可以問一下公司的運作方式以及面試流程。 ## 關於職位 **1. 公司為什麼要招人?** 這是個暖身問題。可以了解公司的大致狀態。缺人是因為在擴編?還是有人剛離職呢? **2. 這個職位上一個人怎麼樣了?他們是辭職了,還是被開除?** 如果不是擴編,那可以先搞清楚這職位剛發生什麼事。弄清楚這段,可以更了解公司對這個職位的期望。 **3. 公司的離職率是多少?去年僱用了多少開發人員,又有多少人辭職了?團隊中待最久、跟最新進的人員分別是多久?** 這問題可以嗅出一些端倪。高流動率代表工作條件有點問題。可能得不到直接答覆,但別擔心,後面的流程有機會深入討論。 **4.到職流程如何運作?面試過程的下一步是什麼?** 獲取準備下一步所需的資訊。 ## 關於員工生活 **5. 公司是否投資於員工發展、培訓或認證?是否有用於學習活動或參加研討會的預算?** 公司當然喜歡積極進修的員工。所以員工至少要有一點時間能學習或參加活動。如果他們有提供進修預算,那非常加分。 **6. 公司允許遠端工作嗎?我應該在辦公室待多少天?遠端工作者的比例是多少?** 疫情讓遠端成為常態。有些公司 100% 遠端工作。有些公司則是混合辦公。你需要知道公司是哪種 。如果是完全遠端,你要問一下有沒有定期的團建活動,或是聚餐之類的。 **7. 有補助去共享空間工作嗎?** 有些人在家很難專心。這時可以考慮去租共享工作空間。 **8. 有育嬰假嗎?有無薪假嗎?病假和特休等等,怎麼安排?** 如果應徵公告沒有寫清楚,你可以這時先問清楚相關規則。 --- # 技術面試後要問的問題 這時你應該在跟技術人員交談。可能是未來的同事、技術主管、或技術長。 藉此機會暸解工作環境。有些問題可以防止踩雷。 ## 關於每日作息 **9. 通常我一周開幾次會議?** 會議一定會有,但有些公司實在開太多了。這問題可幫助評估,工作時會不會一直被打斷。 **10. 公司有 CI/CD 嗎?或者其他開發流程呢?** DevOps、Scrum、Lean 和 Agile 等術語已被濫用到沒什麼意義了。CI/CD 的意義清楚多了。公司有實踐嗎?如果沒有,代表團隊依賴手動部署、測試。 當然,也有CI/CD不可行的地方。但 99% 的情況下,利大於弊。 **11. 多久部署一次?如何部署?** 關於 CI/CD ,需要知道一天部署幾次。這代表部署流程多順暢。 除非是受到政府監管的產業,不然手動、久久部署一次,代表緩慢又低效率的開發文化。 **12. 你們使用 TDD 還是 BDD?如何寫測試?** 測試驅動開發和行為驅動開發對生產力很有幫助。無論是不是在測試團隊,都應該知道一下公司的測試習慣。如果公司完全不寫測試,那就要小心了。 **13. 你們如何追蹤錯誤/問題?寫功能和修理之間的比例是多少?** 這能幫助了解技術債。有技術債是正常的,但如果太多,你可能就一直在救火、整理超亂的程式碼。 **14. 你們偏好哪種:系統穩定或者快速上新功能?你們對技術債的態度是什麼?** 直接問技術債的態度,但也要知道滿足客戶需求的重視程度。 **15. 文件完整嗎?有程式碼風格指南嗎?有現成的測試規格嗎?** 了解一下文件的習慣。可以詢問 API 規範、技術文件、風格指南、用戶故事之類的。文件不夠通常代表你需要一直開會、一直詢問同事。 測試本身就是一種文件,所以有寫測試也很重要。 ## 工具和文件 **16. 使用什麼版本控制系統?** 如果沒有在用版本控制,建議直接換別間面試。除非你在面試技術長或者技術副總之類的。這情況,要詢問能否導入。如果能,你需要很痛苦的花幾個月導入,談薪水的時候要一併考慮進去。 **17. 使用什麼技術/語言/框架?** 不熟悉也沒關係。通常幾週內就都能上手。 **18. 我可以使用我 ${最愛的 IDE} 嗎?** 用自己最愛的,最棒。 **19.公司有提供設備嗎?我有設備的全部權限嗎?我可以用自己的設備嗎?** 如果在自己的電腦上沒有根權限,代表公司不信任員工。 ## 開發團隊文化 **20. 你為什麼選擇加入這家公司?** 如果跟面試官聊開了,請問一些個人問題。了解你將要為之工作或與之共事的人的價值觀,是很有價值的。 **21. 團隊有多大?新手與資深工程師的比例是多少?** 試著深入了解團隊組成與規模。如果你是應徵初階職位,同事大部分都是資深人士,那就是好事一件。 **22. 有多少女性員工?公司有確保員工多樣性的流程嗎?** 了解一下團隊都是同一種人、或者具有很高多樣性。這對工作氛圍也有影響。 **23. 你在這家公司犯過的最大錯誤是什麼?** 我喜歡這個問題,因為它與「生成式文化」的概念有關。生成式文化是一種風險共擔、鼓勵創新、人們不會因失敗而受到譴責(而是被用作學習機會)的文化。 當人們在心理上感到安全,他們會把握更多機會並進行更多嘗試,從而實現創新。 反例則是,病態或官僚文化。在這種情況下,人們傾向於「謹慎行事」——以免因失敗而受到懲罰。這絕對是很差的工作環境,對你的工作跟心情都很不好。 ## 工作與生活的平衡 **24. 人們平均每週工作多少小時?人們通常什麼時候下班?** 你需要每天早點回家、好好享受生活,才能持續打拼。長期過勞代表團隊生產力很差,只能透過加班彌補。 **25. 有 on-call 的時間表嗎?標準工時以及您對加班的期望?我將多久 on-call 一次?緊急情況或人們被迫加班的頻率有多高?** 這個問題是對上一個問題的補充。一個月通常要加班幾次? 大量加班、習慣性的周末工作以及不頻繁、手動部署,是工作與生活不平衡的跡象。如果公司有這些危險信號,請繼續貨比三家。 **26. 我是否需要一直在 Slack/Teams 上面,還是可以分批處理我的工作?** 我常常在沒有鍵盤的時候解決問題。常常在散步或洗澡的時候有新想法。能夠離開電腦散步一下,生產力會更好。 --- # 向經理、首席執行長或創辦人提出的問題 痛苦的技術面試完成後,你可能會見到經理、首席執行長、甚至創辦人。可以把握機會了解公司在市場上的表現、也能讓公司知道你對公司很有興趣。 ## 關於公司 **27. 有公司運作 SOP 嗎?** 查看各種 SOP 可以知道公司的運作方式,讓新員工快速進入狀況。 **28. 公司是怎麼賺錢的?損益兩平了嗎?成長速度有多快?** 如果在面試新創公司,獲利需要好幾年的時間,而且機率不高。所以,你其實正在賭一個高風險、高報酬的事情。 您的專業成長通常會反應到公司的成長。如果你追求穩定並打算待好幾年,那麼選擇一家現金流穩定的老牌公司比較好。 **29. 公司或團隊現在面臨的最大挑戰和機會是什麼?** 開放式問題可以讓你深入了解公司的目標和管理層的心態。檢查您的職涯目標是否與公司的目標一致。 **30. 您認為未來 5/10 年後,公司會在哪?** 面試的時候,被問這個是最難回答的。所以你當然也要問公司,這樣才公平。 **31. 公司如何設定季度/年度目標?這一季/今年的目標是?** 如果沒有公司或團隊目標,那麼您要么是在與錯誤的人交談,要么是在與錯誤的公司交談。 對公司的目標表現出興趣,更重要的是,了解當季、當年的優先事項。是否使用 OKR 管理?如果沒有,那是用什麼規劃目標?如何評估成效? ## 關於職位 **32. 你如何定義我這個職位的成功?你希望我在頭 3 個月內完成什麼?您將如何評估我在試用期的表現?您如何確定某人是否適合您的公司?** 你需要了解試用期如何評估。 **33. 績效考核如何進行?升遷流程如何運作?績效考核與加薪掛鉤嗎?** 您和您的主管可能對成功有不同定義。但績效評估使您、您的主管和公司保持一致。雖然很可怕,但能促進人員和公司的持續改進。這是主管提供回饋、認可成就並提供職業發展指導的好時間。 沒有績效評估,就沒有回饋,晉升或加薪的機會也很小。 **34. 我有多少自主權來決定要做什麼?工作的優先順序如何?是否有分配用於副專案/實驗的時間?** 弄清楚有多大自主空間,藉此了解團隊目前專注什麼。 如果有分配用於副專案/實驗的時間,那就太幸運囉。 ## 提升職業生涯 **35. 我的主管會定期進行一對一的交流嗎?** 一對一對於讓你和主管保持一致非常重要 **36. 我可以為 XXX 開源專案做貢獻嗎?可以去研討會演講嗎?是否需要任何批准?** 如果你有這些興趣,就要問問。這些都是職業發展的寶貴機會。 --- # 結論 公司會展現好的一面,吸引面試者。你需要看穿表面宣傳、弄清楚真實狀況。找到有興趣的問題,不斷提問,直到放心為止。 不要問你本來就該知道的事情。職位描述看清楚,公司網站跟之前的對話看清楚,問重複問題會很鳥。 祝你好運,感謝閱讀!

資深軟體工程師:10年經驗教會我的20件事情!

在軟體產業工作超過十年之後,我總結出了二十條原則,跟大家分享如下: - 原文出處:https://dev.to/ondrejsevcik/20-principles-i-learned-from-10-years-of-developing-software-5354 1. **謙虛**——世界上沒有無所不知的工程師,你也一樣。 2. **先讓它能跑,再讓它正確**——可能的話,再讓它更快。 3. **修改時再優化**——寧可出現重複,也不要出現錯誤的抽象化設計。 4. **始終寫測試**——如果您不寫測試,那麼您就是在手動測試。 5. **解決 80% 的使用情境就好**——你永遠無法解決所有人的問題。 6. **盡量用函數式編程**——比較容易理解。如果您的程式碼需要博士學位才能看懂,那你的方法有點問題。 7. **刪除越多程式碼越好** 8. **足夠好勝於完美**——不要僅僅因為它不完美,就放棄有意義的改進。 9. **私下批評,公開表揚** 10. **做筆記**——如果你認為你會記住它,那你就是在自欺欺人。 11. **與您的用戶溝通**——最好的軟體是由對用戶有同理心的工程師開發的。 12. **有意識地學習**——練習時要牢記一個明確而具體的目標 - 你想要改進什麼以及如何改進(刻意練習)。 13. **不要過早概括**——等到你有至少 3 段重複的程式碼,再進行抽象化(又名:三規則)。 14. **修復破損的窗戶**——代碼中的一段技術債會導致另一段技術債。您的程式碼很快將變得難以管理。 15. **解決問題**——不管是誰的錯,都是你要負責解決。 16. **做有用的事,而不是時髦的事**——先和一個小團隊一起嘗試。如果可行,請擴大實施。如果不行,則中止。 17. **良好的休息才有最佳成果**——定期休息對於獲得最佳表現至關重要。你也不會認為專業短跑運動員一直在短跑吧。 18. **採取小步驟**——大的重寫是行不通的。您將在過程中失去動力和注意力。試著每天發布更新。它使您可以在必要時,自由地調整重點。 19. **表揚出色的工作**——我們在動物身上觀察到的這件事,同時也適用於人類。當你表揚人們的好表現而不是懲罰他們的壞表現時,你會得到更好的結果。 20. **完美的代碼不存在**——最好接受這事實,而不是浪費時間、追逐不可能的事情。