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

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

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

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

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

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

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

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

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

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

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

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

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

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

大公司的程序員，很多都處于甲方視角，沒有什么項目周期的壓力，代碼可以得到很多人的審視、走讀和檢查，一些公司測試人員數量是開發人員的兩三倍，并且測試場景也能夠得到充分保證，客觀上決定了，他們的代碼質量不可能很低，就算低也沒關系，有人、有時間教你提升質量。

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

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

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

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

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

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

說遠了，扯回來。

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

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

道阻且長，大家努力哇～