好吧，這個問題其實很普遍，也很有代表性。

首先作為公司的員工，我們要明白一個道理，縱然有天大的技術能力，縱然熟練掌握了最新的Java架構技術，但是那並不是大部分公司的訴求。對大部分公司來說，要求的是技術框架的成熟和穩定，在這基礎上，是整套框架能夠為開發工作帶來大幅的效率提升，以及整個技術團隊能夠以極地的學習成本來接受和熟悉。

對於一家公司來說，技術也好、框架也好、以此為基礎開發而成的軟體也好，充其量只是工具，賺錢的工具。既然要賺錢，那就已定是將成本壓縮到最低，將利潤空間最大化。

新技術固然好，但是也潛藏著一定的不穩定性和較高的學習成本。

在這種認知下，就不難發現很多程式設計師進入軟體開發團隊後，其實僅僅只是就著這個團隊已有的框架來進行簡單的程式碼複製粘帖操作。而自己引以為傲的一身“絕學”得不到施展，有時候向主管或者領導提出自己的建議，好一點的領導層會笑嘻嘻地回答說“很好啊，我們考慮一下”，而有些耿直的領導則會一臉不耐煩地說“不用你操心這些事情，寫好你的程式碼別出錯就行”。

而之前提出並推行了公司現有技術框架的前輩們，豈容你那麼容易就推翻他們，然後踩著他們的臉上位？程式設計師是很少會想到職場政治和厚黑學方面的事情的。

而當程式設計師在這樣的團隊裡工作了一段時間，開始覺得有些恐慌，開始覺得“學不到東西”，想要出來的時候，會發現離開了這個公司，別的地方壓根兒可能也不用這套技術框架。但是進到新的公司，會發現又是跟前一個僱主一樣的情況。

於是週而復始。

其實這樣的情況並不是不能破解，只是很大程度上需要依靠程式設計師自己的巨大努力和付出。首先程式設計師自身需要付出很多額外的時間，來熟悉和掌握，甚至是精通一些行業內比較新、比較好的技術框架，除此以外，還要對公司所使用的原有框架有深入的剖析和理解，這樣才能有對比，才會知道公司為什麼會選擇那個框架，選擇它的目的是什麼，優勢在哪裡。而自己所掌握的其它技術與其相比又有哪些優勢，或是不足的地方。

有了這樣的比較，才能進一步決定什麼樣的技術框架適用於什麼樣的開發場景或是專案需要。

其次，大部分程式設計師可能都不會在意一些開發規範方面的東西。有一個很著名的段子，就是說程式設計師最煩的兩件事情，一個是寫程式碼註釋，一個是看到別人的程式碼沒註釋。我舉這個例子是要說明，如果你做好了充分的前期準備，覺得差不多可以向團隊提出升級技術框架的想法的時候，你不能忽略其他人對新框架的學習成本問題。

很顯然，如果你花費了一番口舌，好不容易說服你的主管，有幸得到了一個機會，在一個開發週期比較充裕，規模也不算大的專案中試行你的新技術框架。但是在專案進入開發階段時，團隊中的所有人幾乎都在抱怨你的框架使用並不方便，大家總是問這樣那樣的問題，甚至是專案的整體編譯都經常出現問題，那即便是再好再新的技術，也會變成“這個框架真TM爛”這樣的結論。這個時候旁人再對你施加一些職場政治手段，你就離滾蛋不遠了。

另外一條比較可行的路，是進入一家規模比較小的公司，跟著公司的專案、產品和小團隊一起，在實際工作過程中不斷學習新的技術，並逐步應用在公司的專案或產品中，逐漸逐漸形成一個較為穩定的技術框架。你參與了這個框架的設計和成型，也參與了對它的除錯和開發，在這個過程當中又完善了自己對技術的高層次理解。

當這個框架趨於穩定的時候，很有可能就是你變成公司“大佬”的時候。而即便發生了一些不可抗力，你不得不離開這個團隊的時候，你所帶走的也並不只是一套框架本身了，這時候的你得到是“漁”，你變得能夠應付各種不同的情況，這時上哪兒沒有“魚”呢。

這個還是要看情況而定，如果只是常規的crud,這樣大大提高開發效率，不過也有弊端，，時間久了有些基礎的都會忘記，我感覺是這樣的，主要處理下業務邏輯就是了。前臺的話，現在的前臺框架其實也不用這麼寫js,都封裝好了。反正以後的開發都是怎麼方便怎麼來，已經有可以自動生成程式碼的應用了，說不定那天我們程式猿就會失業了。

基於自己的親身經歷分享一下個人的想法，對於智慧框架，我理解為快開 框架，在工作中偶爾也會使用一些快開框架來開發一些週期很短的專案，快開框架相對於主流框架確實縮短了開發週期，很多的基礎配置也被完全封裝，但是快開框架對於初次使用者並不亞於自己親手搭建一個主流框架，首先需要逐步分析快開框架，搞清楚配置是怎樣被封裝，其次才能著手完成業務的開發。

快開或者智慧框架的本質還是將主流的框架進行一系列的封裝，想要遊刃有餘的使用智慧框架還是需要熟悉基礎的主流框架，所以不必糾結智慧框架會不會削弱程式設計能力，在程式設計基礎能力不斷完善的過程中，使用智慧框架反而會讓自己更加出色的完成一系列的工作。

不會，首先，AI會減少工程師的工作量，把更多精力放到其他深層次的研究中，比如最佳化架構，節省伺服器空間這類降成本的工作。其次，目前大量AI還需要學習，AI的學習型演算法是基於大資料基礎的，越複雜而精細的事務，對程式設計抽象能力要求反而越高。

我不這麼認為，如果公司框架非常智慧，說明這個框架肯定是非常優秀的。其實一切的框架都是為了簡化我們的開發，但是其底層所用的技術都是一些基本的技術，但是框架設計思路、原理確實非常值得學習的。我想如果你不是隻是使用框架，而去研究框架的設計思路、原理，多和同事討論這個框架甚至嘗試著去最佳化這個框架，一定會受益良多，也會大大提升個人的程式設計能力。

關注是為了再一次的交流，戳一戳右上角的關注吧！

我們公司用的基本都是java原生寫的程式碼，程式碼寫的一坨屎，分所謂的服務，也就是最近流行的微服務，但是全部都是http呼叫，連http呼叫工具類都沒有統一，專案做了10年了他媽到現在沒人用問題一堆。寫個根據id返回資料記錄的欄位的，讓我用幾個欄位返回幾個欄位，不讓複用原來，真是無語了。

我想說的是公司沒有能力就不要用原生的東西，請用框架，不然寫出來的就是一坨屎。

1.框架智慧，老闆也不會給你加工資

2.智慧之後工作效率提高了，但每天還是要加班，因為活更多了

結論是即使框架智慧了，自己部門知道就可以了，千萬不要給老闆知道，工作做完了沒事也繼續加班

我覺得不會，對於願意學習的人，框架智慧了，可以節省大量時間用於充實自己，比如，搞清楚公司框架如何設計成如此智慧的。對於不願意花時間學習的，天天上班沒事情做也不會花時間去提升自己。

框架也是程式設計師開發的；

如果你是基於框架來做業務開發的，想了解學習更多的技術體系；你可以去了解公司的這套智慧化框架的實現，架構；看看原始碼，和框架組的人多交流交流，這樣會迅速提升自己的技術功底；

你這個問題問的，那大公司裡的人都不行嗎？

大公司裡很多的框架，很多的平臺化，很多的自動化的流程，高度的智慧化框架。

相反的，

公司框架太智慧反而會強化你的程式設計能力

首先明白什麼是框架

你的問題可以這麼理解， Java是一種程式語言，隨它產生的框架是一種特定的編碼模式（包括很多的工具和lib）。

假如，每當你從頭開始構建一個專案時，你都不用框架，很多的基礎工作你都要做，包括列印，除錯，連線資料庫，編譯等等，那麼你還有多少時間來進行你的業務開發？但隨著應用程式越來越大，記住你寫的東西變得很多很難，除錯程式碼變得更加困難。為了避免這樣的問題，框架才被廣泛使用。

你有本事，每次一個專案都寫一個自己的連線資料庫類來試試。

使用框架

使用框架能讓你更注重你的特長，專注於你要做的工作。（不管是業務的還是非業務的工作）。

你不需要花費通常需要幾個小時和幾百行甚至更多的程式碼才能完成的基本任務。

要學會站在巨人的肩膀上，而不是從0開始研究為什麼1+1=2 。

記住，能削弱自己程式設計能力只有對於程式設計這件事的態度，對技術的熱情。

就拿你說的這件事來說，公司的框架太智慧，越智慧的框架，它的實現可能囊括的技術體系和範圍也就越大，那麼你可以慢慢的深入瞭解框架的具體實現，瞭解設計思想及技術內涵。但是如果你只是簡單的去用，不思考不深入，那用什麼工作也不會提升你的能力。

而且作為程式設計師，工作之外的時間不學習一些好的東西，只單純工作，那也是遠遠不夠的！

程式設計能力主要兩個能力：程式碼結構、演算法效率。至於工具、框架什麼的，是次要的事。所以用什麼框架跟你的“程式設計能力”是沒有關係的。