在大公司來說，寫爛程式碼的人相對會少一點。但是寫爛程式碼也沒有關係。因為他們會有嚴格的程式碼審查手段。如果說你的程式碼過於亂。那麼是提交不上去的。

當然我們不排除只要功能實現，即便演算法實現惡劣一點，低調一點，也是能夠被接受的。

所以對於企業領導來說或者老闆來說，只要能夠功能實現，那就可以了。

至於效率的最佳化，那可以慢慢來嘛。

其實這就跟在哪兒都有好人和壞人一個道理，大公司也有能力差的，小公司也有能力強的。具體到我們網際網路行業，很多時候，程式碼質量不是一個程式設計師自己能夠決定的。

設想一下你是一個只有10個人小團隊的軟體公司，老闆親自跑業務接專案，喝了半個月白酒好不容易拉來一單生意，告訴你，這個app客戶要得很急，從設計到交付只有20天的工期，你們趕緊弄吧，客戶尾款打過來我請大家新馬泰出去玩一圈。

然後你和你的兄弟們就開始點燈熬油的加班，加班，加班。

設計有缺陷？不影響使用就行。

測試沒到位？不影響使用就行。

程式碼不美觀？不影響使用就行。

這種情況下，要求什麼程式碼質量，美觀，簡潔，不太現實。現實的是什麼？要賺錢，要完成這件事。

他當然知道程式碼質量不行，在某處有隱患，但那不是當務之急。而且，為什麼說程式碼質量好壞不是程式設計師一個人決定的？因為整個軟體開發流程就不是隻有他一個，還有測試，還有設計，還有產品經理，如果這些人缺席（小公司測試缺席很常見），程式碼質量是很難好起來的。

到頭來，20天緊趕慢趕交付的軟體，所有的功能都處於一個“湊合能用”的狀態，這就是小軟體公司的常態。

這就好像，有人要過河，請你出個解決方案。

方案一：你可以在旁邊撿幾塊爛木板搭在兩岸；方案二：也可以仔細量好尺寸、排定工期、選購材料、召集人馬來造一座漂亮結實的大橋。

兩座橋，都能解決問題，甚至根據場景的不同，都可以很好的運轉下去。對於客戶，或者使用方來說，這個橋怎麼造的、用什麼材料造的，造得過程如何，這些都不重要，重要的是，我能用。

而對於造橋的人來說，你是如何造起一座座橋，如何經歷這個過程，跟自己的職業生涯是息息相關的。

小公司的程式設計師，要經常面對一個“快速出活”的問題，老闆要你快，客戶要你快，所以很多功能上、程式碼質量上、測試範圍上就欠考慮；

大公司的程式設計師，很多都處於甲方視角，沒有什麼專案週期的壓力，程式碼可以得到很多人的審視、走讀和檢查，一些公司測試人員數量是開發人員的兩三倍，並且測試場景也能夠得到充分保證，客觀上決定了，他們的程式碼質量不可能很低，就算低也沒關係，有人、有時間教你提升質量。

在選擇公司的問題上，我始終主張：如果有得選，那麼第一份工作最好選擇去稍大、相對正規的公司。

因為，我在大公司、小公司和中等規模公司都待過之後，悟出一個道理：

當你在小公司，為制度不合理、流程有問題而感到困擾的時候，如果你沒在大公司待過，你壓根都不知道正規的流程和正常的制度是什麼樣的。

就像你上學的時候，如果考到一個稍好的學校，你遇到好老師、厲害的學長學姐的機率會遠比你在普通大學就讀時來得高，對不對？

職場也是同理，大公司總會聚集一些行業大牛，跟他們多接觸，會從根本上提升你的業務素質，還有職業視野。

這些並不是虛的東西，相反，這些東西有些時候比具體的工作能力還要有用，還要實在，而且能夠影響你整個職業生涯。人的格局和視野，是很重要的，可以決定未來幾十年活在哪個層次上。

說遠了，扯回來。

說起來可能會有人笑話我，但是我想說，我對於自己從事的工作，不管是測試還是寫作，都有一定的榮譽感和責任感。我覺得有些軟體是不能崩潰也不能閃退的，因為這種事情一旦發生，使用者所付出的代價太大。比如你寫了大半夜的稿件，word突然閃退，windows突然黑屏，就問你暴躁不暴躁？如果明天就是deadline，沒法按時交差，誰來承擔這個後果？

寫到這裡，回頭看看剛才用造大橋來比喻軟體工程，我真心覺得現在很多app的程式碼質量跟大橋完全不能比。再湊合的大橋，它也不會動不動就垮塌吧？但是卻有很多app或者頁面，就連幾千幾百的併發訪問都扛不住。你要問為什麼扛不住？真的就是程式設計師能力太差這一個原因嗎？不，最大的可能是，老闆沒有給團隊一個測試的時間。再複雜的程式，只要有足夠的時間，大多都可以做到堅固美觀和耐用——就像一座正常的橋樑一樣。

道阻且長，大家努力哇～

程式碼這東西沒有捷徑可走，就是著名的10萬行定律，而且有些東西還是要靠自己悟，不停的思考，嘗試，實踐。當你程式碼量到一定程度的時候，你一定會遇到各種各樣的不爽，比如結構混亂，無法複用，擴充套件性差，牽一髮而動全身。這時你就要思考，查資料，如何解決這些問題。當你把這個瓶頸突破，你會有種打通任督二脈的感覺，然後還會遇到下個瓶頸。當然遇到牛逼大佬指引你，真是有那種賓利車標的感覺。如果對程式碼不感興趣，只是為了，寫100萬行還那樣