剑网3指尖江湖职业推荐 www.1468054.com 今年年初,到一家互聯網公司實習,該公司是國內行業龍頭。

不過技術和管理方面,卻弱爆了。

那里的程序員,每天都在看郵件,查問題工單。

這些問題,多半是他們設計不當,造成的。

代碼寫的一團糟,全是復制粘貼,連作者都沒改,大家普遍不寫注釋,也不格式化,代碼歪歪扭扭。

一個項目里,httpclient竟然出現了四種。

一種是該公司研發部寫的,

一種是老版本的開源項目,

一種是新版本的開源項目,

還有一種是開發人員造的輪子。

打接口請求響應日志,竟然不知道用攔截器。

打錯誤日志竟然不打上下文信息,每個人一種日志風格,千奇百怪。

許多重要的中間流程,居然不打日志。

idea、eclipse、myeclipse的配置文件竟然全部傳到項目里去了。

該公司混了兩年的程序員,跟快遞公司做查詢接口,竟然不知道加密運單號。

所有服務間通訊,都沒有設requestId,導致跟蹤會話很困難。

一個沒什么qps的邊緣接口,居然做消費者生產者+阻塞隊列的異步模式。

顯得你技術少是不是。

不知道異步會增加維護成本,提高測試難度嗎?

而且,任務隊里沒有考慮持久化,趕上發布,丟了好多任務。

讀取一個小小的xml和exc配置文件,居然用流式解析,沒見過這么二逼的,真是醉了。

做優化全靠拍腦門拍大腿,難道不會用excel分析日志,用jprofile掃項目?

一個100以內的常數集合遍歷,他也要寫個優化算法進去,算法跟業務還攪在一起,一團亂麻。

每個人都在嚷嚷性能、算法、分布式計算……

幾乎沒有文檔,全靠從代碼反推邏輯。

有枚舉他不用,非要在每個頁面上,把枚舉值挨個兒寫死,知道后面改代碼多么費勁嗎?

欺騙性的變量名,里面存儲的是AES加密的,變量名后綴卻寫成了DES;里面存的是小寫字母,卻寫成upperStr。

一個方法十幾個參數,有三分之一是極其簡略的縮寫,注釋肯定也沒有的。

一個類寫到三四千行是常事。

開發自測,居然要把代碼全丟到公共機器上,而且都是走svn,他們把svn當ftp用。

svn里面大量的無意義提交,一多半的提交連都編譯不過去。

我看到有個應屆生,改了兩句話,馬上提交,說是怕代碼丟失。

一個運行了兩年的項目,spring的包掃描明顯配錯了,有些bean根本掃不進來,居然沒有人發現。

一半的bean在spring管理下,另一半的bean他們自己寫單例模式來實例化。

他們用mysql來做審計系統,出報表,有個報表要跑8分鐘。

原來是有人用字符串來存多值(逗號分隔),sql里寫了like,導致沒有利用到索引。

為什么不用pg,pg在sql編程方面,功能更豐富,更適合做統計,它本身就支持數組。

程序員們都是得過且過的態度,怎么把代碼灌進去,跑的通測試,就算交差了。

為什么大型互聯網公司,技術和管理這么差勁,是怎么形成的?

新手經?;嵊姓庋南敕ā剛獯朐趺湊餉蠢??寫的人干什么吃的?怎么能這樣?為什么不按照書上說的做?」,這很正常,大家都年輕過,經歷過這種階段,我懂你心里的想法,所以也愿意詳細地向你解釋,這一切發生的原因是什么。

你說

不過技術和管理方面,卻弱爆了。

那里的程序員,每天都在看郵件,查問題工單。

這些問題,多半是他們設計不當,造成的。

你真的覺得『國內行業老大的互聯網公司』會是技術和管理弱爆了的樣子嗎?

你以為團隊應該像永動機,但現實永遠有各種摩擦、輻射、損耗。

內燃機的能量轉化率,通常只有 30% – 50%,但是它卻是驅動全世界運轉的核心引擎,順豐京東的快遞小車、聯通全國的高鐵動車綠皮、瞬時直達的飛機……

機器尚不能 100% 效率運轉,何況是人呢?

你說我們的程序員每天都在查看郵件、問題工單,你說這些問題多半是我們設計不當造成的,請問你有試過統計數據嗎?你大概只是『感覺』如此吧?

事實上,經過十幾年的發展,我們內部的『效率改進團隊』已經非常高效成熟,每月、每周、甚至每天都會有新的改進,現在的業務處理方式,不說全世界,我可以自豪地說在全國我們是領先的,甚至是遙遙領先,不然憑啥坐到了全國龍頭老大的位置呢?

所以啊,你只看到了程序員花在業務上的時間,沒看到我們內部的『效率改進團隊』為程序員們省掉的時間,我覺得我有必要站出來為默默付出的『效率改進團隊』說幾句。

當然,樓主作為實習生,不知道這些事情進而產生了這些疑問,也暴露了我們的不足。我已經在『團隊建設委員會』里提出了這個問題,大家一致通過了決議,以后我們會對新員工——包括實習生加強企業文化、歷史培訓,確保我們的新伙伴們不僅知道要去哪兒,也要清楚我們從哪里來,長路漫漫,我們一同前行。

你覺得

代碼寫的一團糟,全是復制粘貼,連作者都沒改,大家普遍不寫注釋,也不格式化,代碼歪歪扭扭。

當初公司起步的時候,整個項目都是幾個初創程序員加班加點熬出來的,我知道你看過《代碼大全》、《程序員修煉之道》、《Unix 編程藝術》,你對上面的準則信手拈來,你可否翻開床頭柜上的這幾本書,看看它們的出版時間呢?

是的,公司起步的時候,這幾本書根本還沒有出版,彼時中國互聯網方興未艾,大家都是摸著石頭過河。現在你遇到問題,你可以問朋友、問導師、用谷歌、用棧溢出、用知乎,我們寫程序那個年代,看的是譚浩強、嚴蔚敏,用的是 52k 撥號上網,語言只有 C,編輯器是沒有語法高亮和實時編譯的,編譯器是沒有智能準確的報錯的,沒有現在這么多知識、也沒有這么多規范和好資源、好工具。不過我們還是把項目做出來了,把公司一步步推到了現在的位置。

不過這個問題是客觀存在的問題,誰也不否認,但是你知道為什么你被分配到了一個『代碼看上去一團糟也不夠規范』的項目嗎?我們需要新鮮血液來重構一些老代碼,所以你會被分配到艱苦的崗位上。我們希望你是勇于戰斗的戰士,我們更希望你能成長為經驗豐富的老兵,而把你放到這種崗位,是對你來說成長最快的方式。

你認為

一個項目里,httpclient竟然出現了四種。

一種是該公司研發部寫的,

一種是老版本的開源項目,

一種是新版本的開源項目,

還有一種是開發人員造的輪子。

你不知道的是,我們最初用了開源軟件(也就是你所說的『老版本』),它構成了我們早期項目的基石,隨著業務復雜性增加,我們改進并最終切換到新版本。

這個軟件跑老業務非常成熟,但是在一些新業務上有不可調和的矛盾,所以在痛苦的適配后,研發部的同事們自告奮勇用 20% 的時間寫了新業務的組件——是的你沒看錯我們也有 20% 時間,我們鼓勵工程師的創新。

至于你說的開發人員造的輪子——這說起來可真有趣,它其實是前年來的一個清華大學實習生寫的。

當時他來了之后,針對他接手業務的需求,向我抱怨說現有的 3 種都不好,要寫一個新的來『統一天下』,這話是他的原話,我記得非常清楚,因為以我多年經驗來看這樣的做法是不可取的,但是本著鍛煉年輕人的心態(加上他的確是不可多得的天才),我同意了他的請求,于是我用自己的業余時間接管了他的大部分工作,全力支持他寫一個新的組件,幫他擋住了所有上面的壓力,后來的故事就是你看到的這樣。

是的,他后來越深入、就越來越感到業務的復雜,不斷推翻重構、拆東墻補西墻,但始終發現和自己想的根本完全不一樣,受不了了就走了,留下來這個。

我們明年的規劃中,就包括剔除這個組件的 codebase,因為它實在是太糟糕了。

你又說

打接口請求響應日志,竟然不知道用攔截器。

打錯誤日志竟然不打上下文信息,每個人一種日志風格,千奇百怪。

許多重要的中間流程,居然不打日志。

idea、eclipse、myeclipse的配置文件竟然全部傳到項目里去了。

該公司混了兩年的程序員,跟快遞公司做查詢接口,竟然不知道加密運單號。

所有服務間通訊,都沒有設requestId,導致跟蹤會話很困難。

攔截器并不如你所想的那班美好,也許你在自己的電腦上寫過一些玩具代碼,覺得這樣很方便、酷炫,但是真正到了戰場,你會發現沒什么才是必須的、好的,只有適合的才是對的。

至于配置文件,這么說吧,IDE 的配置文件傳到代碼倉庫是我定下的規矩,『怎么會有人定這樣的規矩?』,是的你可能從軟件工程的教科書上或者某些『知名博客』上讀到了不能這樣做,但實際上這樣做在很多情況下是必須的。

原因何在?

這樣可以確保代碼克隆即可用,而不是讓每個人都去設置一大堆無聊的東西,這樣不僅節省時間,也確保了每個人的環境一致性,你想想這幾年火熱的 docker,應該明白了這樣做的正確性和必要性了吧?

你可能會說即便如此、插件也不用上傳到服務器保存,我告訴你這樣是不行的,你要考慮到我們這個項目前后十余年,你覺得幾個插件能堅挺十余年?很可能我們早期用的軟件,現在你已經完全不可能找到了,所以保存一份備份是非常有必要的,決不能錯誤地認為是冗余。

教科書只會教你基本通用的原則,樹立你基本正確的觀念,但是如果只是死守教條,如何能擁抱日益復雜的變化呢?

你看的教科書,且不說時間上已經是二十多年前的了,在適用性上,也不說就是真理,IT 行業發展日新月異,幾個月就是滄海桑田,為了適應這樣的變化,認真地思考、總結、判斷才是最重要的。

你覺得

一個沒什么qps的邊緣接口,居然做消費者生產者+阻塞隊列的異步模式。

顯得你技術少是不是。

不知道異步會增加維護成本,提高測試難度嗎?

而且,任務隊里沒有考慮持久化,趕上發布,丟了好多任務。

讀取一個小小的xml和exc配置文件,居然用流式解析,沒見過這么二逼的,真是醉了。

你大概不知道,當初跑在你口中的「一個沒什么qps的邊緣接口」上面的業務帶來了公司曾經 90% 的收入,所以我們用了復雜的設計以應對當時的需求,當然現在業務轉變,老系統不再需要處理那么多業務了,但是更沒有理由為一個『works perfectly well』并且不再重要的業務重構代碼吧?

所以,不是我們秀技術,而是業務需求 + 業務變更使然,年輕人還需要多學習一個。

你抱怨

做優化全靠拍腦門拍大腿,難道不會用excel分析日志,用jprofile掃項目?

一個100以內的常數集合遍歷,他也要寫個優化算法進去,算法跟業務還攪在一起,一團亂麻。

每個人都在嚷嚷性能、算法、分布式計算……

幾乎沒有文檔,全靠從代碼反推邏輯。

有枚舉他不用,非要在每個頁面上,把枚舉值挨個兒寫死,知道后面改代碼多么費勁嗎?

欺騙性的變量名,里面存儲的是AES加密的,變量名后綴卻寫成了DES;里面存的是小寫字母,卻寫成upperStr。

一個方法十幾個參數,有三分之一是極其簡略的縮寫,注釋肯定也沒有的。

一個類寫到三四千行是常事。

我再強調一次——我們是全中國同類公司中技術能力第一的,你所說的問題,當然是不存在的。

我們有專門的 Hadoop 集群來分析日志,當然也就用不著 Excel 了。

對于我們這種體量的公司來說,不存在什么『常數集合』,代碼必須用合適的數據結構——這是常識吧?

特殊的算法和業務摻雜以增加內聚性,這是我們多年的經驗,的確,它和教科書上說的不一樣,但是我前面說了,死守教條是不行的——想必你一定知道 OSI 7 層網絡模型吧?

公司的技術氛圍濃厚,是和公司的基因分不開的,我們公司最重要的原則就是——『擁抱變化』,從十幾年前的機房托管單機到現在的龐大自建集群,技術躍遷了何止千萬里,所以每個人都在學習新知識、每個人都沉浸在新知識的喜悅中。

你的問題,大多都是因為沒有考慮到公司的龐大體量和十幾年的技術躍遷才有的疑問,這點不再贅述,自行體會吧。

你想的是

開發自測,居然要把代碼全丟到公共機器上,而且都是走svn,他們把svn當ftp用。

svn里面大量的無意義提交,一多半的提交連都編譯不過去。

我看到有個應屆生,改了兩句話,馬上提交,說是怕代碼丟失。

一個運行了兩年的項目,spring的包掃描明顯配錯了,有些bean根本掃不進來,居然沒有人發現。

一半的bean在spring管理下,另一半的bean他們自己寫單例模式來實例化。

其實那不是 SVN,那是我們公司自主研發的適應我們內部需求的 源代碼管理系統 和 文件管理系統,你可以往里面放任何東西。

你所說的「無意義提交、一多半的提交連都編譯不過去」其實只是表象,這套系統代號 TITAN,它自帶 CIDD(持續繼承、交付、部署),所以這些無法編譯的提交都是不會有機會走到下一步流程的的。

如果你工作了一年,你就會發現這個需求是很重要的,改動、尤其是大型改動,中間會有很多非可用但有需要存檔的步驟,現有的源代碼管理系統都不能很好地支持這些需求,因此你也被教育了一套適應落后工具的思想。人啊,最重要的能力是改進工具,所以用 TITAN 的時候要擁抱全新思維,不要被落后思維捆綁。

如果你工作了幾年,你可能還會問為什么我們沒用 Jenkins、Travis 等工具,其實呀,就在 TITAN 之中呀,它凝結了公司最優秀的人才的十幾年寶貴經驗和心血。

By the way,我們最近正計劃開源它,為中國開源社區做貢獻,也希望提高業界的綜合素質?;隊閭嶠?PR 哦。

你最后說

他們用mysql來做審計系統,出報表,有個報表要跑8分鐘。

原來是有人用字符串來存多值(逗號分隔),sql里寫了like,導致沒有利用到索引。

為什么不用pg,pg在sql編程方面,功能更豐富,更適合做統計,它本身就支持數組。

程序員們都是得過且過的態度,怎么把代碼灌進去,跑的通測試,就算交差了。

為什么大型互聯網公司,技術和管理這么差勁,是怎么形成的?

為什么不用 pg?如果你抱著這種想法,那用了 pg 也要被噴的,到時候就就會說 —— 「為什么不用 sqlite,輕量簡單,搞這么復雜真的有必要嗎?」,真的有必要。。。

這只是一個很簡單的系統,做的事情也很簡單,當初做這個系統的同事更熟悉 MySQL,當然 MySQL 是不二之選了,對于簡單的東西,追求的是開發速度、使用便利性。

你覺得一個月跑一次的審計代碼,8 分鐘有什么問題嗎?就算是一周跑一次,當然也是沒問題的。

程序員的單位時間是如此寶貴,為了優化一段一個月跑一次的 8 分鐘代碼,值得花費數天的時間來做這件事嗎?

重復一遍,你的問題,大多都是因為『沒有考慮到公司的龐大體量和十幾年的技術躍遷才有的疑問』,這點不再贅述,還請自行體會。

當然,年輕人樂于思考,這是好事,是希望,新鮮血液替換老舊部件系統才能健康發展成長,人如此、公司如此、國家也是如此。

希望你勤于思考,努力學習,有問題的話,我們公司是鼓勵同事們向 CEO、CTO 寫信的,不然也不會有 CEO、CTO 信箱了你說對嗎?

當然,這樣的技術性問題、你寫給我就好,CEO 是船長,不需要關心底層鍋爐房的細節。

另外我想補充一下我的想法,希望對你有所幫助。

 

你看你都沒說加班問題,我們公司沒加班啊,這多好,怎么做到激烈競爭下還能不加班的?都虧了公司老領導和元老們的一手決策

所以我想補充的不是技術問題,技術問題都不是問題,年輕人可以學習、交流,技術都會很快成長,畢竟年輕人的沖勁大、頭腦靈活。

我想說的是整體觀、大局觀、大棋戰略。

 

黃金的導電性最好,為什么電腦主板還要用銅?

清華大學最好,為什么有人要去普通學校?

飛機最快,為什么還有人坐火車?

因為資源都是有限的,我們在現實生活中——而不是教科書上——必須兼顧成本和產出的平衡。

 

你問我每行代碼都多人多層人工 review 好不好?問我支不支持?我說好,review 我怎么能不支持呢?我今天在知乎這個公眾平臺我明確說了我支持。

但是你也應該多學習一個,這個現實畢竟是現實,我們要兼顧各種考量。

你今天在這里渲染「大公司技術和管理這么差勁」,是不對的、是失實的、是欠妥的、是缺乏認真思考的、是未加深入考量的。

將來輿論出了偏差,你雖然不用負責任,但是你認識到自己的錯誤的時候,會后悔、會內疚、會難過的吧?

何處烏托邦?或許……等下一代?

總結就是,生產效率才是最重要的,世間萬物最重要的是平衡。

怎樣取舍、如何妥協,這不僅是大自然的規律,也是我們前進、發展的準繩和仰仗的原則。

 

下面是陳萌萌的回答:

題主你看到了很多槽點,但我認為你不能只看到槽點和大概怎么解決。有沒有想過怎么改進,如果是你的話你怎么做,這些項目里面臨的主要挑戰是什么,次要的挑戰又是什么?

不要只告訴我技術A弱爆了,用B就可以完爆這個項目了。你知道用B的優劣,B的適用場景以及適用B的成本嗎?對于一間公司來說,成本是很重要的。我這里說的成本不是金錢。而是,假如你看不爽一份代碼,你打算重構它,你覺得你需要投入多少時間,多少人力?重構之后,又要花費多少時間和人力去升級依賴這份代碼的其他項目?不要以為開會無用,老板就只是在天天發郵件。如果你重構了一份代碼,不能通過溝通說服其他組去升級他們的組件,又或者你只是重構了一份雖然很丑陋,但其實并沒有多少程序依賴它的代碼,又又或者你重構了代碼只是讓代碼技術含量更高了,更好看了,卻沒給公司帶來多少收入甚至KPI,那你的工作和成果就很尷尬了。

其實上述也解釋了為什么你身邊的同事都眼睜睜地看著這些丑陋的shit存在而無動于衷。因為他們也是需要投入成本的。先不論他們個人技術水平高低,試問誰愿意挑一個又艱難,又不能產生多少效益的任務去做?當然,你會說,寫好代碼是程序員的節操。抱歉,節操多少錢一斤,北京三環商品房多少錢一平?

編程高手都有真愛,但現實就是編程高手鳳毛麟角。我們身邊的大部分同事可能只是希望養家糊口,他們頭上還掛著十幾個bug等著修。我們數落他們沒追求,但追求從來都不是嘴上說說,吐吐槽就能實現的。

人心如此,公司也如是。

矛盾分主次,公司的目標都是一樣的:用最少的成本投入到最能產生效益的項目中去,或者投入大成本去解決公司最需要解決的問題,這間公司才能繼續運作。

所以題主你想想,在你吐槽的個案中,有多少是公司真正關心的?有哪些是你的老板認為可以創造最大效益的?有哪些才是主要矛盾或者挑戰需要最牛逼的人挺身而出第一時間解決?去辨別,解決這些關鍵的問題吧,騷年。必要時帶上(忽悠)一隊人馬(同事)跟你一起干,茍富貴,勿相忘。不要像祥林嫂一樣,天天抱怨著生活,日日思考著辭職。得罪點說一句:“淪落”到要跟這樣的人共事工作,難道自己身上就沒有原因?

這個世界有更好的公司,有更牛逼的人。如果你認為解決這間公司的這堆問題不值得,又或者同事實在太不給力,就遠走高飛吧。

我以前也跟題主一樣,看我第一份正式工作的很多技術環節都相當不爽。這份代碼寫得丑,那個設計像大學生作品,重要的項目居然連單元測試都沒有……但是我后來反觀我自己,并沒有發現比起那些丑陋代碼和糟糕實現強悍多少。我跟我的同事沒有質的區別。我笑話他們代碼混亂bug不盡,我何嘗不是少處理了一個field,倒騰錯了一個片段的數據搞到要翻工重跑?在我心底里艸了隔壁組那個“我的程序好像不能跑,你幫我debug下”的同事一千次之后,帶我做ML讓我倒騰數據并且被我的程序搞壞了幾份數據(當然后來搞好了)的T9君在會議上說:“她已經很努力了,我承認我有時候也逼得她太緊,她應該有多些時間的?!?/p>

余下全文(1/3)

本文最初發表在伯樂在線,文章內容屬作者個人觀點,不代表本站立場。

分享這篇文章:

請關注我們:

《為什么有些大公司技術弱爆了?》有46個想法

  1. sxan 對這篇文章的反應是好文
  2. ikgad 對這篇文章的反應是敬佩,俺的神呀,贊一個
  3. ad 對這篇文章的反應是贊一個
  4. 這篇文章可以總結為一句話:我們公司就是牛,給我們公司提的意見都是錯的;哪怕意見是對的,我們也沒做錯;哪怕貌似我們做錯了,也是有原因的,沒人能做的更好;凡是提意見的都什么也不懂,都是技術低情商低的。

  5. Mu 對這篇文章的反應是贊一個
  6. zhaogang 對這篇文章的反應是敬佩
  7. 鄭好勤  這篇文章
  8. tinyork 對這篇文章的反應是好文
  9. 亞圣啊 對這篇文章的反應是贊一個
  10. 靳春城 對這篇文章的反應是敬佩,好文
  11. 單純只是現實面跟理想面的問題

    一個精湛的程序員有很多好的技術及思考
    但需要一年好好規劃及開發

    公司老闆:我怎麼知道給你一年是否可以完成,給你三個月把功能都做出來看看

    于是你要馬走人,不然就是做個半殘的成品
    恐怖的是如果你做出來了,這半殘的成品還可能直接就上線了
    因為公司需要賺錢,這樣才不會浪費他聘請你的錢

    我個人為程序員非老板
    我能認同,的確有一堆思考怪異的上司及要求
    越是大的公司,這種人越多
    但我們也只是小小程序員,上面的要求你不得不應
    所以寫出了很多怪異的代碼

    站在老板的角度我也能認同
    因為對他們而言,技術不是問題
    怎么創造錢才是問題

  12. Roy.Chang 對這篇文章的反應是贊一個
  13. 視角不同??⑷嗽蹦芄灰饈兜秸廡┪侍?,并且在自己所處的角色上做到,很難得,如果能夠以更高的視角看的話,項目經理能夠輕松不少。
    yy了,誰沒年輕過

  14. ZTON 對這篇文章的反應是贊一個
  15. luotaiyti 對這篇文章的反應是敬佩
  16. 你咋不用JDBC而用hibernate ,不用文件而用數據庫,時代在變遷,人在進步,以前的做法放到以前都是合理的,但以現在成熟的眼光來看,簡直一團糟,恐怕連coder也不願意再回頭看,你代碼不寫註釋是當時環境所致,但以現在來看,十幾個參數你不寫註釋,你在逗我? 不要總以當初寫代碼的心態來看現在的見解,還是那句話 ,時代在變更,老思想也該變了

  17. 文章開頭提到的問題很真切,而后文居然能給他一一反駁。我真的輸了。

  18. 李建鵬 對這篇文章的反應是贊一個
  19. 站在一個程序員的角度把問題一一看完,大部分還是很有共鳴,一個有顆技術心的人總是會有點技術潔癖的,在不過分影響成本和項目進度的情況下這樣的態度是值得贊同的。都是年輕時候過來的,也都是踩了各種坑才能找到更好的處理這些問題的方式??戳斯靜忝嫻幕馗?,通篇看下來的第一個感覺就是為了回復而牽強附會的找理由,就像樓上仁兄說的感覺:我們都是對的,就算我們做錯了也是有原因的。我贊同任何問題都需要放在一個特定的環境下去找原因,質量成本進度都得兼顧,不過有這樣的態度和細節觀察能力,更值得去引導而不是全盤否定

  20. 站在一個程序員的角度把問題一一看完,大部分還是很有共鳴,一個有顆技術心的人總是會有點技術潔癖的,在不過分影響成本和項目進度的情況下這樣的態度是值得贊同的。都是年輕時候過來的,也都是踩了各種坑才能找到更好的處理這些問題的方式??戳斯靜忝嫻幕馗?,通篇看下來的第一個感覺就是為了回復而牽強附會的找理由,就像樓上仁兄說的感覺:我們都是對的,就算我們做錯了也是有原因的。我贊同任何問題都需要放在一個特定的環境下去找原因,質量成本進度都得兼顧,不過有這樣的態度和細節觀察能力,更值得去引導而不是全盤否定

  21. 趙寧 對這篇文章的反應是贊一個
  22. 通篇看下來就是一個感想,我想把這個功能寫好,不行,再不上線我們就虧錢了;程序還需要優化一下,不行,再不上線就被人搶了市場了;我要寫一下注釋方便以后修改,都什么時候了,損失的錢你來賠???哈哈,有時候就是身不由己。

  23. 江錦泰 對這篇文章的反應是好文,垃圾,mark
  24. 偉男 對這篇文章的反應是好文
  25. 哈哈,同感。目前我的公司也是這樣,在返回的json里喜歡用逗號當數組,數據結構喜歡用~^!等特殊符號表達,而且還不考慮這些特殊符號的轉義問題。作為一個小小的程序員,不能改變什么,只能自己對自己說,管他們怎么寫去,自己有自己的判斷力就行了,此非久留之地。

  26. snowyying 對這篇文章的反應是好文
  27. 龍樓 對這篇文章的反應是贊一個
  28. 瑟瑟發抖!
    我也很鄙視那些復制代碼過來注釋都不改的人!

  29. 所以說中國只能出所謂只會賺錢的公司,而創新技術是無緣的。但是這些人恰恰不知道只有創新才能有錢賺??純次鞣餃碩災柿烤媲缶囊?,人家的產品比我們不知道好到哪里去了。對于產品質量的要求是一種態度和價值觀,無怪乎中國在各方面的技術都落后西方,看看我們的價值觀就知道想要趕上別人根本不可能。

  30. 王星  這篇文章, 并對這篇文章的反應是贊一個,好文
  31. 理查德第一 對這篇文章的反應是贊一個
  32. 虛無境 對這篇文章的反應是贊一個
  33. 戈飯  這篇文章, 并對這篇文章的反應是敬佩
  34. 投資回報率是管理者的問題;程序員有工匠精神才是對自己崗位負責

  35. DHclly 對這篇文章的反應是贊一個
  36. 一小枚程序猿 對這篇文章的反應是贊一個,好文
  37. 絕大多數問題都是強詞奪理的回答,為了躲避一將無能累死千軍的事實。哈哈

  38. sdsdd 對這篇文章的反應是贊一個
  39. ioan 對這篇文章的反應是贊一個

發表評論

電子郵件地址不會被公開。 必填項已用*標注