Java開發(fā)除了增刪改查還能做什么？很迷茫？

?

近日，閑逛知乎，忽見一問，曰 “Java開發(fā)除了增刪改查還能做什么？很迷茫？”。余大喜，此非送分題乎？遂答之，故成此文。博君一樂耳。

?

參加工作不久的初中級開發(fā)工程師通常都會有題主的感受，就是覺得Java開發(fā)，尤其是后端Java開發(fā)好像只能做CRUD，干一些增刪改查的重復、簡單的工作。

每天面向的就是表格處理、報表處理、后臺管理系統(tǒng)等等。所謂的高并發(fā)、高可用是一點兒都沒接觸到。

實際上，這是正常的感知，因為每個人最直觀的感知就會決定他對這個事物的認知。

?

話說回這個問題，Java開發(fā)真的只能做CURD之類的工作嗎？

?

答案當然是否定的，當然，我們說軟件本身歸根到底都是由算法+數(shù)據(jù)結構構成的，進一步細化之后，其實就是通過一系列的增刪改查操作，構成算法，對數(shù)據(jù)結構進行操作，賦予業(yè)務屬性。

那么我們說Java，甚至于各種其他的編程語言，都是在增刪改查也不為過。

這里有點鉆牛角尖了，我想題主說的增刪改查應當就是字面上的意思，也就是平時的開發(fā)主要就是通過使用開發(fā)框架完成簡單的需求。

而完成需求的主要過程就是調用api的增刪改查功能，業(yè)務邏輯怎么看都復雜不起來。

實際上，當我們開發(fā)接觸業(yè)務系統(tǒng)的主流程，我們會發(fā)現(xiàn)，好像簡單的api調用沒有那么好用了。

為了實現(xiàn)查詢的高性能，我們不能再簡單地通過 「Data Access Layer（或者說DAO？）」 基于JDBC/MyBatis/JPA 直接操作DB了事。

而是需要整合緩存，作為查詢的緩沖。而緩存又進一步分為本地緩存、分布式緩存。

此時我們就不得不考慮緩存失效策略，緩存與DB數(shù)據(jù)一致性的處理，如果恰好使用了諸如Redis、cassandra、MongoDB等分布式NoSQL.

數(shù)據(jù)庫，我們還得進一步考慮如何保證它們的高可用，以及如何對查詢進行優(yōu)化。

退一步說，即便沒有使用緩存，當用戶數(shù)量增加，請求激增，或者產品貼心的提出了要在系統(tǒng)中增加秒殺、大促等場景，那么我們就不得不考慮對DAL/DAO層進行優(yōu)化，常見的優(yōu)化諸如：讀寫分離、分庫分表、慢查詢優(yōu)化。

站在一家公司業(yè)務發(fā)展的進程上看，分庫分表往往不是一開始就引入的，而是先對數(shù)據(jù)庫進行讀寫分離，主從架構優(yōu)化，然后對業(yè)務中的sql進行優(yōu)化，

那么對于研發(fā)而言，掌握常見的SQL優(yōu)化策略，就顯得尤為重要，如explain的使用、索引的原理及優(yōu)化。

如果使用了分庫分表，那么就需要對各種分庫分表的中間件進行選型，勢必需要進行調研學習，框架整合，選型比較等一系列的工作，這和傳統(tǒng)的增刪改查

相比又增加了些許挑戰(zhàn)。

我們假設一開始的服務是單體的，那么這個時候項目的代碼基本上都是寫在一個工程里，業(yè)務之間的調用也都是本地調用，跑的很好。

隨著業(yè)務量增加，用戶數(shù)增多，競品數(shù)量增加，導致需求迭代越來越快，需求提出越來越多，于是不得不考慮對單體服務進行服務化改造，

那么此時就又需要接觸到服務化框架，比如說Dubbo、gRPC（當然它本質上還是一個rpc框架，需要自己增加各種服務化的支持，如負載均衡、服務發(fā)現(xiàn)等）、SpringCloud（它本質上是一個微服務框架，提供了一攬子的解決方案），

自然而然地，我們就需要通過rpc調用改造原先的本地方法調用，通過MQ（Kafka、RocketMQ、Pulsar等）對異步場景下的數(shù)據(jù)交互進行改造。

分布式了，服務間調用鏈路長了，復雜了，監(jiān)控得加對吧，那么就自然而然需要引入各種監(jiān)控框架，比如說APM探針，如ZipKin、PinPoint、SkyWalking等組件，

日志分析系統(tǒng)，如ELK、Flume等組件，有了監(jiān)控上報的數(shù)據(jù)，我們還得提供一些可視化的界面，可以自研，也可以使用開源的組件比如說prometheus + kibana。

公司業(yè)務復雜了，系統(tǒng)規(guī)模變大了，老板想看看業(yè)務數(shù)據(jù)，搞搞用戶畫像，搞搞日志分析，這個時候就得引入大數(shù)據(jù)那套生態(tài)圈，hadoop、flink、HBase用起來了，

想用sql方便查數(shù)據(jù)，于是HIVE也得用起來了，ETL搭起來了，本質上還是增刪改查，但是復雜度和當初的單體系統(tǒng)DAO/DAL不可同日而語。

業(yè)務系統(tǒng)數(shù)據(jù)要導入大數(shù)據(jù)系統(tǒng)，kafka也接進來了，zookeeper也得搭起來了，那么自然的，不得了解一下zookeeper一致性實現(xiàn)的機制，各種ZNode的特性和使用方法，

再了解了解ZAB算法，學習一下優(yōu)秀的分布式協(xié)調算法是怎么實現(xiàn)的，于是你對分布式系統(tǒng)的認識又加深了。

后來，業(yè)務復雜到，迭代一次就得修改好多個微服務，很頭疼，于是大佬說，要不咱們試試DDD吧，重構一下系統(tǒng)。

于是我們又得學習一通DDD的方法論和工具箱，大刀闊斧的搞了領域驅動改造。

此時的我們，回頭一看，原來Java不止是簡單的增刪改查，它的生態(tài)如此之廣闊，此時的自己感受著Java生態(tài)圈的龐大和自己顯著的成長，突然眉頭一動，

恍然大悟，KAO，搞了半天，這些玩意兒不還是增刪改查嘛！

繼續(xù)更新一下，當寫業(yè)務系統(tǒng)寫到一定程度，大概率需要定制一些自己的組件，封裝一些類庫，這個時候大概率也就開始讀源碼了。

當接觸了優(yōu)秀的開源框架的源碼，比如：Spring的core、Context包、Guava、RocketMQ、Netty、甚至JDK的JUC包源碼，我想基本上也就不會再糾結Java到底可以干什么了。

因為源碼已經告訴你了，Java可以干的事情很多，

它可以開發(fā)IOC、AOP框架，簡化業(yè)務開發(fā)的工作量；

它可以開發(fā)各種微服務中間件，簡化服務化改造的成本和投入；

它可以開發(fā)各種三方類庫，提升代碼質量減少重復開發(fā)；

它可以封裝復雜的底層細節(jié)，讓開發(fā)者更加友好地進行并發(fā)編程；

重要的，它能夠提供一個窗口，讓開發(fā)者不斷更新知識體系，不斷進步和持續(xù)學習。

對于公司發(fā)展而言，它也能夠持續(xù)帶來流量的增加和業(yè)務的發(fā)展。

總結：

學習三境界，看山是山，看山不是山，看山還是山。

題主能提問出這個問題，恰巧表明題主已經到了看山不是山的層次，有所質疑，有所進步，祝我們都能繼續(xù)進步，到達更高的認知層次。

看了看其他的一些答案，各種推薦書，還有推薦自己的筆記要關注的，蚌埠住了。

答案原地址：https://www.zhihu.com/question/510619641/answer/2347022679