松花皮蛋的黑板報
  • 分享在京東工作的技術感悟,還有JAVA技術和業內最佳實踐,大部分都是務實的、能看懂的、可復現的

掃一掃
關注公眾號

ARTS-21-避免過度設計

博客首頁文章列表 松花皮蛋me 2019-08-04 23:06

ARTS的初衷

Algorithm: 主要是為了編程訓練和學習。

Review:主要是為了學習英文

Tip:主要是為了總結和歸納在日常工作中所遇到的知識點。學習至少一個技術技巧。在工作中遇到的問題,踩過的坑,學習的點滴知識。

Share:主要是為了建立影響力,能夠輸出價值觀。分享一篇有觀點和思考的技術文章

https://www.zhihu.com/question/301150832

一、Algorithm

二、Review

許多文章都在強調不要過度設計自己的系統,但是沒有道出個所以然來,所以本文列出一些經典的過度設計,希望能給你帶來啟發,在工程上做一些平衡,避免過度設計把我們推到另外一個復雜度上

1、Engineering is more clever than Business

工程師通常認為自己是最聰明的,這第一個錯誤容易讓自己過于工程化。我們計劃了100件事,業務方會提出我們之前沒有考慮到的第101件。如果我們解決了100個問題,那么接下來還可能會有1000個問題。我們以為一切都是掌握之中,然而實際完全不知道未來會發生什么

在研發生涯中,從未碰到過業務在需求上是收斂,它們總是發散的,這是業務的本來面目,不是產品經理的錯

2、Reusable Business Functionality

當業務方提出了越來越多的需求時,我們第一反應是盡量分組和泛化業務,這是大部分MVC架構最后成為由大量模型或者控制器堆積的原因,正如前面所說的,業務永遠不會是收斂的,它們總是發散的

在系統中,共享邏輯和抽象應該是趨于穩定的,然而隨著功能迭代越來越多,它們要么會保持平穩,要么會變得脆弱。當相反的情況發生時,就會成為太大而失敗的系統

比如說,有個業務是實現用戶屬性管理,我們持著任何東西都是相似的這種觀點,首先完成通用的CRUD邏輯,但是這個需求實際上要求滿足13個不同的注冊流程,也就是說通用的邏輯代碼沒有任何意義。同理,一個訂單視圖和訂單編輯視圖流程是完全不一樣的,可偏偏有些人會合并視圖

我們在橫向分割業務前,應該先嘗試縱向分割,同時也要考慮從一種方式切換到另外一種方式的可操作性和便捷性,否則重寫系統將是災難性的工作,也就是說分離行為比強行合并好

3、Everything is Generic

需要連接數據庫,那就寫個通用的泛化適配器
需要查詢數據庫,那就寫個泛化查詢
需要對參數進行校驗,那就寫個通用的參數校驗器
需要對結果進行包裝,那就寫個通用的數據映射器
等等

當在實現需求時,浪費大量的時間嘗試總結出完美的抽象層,甚至原本業務問題的答案非常顯而易見。即使奇跡般地總結出了一個完美的抽象時,它往往會很快變得不適用,目前最好的代碼設計側重點應該是編碼易于被刪除的,而不是盲目追求易于擴展

實際上,重復代碼比錯誤的抽象更好,只有當你看到系統里有邏輯重復的代碼,才能更好地進行抽象,同時重復代碼暴露了許多用例,有助于使得邊界上下文清晰

4、Shallow Wrappers

我們習慣使用外部庫時都封裝一層,這種封裝是淺層的,不幸的是,我們容易在提供功能和編寫好的包裝器之間模棱兩可,混淆著大量的業務邏輯,使得它既不是一個好的包裝器,也不是一個好的業務解決方案。實際上要封裝一個優質的庫,需要投入大量的時間編寫,同時保證高代碼質量和完善的代碼測試,具備清晰、可測試的、可測量的API。需要注意的是,封裝應該是例外,不應該是常態,不要為了封裝而封裝

5、Applying Quality like a Tool

高質量的代碼通常滿足SOLID原則,使用相應的設計模式和代碼技術,比如factory、builder、strategy、generics、enums。如果你不加思索地運用質量概念,比如說將所有的變量修飾修改為private final,這并不能將編碼質量提高,或者改變過去鏈式繼承的方式,每個類都有接口和實現,然后注入到下一層,看似滿足SOLID概念。實際上SOLID的設計初衷是為了反對濫用繼承與其他OOP概念,然而大部分工程師沒有搞清楚這些概念從哪里來,如何出現,只是照單全收,沒有從思維上消化,只是工具化地盲目應用

學習一門其他語言,嘗試以另外的思維模式去做事情,這樣會成為一個更好的開發者。新瓶裝舊酒對我們沒有任何幫助,我們不必為了應用一個新概念而弄亂一個清晰的設計

6、Overzealous Adopter Syndrome

發現了泛型技術,將一個簡單的 “HelloWorldPrinter” 修改成了“HelloWorldPrinter”,那怕事實上只會有特定的數據類型,或者有足夠的普通類型簽名

發現了策略模式,現在每個條件語句都是一個策略

到處使用枚舉/擴展方法/Traits等各種炫酷的技術

上面都體現出了過度適配問題

7、<X>–ity

例子1、實現一個CMS系統,要求具備可擴展性,業務人員可輕松添加字段
結果:業務人員從來不使用這個功能,當他們需要時,會要求工程師在旁邊協助,也許我們所需要的只是一個簡單的開發人員指南,可以在幾個小時內添加一個新字段,而不是點擊式界面

例子2:設計一個可輕松配置的包羅萬象的數據庫層,我們可以通過文件配置輕松切換數據源
結果: 過了很長時間因為某種原因需要切換數據源,但是修改配置文件無法滿足我們的要求,現在業務有了很多的功能差距,導致不兼容

實際上,建議將數據庫視為解決方案的一部分,拋棄可配置性,否則很難保證兼容性。當設計時,多問自己使用場景是什么,然后深挖下去,你可能會發現大部分特性都是沒有必要的,包括可配置性、安全性、可擴展性、可維護性、可繼承性。總之,不要在沒有被要求時加上各種特性,應該明確地定義與評估場景、用戶故事、需求、用途

文章翻譯修改自:

https://medium.com/@rdsubhas/10-modern-software-engineering-mistakes-bc67fbef4fc8

三、Tip

并行程序設計模式,包括Future模式、Master-Slave模式、保護暫停模式、不變模式、生產消費者模式等

(1)、Future模式,服務程序不等數據處理完成便立即返回
(2)、Master-Slave模式,Master線程負責接收和分發任務,Worker線程負責處理子任務,每個Worker線程只處理部分任務
(3)、保護暫停模式,僅當服務進程準備好才提供服務
(4)、不變模式,通過回避問題而不是解決問題的態度來處理多線程并發訪問控制,如不可變字符串
(5)、生產消費者模式,生產者線程向內存緩沖區提交任務,消費者線程從內存緩沖區獲取任務并處理

四、Share

leetcode并發題目解題報告JAVA版-透過問題看并發編程注意事項和技巧

黑龙江6+1开奖结果查询