期間:2016
Dominion 第二版
Dominion 基本遊戲和陰謀的第二版
函式長度
在我的職業生涯中,我聽過許多關於函式長度應該多長的爭論。這是更重要問題的代理問題 - 什麼時候我們應該將程式碼封裝在自己的函式中?其中一些準則基於長度,例如函式不應大於螢幕上可容納的長度。有些則基於重複使用 - 任何使用超過一次的程式碼都應放入自己的函式中,但僅使用一次的程式碼應保留在內聯中。然而,對我來說最有意義的論點是意圖和實作之間的分離。如果您必須花費精力查看程式碼片段才能找出它在做什麼,那麼您應該將其提取到一個函式中,並將該函式命名為「什麼」。這樣,當您再次閱讀它時,函式的目的就會立即跳出來,而且大多數時候您不必關心函式如何實現其目的 - 也就是函式的本體。
隱藏精度
有時當我處理一些資料時,那些資料比我預期的更精確。有人可能會認為這是一件好事,畢竟精度是好的,所以越多越好。但隱藏精度可能會導致一些微妙的錯誤。
洛夫萊斯與巴貝奇的驚險歷險
在蒸汽龐克口袋宇宙中引人入勝的卡通組合,以及關於電腦先驅及其真實維多利亞時代世界的資訊性註腳。
值物件
在編寫程式時,我常發現將事物表示為複合體很有用。2D 座標包含 x 值和 y 值。金額包含數字和貨幣。日期範圍包含開始和結束日期,而日期範圍本身可以是年、月和日的複合體。
在這樣做的過程中,我遇到了兩個複合物件是否相同的疑問。如果我有兩個點物件,都表示笛卡兒座標 (2,3),將它們視為相等是有道理的。由於其屬性的值(在本例中為 x 和 y 座標)而相等的物件稱為值物件。
別名錯誤
當透過多個參照存取相同的記憶體位置時,就會發生別名。這通常是一件好事,但它經常以意外的方式發生,導致令人困惑的錯誤。
水煮紅蘿蔔
在我成長的過程中,我討厭紅蘿蔔,討厭它們的味道和質地。但是在我離家開始自己煮飯後,我開始喜歡它們。紅蘿蔔本身沒有改變,我的味蕾也沒有徹底改變,差別在於烹飪方式。我母親和其他許多那一代的英國人一樣,並不是一位很棒的廚師,特別是煮蔬菜。她的做法是將紅蘿蔔煮二十分鐘以上。我後來學到,如果你正確地烹飪它們,紅蘿蔔會帶來完全不同的體驗。
這不是一個關於烹飪的網站,而是關於軟體開發的網站。但我發現,一種技術或工具通常就像可憐的紅蘿蔔一樣,被指責很糟糕,而實際的問題是技術執行不正確。
雙峰 IT
雙峰 IT 是有缺陷的概念,認為軟體系統應該分成這兩個不同的類別,以便管理和控制。
- 前端系統(參與系統)應針對快速功能開發進行最佳化。這些參與系統需要快速回應不斷變化的客戶需求和商機。應容忍缺陷,因為這是快速開發週期的必要成本。
- 後端系統(記錄系統)應針對可靠性進行最佳化。作為記錄系統,重要的是不要出現會損害企業的缺陷。因此,你會降低變更速度。
無伺服器
無伺服器架構是基於網路的系統,其中應用程式開發不使用一般的伺服器程序。相反地,它們僅依賴第三方服務、用戶端邏輯和服務託管的遠端程序呼叫 (FaaS) 的組合。
YAaaS
YAaaS:又一個即服務
現今一切事物似乎都需要「即服務」,因此我們需要一個元術語來描述這種語言趨勢。感謝我的同事 Birgitta Böckeler 提出這個術語。現在我們可以說「FaaS 是『函數』的 YAaaS」。
以業務能力為中心的
以業務能力為中心的團隊,其工作長期與業務的特定領域保持一致。只要所述業務能力與業務相關,團隊就會存在。這與專案團隊形成對比,專案團隊僅持續到交付專案範圍的時間為止。
以活動為導向
任何重大的軟體開發工作都需要執行多項不同的活動:分析、使用者體驗設計、開發、測試等。以活動為導向的團隊圍繞這些活動組織,因此您有專門的團隊負責使用者體驗設計、開發、測試等。以活動為導向承諾許多好處,但軟體開發通常最好使用 以成果為導向 的團隊。
以成果為導向
贊助軟體開發的人通常對開發指標(例如速度或部署到生產的頻率)不太感興趣。他們更關心軟體將提供的業務效益,例如降低手動工作、提高銷售轉換率、提高客戶滿意度,也就是業務成果。以成果為導向的團隊是受委託並具備提供業務成果的能力,此類團隊擁有能夠執行所有必要活動以實現成果的人員。相比之下,以活動為導向 的團隊既沒有設備也沒有受委託這樣做。他們只能執行實現成果所需的幾項活動之一。
重構 JavaScript 影片商店
計算和格式化一家影音出租店的帳單這個簡單的範例,開啟了我在 1999 年的重構書籍。如果用現代的 JavaScript 來做,你可以採取好幾種重構方式。我在這裡探討四種:重構到頂層函式、使用帶有分派器的巢狀函式、使用類別,以及使用中間資料結構進行轉換。
演化式資料庫設計
在過去十年中,我們開發和改進了許多技術,讓資料庫設計可以在應用程式開發時進行演化。這對於敏捷方法來說是非常重要的功能。這些技術仰賴於將持續整合和自動化重構套用於資料庫開發,同時讓資料庫管理員和應用程式開發人員密切合作。這些技術可以在前置作業和已發布的系統中運作,無論是全新專案或舊有系統都適用。
生而為此
社交能力差、白人、男性程式設計師的刻板印象已經存在很長一段時間了。儘管「科技業的多元性」是一個備受討論的話題,但數字並沒有因此而有所改善。相反地,許多科技業內外的人士仍然認為這個刻板印象是自然規範,而這種認知正是阻礙我們讓這個行業變得更具包容性和吸引力的因素之一。那麼,這個形象從何而來?全球程式設計師人口的統計資料真的自然而然地演變,是因為「男生就是比較喜歡電腦」嗎?是什麼形塑了我們對程式設計師的認知?本文探討了一些我在閱讀電腦歷史時發現的可能解釋。
不僅僅是站著:每日站立會議的模式
每日站立會議已成為許多團隊的常見儀式,特別是在敏捷軟體開發中。然而,許多細微的細節區分了有效的站立會議和浪費時間的會議。