曾在IT界掀起腥風血雨的一個問題:技術總監要不要了解技術細節?java
歸根到底的問題就是:技術總監還要不要寫代碼了?mysql
在18年12月先後,我給你的回答可能大相徑庭。nginx
18年12月,我離開了相伴多年的公司,換了一個東家。程序員
「我要寫代碼",五個大字映在個人胸腔。web
就在前段時間,老東家的上司還問我要不要回去。面試
我想了下,回覆以下:spring
回去的話,不想帶項目,不作項目經理,能夠作售前、架構把控,寫代碼也能夠;能夠找人作項目經理,我前期能夠帶一程,或者協助。sql
我以爲XXX(我當前公司)這邊的組織架構還能夠,有總工、架構師、項目經理,架構師負責規劃項目或者核心代碼實現,項目經理負責項目進度。數據庫
爲何這樣說?
請看我上文十年風雨,一個普通程序員的成長之路(七)膨脹、驕傲,程序員轉項目經理的原罪
兩年的項目經理作下來,感受在代碼修煉、程序設計上沒有任何的長進。
在組建大數據項目組的時候,本覺得本身能夠投身項目,寫一些核心代碼,弄一弄Hadoop、hbase、jstorm、kafka、spark、kylin這些咱們項目中用到的大數據技術。
可是事與願違,承擔了一個項目經理的職責後,需求對接、項目里程碑跟進、對領導與客戶的進度彙報、資源協調……等等等等,都成了不起不去關心、煩心、投入精力的事兒。
如此下來,當18年結束大數據項目,我轉崗成爲技術經理,不想再作項目經理。
但是又跟進了一個跨政府部門合做交換平臺的項目,此時我惟一的要求就是給我配一個項目經理,我來負責這個項目的需求設計、架構選型與核心框架搭建。
結果領導答應的好好的,本來要作這個項目經理的同事,卻由於手頭的事遲遲交接不掉,最終仍是讓我接手了。而那個同事由於不滿於當前的工做情況,最終也是離職了。
我以爲,這樣的決策算是一種雙輸吧。
所以,這讓我萌生了一個念頭,我是否是也該出去看看了。
在18年12月前,我給你說上面那個問題(技術總監到底要不要寫代碼)的回答是,技術總監把控大方向就好了,寫啥代碼?哪來的時間給你?你又不是隻負責這一個項目。
【我最多的時候,擔任了5個項目的管理工做、2個項目以上的系統架構與技術評審。】
在18年12月後,我深深地跟你說,寫代碼吧兄弟。除非你想在這個公司養老。
不寫代碼則不瞭解技術細節,不瞭解技術細節一出去面試就一個接一個的懵逼。
關於這段經歷的獲得與思考:
對於技術能力還沒達到必定程度的程序員,個人建議是,仍是先暫且放一放管理性的工做。
能夠作一作項目的研發leader,可是仍是千萬不要作事務型的項目管理工做,除非你對管理很感興趣,那就走這條路吧。
在18年11月的時候,結束了跨部門交換平臺的工做。因而閒了下來,便把51 job上的簡歷給更新了下。
基本上天天都會有一個電話過來,約面試。
好笑的是,當時真的是什麼都沒準備,兩手空空,腦殼也是空空。
沒有去leetcode刷刷題,沒有去把一些基本的java知識複習下,沒有去好好返場熟悉下分佈式、高併發。
估計當時也是沒作好離職的思想準備吧。
很隨意地去面試了幾家,發先本身連不少基礎知識都給忘了。
有次印象深入的面試,是一個年輕面試官拿了一份卷子出來,讓我作筆試題。
筆試題?
Oh,No,我都很久沒碰過這個玩意兒了。基本上都是面試聊一聊就結束了。
而後這個面試官問了一個讓我至今都還記得的問題:「什麼是對象?」
我特麼直接懵逼了。什麼是對象?要不要new一個給你?
這個問題不是學習畢業第一年問的問題嗎?
我還真沒答上來,腦子一片空白。
我笑着說:「我懵逼了,你能給我點提示嗎?」
此次的面試經歷應該是在我11月到12月這個階段,屢次面試經歷中最糟糕的一次。
由於感受這個公司或是不尊重,或是招人、面試的制度、流程有問題。
像是在進行校招似的。
(固然,我自身也有問題,連這些基礎知識都給忘得乾乾淨淨。)
還有家公司的面試項目經理、項目總監、運維經理齊上陣面試我,結果問了一堆項目管理、數據庫設計的問題,但是又說不到點上。
我問他們究竟是須要什麼崗位的人才?他們說崗位不少,都須要,看面試人的能力狀況。
我了個去,你不說你招啥樣的,我十八般武藝賣哪一種呢?
面試的倒數第二家就是我如今所在的公司。
一面主要問的是對於性能有什麼見解?
我說了下QPS、TPS相關的一些概念,基本就過了。
二面問了nginx、ES以及讓我描述下性能優化的過程。
nginx說實話我是交換平臺項目才用的,並不熟悉,熟悉的是weblogic。
面試官問我nginx有哪些負載策略?我挺懵逼的,還真沒研究過,我說你能提示下嗎?
他笑了笑,說例如輪詢。
我想了下,回答說是配置upstream嗎?
以後回去看了下,nginx是能夠配置輪詢、ipHash、平均負載、權重負載多種負載策略。
ES,即elasticSearch,我是真的沒用過。這個東西我是知道的,可是遺憾的是面試時腦子有點糨糊,居然說沒聽過這個玩意兒。
【這個沒據說過在廣度上減分很大。】
關於性能優化,我說了這樣大體一個流程。
由於跟數據庫、數據倉庫、查詢打交道比較多,因此着重說了下數據查詢的優化過程。
(1)先找出慢SQL,以Oracle爲例,能夠經過AWR報表的方式查看。
(2)查看慢SQL的執行計劃,看看查詢的關鍵字段是否是缺失索引,添加索引。
(3)有索引,可是查看執行計劃,並無走索引。此時有兩種方法,一是用hint,二是可能數據表最近被大批量的刪除、新增過,須要手動收集數據表的統計信息,讓SQL優化器正常解析SQL。
(4)數據表太大,沒有合適的全局索引。可不能夠建設分區表?按照時間、地區進行分區操做。
(5)不能分區,或者分區效果也不顯著,須要考慮改動表結構了,有些字段是否是能夠拆出去?作成維表、擴展表?
【這是垂直拆分。缺點是查詢時若是要查詢擴展表字段,須要join操做,插入修改時要考慮多表,事物複雜。單表數據量仍是太大。】
(6)或者能夠考慮進行分庫分表操做。對於Oracle來講單張1億如下數據分區就夠了,不須要分庫分表。
【水平拆分。缺點是會致使事物一致性更爲複雜,還需引入分庫分表的管理中間件。】
(7)進行歷史數據分離。將一些不經常使用的數據,例如兩年前的數據都拆分到歷史表中。
【即冷熱數據分離。】
(8)增長數據庫性能,升級硬件,例如磁盤換上SSD。這個方法是被驗證過了的,尤爲是查詢批量數據,無高效索引的時候。
(9)從數據庫層面已經沒法優化了,咱們能夠考慮在應用端使用並行查詢的方法爬出數據,而後再行合併。
【事實上,不少報表工具都是這麼作的。】
(10)從業務上去優化,看看這樣查詢是否是有道理,這些字段是否是確實須要?需不須要這麼精細?需不須要這麼頻繁?大數據量報表每個月一出就好了?那這樣就無所謂時效性了。
面試最後,面試官問我對他們公司還有什麼問題?
我問了下若是入職後,將從事什麼樣的工做。回答的是一些中間件、平臺的開發。
我以爲仍是比較契合我當前迷茫期的目標的。
【真的是迷茫期,不知道幹什麼了。在老東家那裏,最多也不過就是升個總監,養老罷了。技術上就徹底與主流脫節、荒廢了。】
這個offer拿到後,便沒有怎麼再去面試了。
關於這個offer,其實我再認真刷兩天面試題,拿到的級別跟工資應該會更高點,可是這多是我,或者也是不少程序員的一個通病吧。拿到了offer便不想去面試了,麻煩。
其實仍是應該再多看看的。
關於面試的思考與獲得:
對於被面試者而言,應該準備充分點。由於時間過短,不少工做中難得的品質無法在短短的半小時、一小時內展示出來。不要讓本身遺憾,不要讓面試你的公司錯過你遺憾。
對於面試官而言,我認爲在面試、考查一我的的能力時,應該是去着重發現他的優勢,而不是努力找出他的不足。
每一個人都有本身不擅長的一面。
咱們是來挖掘人才爲公司增加業績的,而不是顯示本身能力來玩找茬遊戲的。
在入職新公司後,第一週就是領個電腦,裝些IDE工具,熟悉熟悉公司的規章,熟悉下同事,熟悉下工做範疇。
第二週便來活了,是寫個小工具,能夠自動將spring項目中針對Oracle、mysql的SQL語句轉換爲適配國產數據庫(達夢)。
前期已有一個架構師作了初步調研,我喊他榮哥。榮哥搭了個架子,讀入了mybatis的XML,我便開始解析、匹配、轉換xml中的sql,按照插件模式作了個擴展接口,總共花了一週寫好了這個demo。其中轉換mysql的merge方法比較麻煩,花了有兩天時間。
這個demo能夠轉換大部門的SQL語句,對於沒法轉換的,則輸出log,予以提示,多少行什麼方法須要人工去轉換。
後續又調研技術專家,業務側人員,作了這個工具的擴展方案,提煉了一個SQL輔助工具集。
規劃了一些擴展功能。如能夠鏈接JDBC,利用jdbc數據庫鏈接池收集SQL的執行次數、消耗時間,生成慢日誌、錯誤日誌文件,開發導入SQL的檢測功能,經過分析每條SQL的執行時間、表的索引、主外鍵關聯等數據,發現SQL錯誤、警告,獲取SQL執行計劃,提供建議,如SQL是否存在全表掃描、笛卡爾積等?
固然,後續就沒有後續了。
由於業務的調整,這個項目後續並無展開。
而我,也開始投入下一個項目了。
可是經過這樣一個項目,我卻以爲,這,的確是我想作的工做。
2019,我來了。
---------------個人成長之路系列---------------
十年風雨,一個普通程序員的成長之路(七)膨脹、驕傲,程序員轉項目經理的原罪
歡迎關注個人公衆號:姚毛毛的博客
這裏有個人編程生涯感悟與總結,有Java、Linux、Oracle、mysql的相關技術,有工做中進行的架構設計實踐和讀書理論,有JVM、Linux、數據庫的性能調優,有……
有技術,有情懷,有溫度
歡迎關注我:姚毛毛& 妖生