前言

我是個碼農(nóng)，在職場干了多年，在超過10個公司服務(wù)過，遇到過各種怪現(xiàn)狀，拍案驚奇葩，不吐不快，太想寫篇文章吐槽一下。

 

這篇文章匯集了我10多年來的工作中遇到的各種經(jīng)歷，總結(jié)的心得，分別討論了團(tuán)隊與協(xié)作（同事/領(lǐng)導(dǎo)/客戶的交流）、技術(shù)與質(zhì)量（學(xué)習(xí)、技術(shù)選擇、質(zhì)量）、職業(yè)與事業(yè)（現(xiàn)實、追求、老油條、職業(yè)道德、典故、事業(yè)/經(jīng)驗）、找工作（獵頭/中介、應(yīng)聘、簡歷、面試別人）、辭職（原因/理由、信任）等，干貨滿滿的，里面還夾帶了我的很多秘密和典故，如果你認(rèn)真看，會回來找我贊的！?。?/p>

 

如果你非要叫我跑龍?zhí)状a農(nóng)，請不要在前面加個死字，謝謝。

 

下面的文章夾雜了不少英文，那是因為這些文字都是我在澳洲寫的，習(xí)慣而已，不是你們想象中的所謂裝逼，謝謝。

 

本文是我的個人經(jīng)歷和意見，請取濾網(wǎng)三錢，和著服用，謝謝。

 

協(xié)作與交流

 

同事/領(lǐng)導(dǎo)

林子大了，什么鳥都有，公司大了，什么人都有。有人的地方就有江湖，有利益的地方，就有沖突。

 

澳洲，跟美國一樣，是移民國家，一般每家公司都有各色人種。文化的差異，語言的溝通，總會造成各種矛盾。

 

根據(jù)這些年來的觀察，沖突一般有：1、邀功，當(dāng)你辛苦干完活，別人把功勞拿走了；2、推卸責(zé)任，不是你造成的問題，別人強(qiáng)加于你身上；3、小圈子排擠外人。

 

公司S，心累，現(xiàn)在公司部門和部門之間有嚴(yán)重的斗爭，各自為政，根本就不是想干活的，惡心的事情很多，譬如部門老大不干活，讓小弟干，小弟工作繁忙壓力大就爆脾氣，說話不像人樣，然后部門老大就各種推卸責(zé)任，還美化之，去它大爺?shù)?。

 

公司B，三個印度碼農(nóng)在印度，一個大胡子孟加拉國的，一個剛來澳洲兩天的伊朗人，一個來了澳洲很多年但口音極重的越南人，一個還在馬來西亞下個月才來報道的碼農(nóng)，加上來自黎巴嫩的上司，還有我，真的是聯(lián)合國。

 

公司K，精神分裂的部門女同事，菲律賓大媽，在公司呆了18年，在CTO背后聯(lián)合她的兩個馬來西亞小弟直接跟CTO的上司說CTO各種壞話，在CTO面前老裝很友好地狂笑，對待客戶是一樣的做法。

 

公司T，當(dāng)年很純真，但已經(jīng)目睹了各種利益糾紛。公司和別的公司協(xié)作做的GSP系統(tǒng)，一個醫(yī)藥銷售系統(tǒng)，產(chǎn)品做得差不多了，各種糾紛，后來產(chǎn)品就爛尾了。

 

公司T，我離職，老板請大家吃醬板鴨，味道特別棒，至今難忘，離職后還和老板保持了多年的聯(lián)系，每年春節(jié)還發(fā)祝賀短信，很精短，都是手寫的。

 

工欲善其事，必先利其器。開發(fā)工具，是開發(fā)中重要的資源，公司不應(yīng)該在這塊上有任何吝嗇。

 

公司S，我入職后發(fā)現(xiàn)開發(fā)部的機(jī)器，最老的7年了，新的也有3年老了，沒改一行代碼，重新編譯，需要5分鐘以上。跟我一起入職的有4個新同事，公司給我買的電腦是給其它同事買的3倍價錢，IT部經(jīng)理一臉正經(jīng)地跟我說：你丫的應(yīng)該覺得慶幸拿到這么貴的電腦。但我一臉無奈地跟他說：“雖然你買的是我要求的ThinkPad，我我希望是t4xx，你卻買了exxx，我才不想要呢！”。新來的項目經(jīng)理對公司安排給他的新手提電腦很不滿意，一大早打開的時候就已經(jīng)用力噼噼啪啪了，還吐槽連HDMI接口都沒有什么的，下班快走的時候還吐槽這i3 CPU配置都8年老的了。首先，講道理，每次i3換代都有新版本，不能刻舟求劍，但是，省這幾百塊不值得。

 

客戶

公司S，做IT的同事告訴我?guī)讉€真實的故事，忒搞笑了，其中一個是：客戶說電腦不正常，同事遠(yuǎn)程協(xié)助，很客戶說：“close all the windows"，然后客戶說“done"，同事說我這里看見還沒有關(guān)閉啊，客戶堅持已經(jīng)關(guān)閉。爭論半天，最后發(fā)現(xiàn)客戶關(guān)閉了的不是“窗口”，是“窗戶”。

 

公司S，有一個潛在客戶發(fā)來合同，要求我們的系統(tǒng)一年365日，100%在線，如果服務(wù)down了，按分鐘賠錢[允悲]。

 

技術(shù)與質(zhì)量

學(xué)習(xí)

只為一家公司賣命一輩子的，少數(shù)。即便只為一家公司干活，始終會有產(chǎn)品改進(jìn)甚至更新?lián)Q代的一刻，不管是用戶量上去了，還是用戶需求變更了，那總要學(xué)習(xí)新技術(shù)。一些公司，系統(tǒng)多年不改進(jìn)，員工就無欲無求了。等離開公司的一刻，才發(fā)現(xiàn)自己與社會脫節(jié)了，這種如溫水煮蛙，所以早就了很多養(yǎng)老心態(tài)的老油條 。

 

公司C，一個資深碼農(nóng)，離職之前，考高級程序員證，惡補(bǔ)，拿到證之后，離職了。

 

我不是喜鵲碼農(nóng)(The Magpie Developer)，不貪新厭舊，確實太多東西需要學(xué)，數(shù)據(jù)量太大了，每天太多東西可以學(xué)，時間不夠。舉個例子，基本的日常使用的工具，如開發(fā)工具，譬如Visual Studio，即便你每天用，很多有用的東西我就是沒留意，舉個栗子：你知道怎么快速復(fù)制、剪切、刪除整行代碼嗎？刪除一個詞呢？再舉個粒子，SSMS(SQL Server Management Studio)里面，怎么快速查看一個對象的相關(guān)信息，如一個表，顯示所有字段、主鍵、索引、約束等等？

 

最近看越來越多的網(wǎng)絡(luò)資源，一些要收費(fèi)，如一個網(wǎng)站提供了專業(yè)面試國際大公司的一對一指導(dǎo)服務(wù)，全程真題，還有全球20多個著名Web2.0公司的系統(tǒng)設(shè)計詳解，也就幾十刀，值得買。

 

看過很多技術(shù)文章，一些網(wǎng)站追求一些非常入門的內(nèi)容，譬如怎么做個多級菜單，動畫效果，等等，放在首頁，而一些干貨文章卻忽視了，悲哀。

 

技術(shù)選擇

前端、后臺、數(shù)據(jù)存儲，都有亂象。

 

前端尤其亂，對日新月異的那些前端技術(shù)無力吐槽，簡單來說，就是臟亂差，可惜，技術(shù)負(fù)責(zé)人，沒有把好關(guān)，選擇了錯誤的技術(shù)。

 

技術(shù)選型，決定因素很多，譬如技術(shù)帶頭人，譬如技術(shù)儲備，公司現(xiàn)有情況，等等。著名云程序日志記錄提供商raygun，幾個月之前扔掉node.js改用.net core，性能提升20倍。但就是有些公司的技術(shù)人為了反對而反對，選擇一些不切實際的解決方案[攤手] 。

 

舉個栗子，譬如SOA家的微服務(wù)的設(shè)計與使用。網(wǎng)上諸多最佳實踐，在多數(shù)公司里面都沒有、也不會實現(xiàn) ，不管是決策者、財力資源、還是人力資源等限制 。大家審視一下現(xiàn)在公司的系統(tǒng)， 你連現(xiàn)有系統(tǒng)的的基本的模塊化做到了嗎？如果沒有，憑啥你就覺連模塊化就做不到就能把微服務(wù)做好？ 甭想微服務(wù)了。微服務(wù)不大適合初創(chuàng)或小公司，Martin Fowler說過，上微服務(wù)需要現(xiàn)有的流程、監(jiān)控、快速發(fā)布基礎(chǔ)， 而且發(fā)布的成本和復(fù)雜度比單系統(tǒng)服務(wù)高，服務(wù)間的網(wǎng)絡(luò)數(shù)據(jù)交換成本額外高，本地開發(fā)測試復(fù)雜度和成本也高。 放遇到異常，還是看業(yè)務(wù)，一些transactional的該怎么樣就怎么樣，一般流程化操作，如用sagas，容易導(dǎo)致死流程，這種怎么監(jiān)控和解決具體問題具體分析。一般做法是有機(jī)制重試n次后還不行就escalate到IT，還有日志這塊也是很多坑的。

 

繼續(xù)這個栗子，微服務(wù)的基礎(chǔ)，用公有云的話，論靈活性，那就azure function；論scalability，還是azure batch吊；論可控性，還是service fabric強(qiáng)；論簡單易用陪流程，還是azure logicapps好；論業(yè)界認(rèn)受度，還是Amazon家的AWS λ 吊。

 

MYOB是澳洲著名的老牌會計系統(tǒng)，直到幾年前他們的解決方案還是Windows桌面程序，客戶需要用citrix遠(yuǎn)程進(jìn)去跑的。。。anyway，原來這公司的名字是Mind Your Own Business的縮寫。

 

質(zhì)量

在編程的時候，我們一定要想象一下，以后維護(hù)我們自己的代碼的那個人會成為一個暴力的精神病人，并且，他還知道我們住在哪里。

 

MVP，對體育運(yùn)動來說，是most valuable player(最有價值運(yùn)動員/球員)；對開發(fā)人員來說，是most valuable professional (最有價值專家)；對產(chǎn)品開發(fā)來說，是minimum viable product (最簡可行產(chǎn)品)。一些公司開發(fā)系統(tǒng)，一開始就勾畫宏大的愿景，幾個月甚至幾年之后，產(chǎn)品還是沒有見蹤影。相反，一些公司追求最小化的可行產(chǎn)品，每個版本只發(fā)布一個新功能。

 

看了很多公司的系統(tǒng)，就像在吃蒼蠅。

 

怎么給垃圾系統(tǒng)擦屁股：你被扔了一坨熱氣騰騰的爛代碼，幸運(yùn)的話只有幾百萬行，沒有注釋，僅可能有的就是早已過時的文檔，寫這些代碼的爛碼農(nóng)早已去逍遙快活。

 

公司X，第一天，下班了，累癱，腰酸背痛。首兩周都是各個部門的不同人來介紹公司、各種業(yè)務(wù)、各個系統(tǒng)，找了幾個機(jī)會跟開發(fā)團(tuán)隊聊了一下，順手看了一下他們的開發(fā)，具體就不談了。只能說公司業(yè)務(wù)成功，和開發(fā)不是正相關(guān) 。

 

公司B，客戶端用OLEDB從Visual FoxPro讀到DataTable，序列化到JSON，壓縮，存到Azure BLOB，然后寫相關(guān)記錄到Azure Service Bus Queue，服務(wù)器端Service Bus接收到信息，取相關(guān)BLOB，解壓，反序列化，再Bulk Copy到Azure SQL Server的臨時表，再轉(zhuǎn)換格式化各字段讀關(guān)聯(lián)表，最終到達(dá)目標(biāo)表。。。蛋疼的感覺？

 

公司B，巴西碼農(nóng)，為了格式化法國人名常見的組合名(就是名字中間有-、·、空格等符號后面第一個字母要大寫)，他洋洋灑灑寫了80多行代碼，逐個字母替換，而且為了應(yīng)付空格，又重復(fù)了一遍。。。。

 

公司B， 又優(yōu)化另一報表，初步加了索引重構(gòu)邏輯后，從原來超時到現(xiàn)在1分26秒，再分析，發(fā)現(xiàn)另外一個瓶頸是引用了這函數(shù)，報表先調(diào)用一個主的人名格式化函數(shù)，這函數(shù)再多次調(diào)用上述那函數(shù)，重構(gòu)后，只需要6秒。

 

公司B，挺無語的，部門一碼農(nóng)，一個流量值(字節(jié))要格式化顯示成兆，他直接/(1024*1024)，根本不明白那些小數(shù)就不能顯示了，然后呢，還Round兩位小數(shù)，問和尚借梳子啊。

 

公司B，數(shù)據(jù)庫那塊，簡單地說，就是數(shù)據(jù)庫規(guī)范范里面的第1/2/3范式都完美地忽略了 。。。前端界面對一些字段沒有做校驗，所以系統(tǒng)跑的時候各種爆，譬如期望是數(shù)值但里面有各種詭異字符，期望是郵箱地址但是文字。。。日志那塊，每個方法執(zhí)行都做一下開始/結(jié)束日志，隨便點(diǎn)幾下界面，幾百K的日志內(nèi)容[攤手]

 

我發(fā)現(xiàn)，懶/爛碼農(nóng)，很喜歡復(fù)制粘貼。

 

公司S，部門一開發(fā)人員，擅長復(fù)制粘貼代碼，原本幾百行的代碼，硬生生搞成1萬多行。他說：“我寫代碼，瘋起來，我自己都害怕！”某天，這個碼農(nóng)在看自己的代碼的時候，迷茫了，看不懂了，代碼邏輯流程太亂。所以，他只能打開Visio，逐步把邏輯畫出來了。。。[攤手]

 

公司S，系統(tǒng)是asp.net webform + vb.net + 大量第三方重量級UI控件，前端、后臺和數(shù)據(jù)庫性能都很爛，根本不是SaaS，也不支持多服務(wù)器，各種各樣的錯誤。我躊躇滿志地來到公司，第一天就跟大家說：“做開發(fā)這么多年，爛代碼我看慣了，所以大家放心，不管多爛的代碼我都可以重構(gòu)改造的”，3個月后，我歇斯底里地指著屏幕上的爛代碼，狂叫道：“你們這樣寫代碼是不人道的?。?！”

 

公司S，系統(tǒng)各種問題，性能表現(xiàn)差強(qiáng)人意。其中一個表現(xiàn)是，越越來越慢，譬如同一個功能，所以參數(shù)一樣，今天跑5秒，后天6秒，大后天7秒這樣。。。最后發(fā)現(xiàn)還是跟我之前優(yōu)化的日志有關(guān)，雖然改成異步批處理，但是日志基于文件，每個最大2M，不斷翻滾，日志文件名邏輯是掃描所有文件來取下一個文件名。

 

公司S，一天，分析了一下數(shù)據(jù)庫，一個客戶7天做了150萬次數(shù)據(jù)庫讀操作，約讀取了200G數(shù)據(jù)，加上前端那些Web Form冗余HTML，實際從服務(wù)器上走出的數(shù)據(jù)是很夸張的(按我司的規(guī)模)，數(shù)據(jù)庫請求延遲更厲害，一個客戶每次請求都要等0.2秒。

 

公司S，存在多個業(yè)務(wù)邏輯錯誤問題?？蛻舴从硵?shù)據(jù)有問題，部門的同事分析數(shù)據(jù)和代碼，最后發(fā)現(xiàn)關(guān)鍵邏輯是讀的配置文件，而這個配置是應(yīng)該按具體客戶的設(shè)置來的，但變量寫成了static。

 

公司S，系統(tǒng)運(yùn)行時大量日志生成，同步寫入日志文件，我改成了異步。還有，每個頁面加載完成，都記錄一下用戶的IP、加載開始時間、加載結(jié)束時間等信息，也是同步的，加上其它業(yè)務(wù)邏輯寫得不行，所以很忙，我也改成了異步，定時批量寫入日志。

 

一些公司的碼農(nóng)，不把警告當(dāng)警告，完全無視之。

 

公司S，主系統(tǒng)，編譯的時候，顯示254個警告，不能再顯示更多了。

 

公司S，下班前，每周五全員工公司例會中，一個IT部的同事問我：“Wilson，你們部門是否會把機(jī)器學(xué)習(xí)應(yīng)用起來”，我心想：“你們連數(shù)據(jù)倉庫都沒做，所謂商業(yè)智能這只是做了些基本報表，數(shù)據(jù)量也不是很大，我以前隨便處理都是幾十億起跳的，還想機(jī)器學(xué)習(xí)？？？” 然而，我還是老實說：“大家知道Google alphago嗎？就是最近打敗了最牛的圍棋手的人工智能系統(tǒng)？”。沒人回答。我繼續(xù)“我們寫程序，是直接解決問題。機(jī)器學(xué)習(xí)，是我們寫一個邏輯，讓機(jī)器其去利用現(xiàn)有的數(shù)據(jù)進(jìn)行分析找出最優(yōu)方案，這是非直接解決問題，”

 

數(shù)據(jù)從用戶在界面輸入開始生命周期，經(jīng)過傳輸?shù)竭_(dá)網(wǎng)站，經(jīng)過處理(譬如ETL)，再存到數(shù)據(jù)庫，后續(xù)還可能有數(shù)據(jù)倉庫二次處理等，最后數(shù)據(jù)失效被刪除。這中間很多事情需要做，但，最重要的第一步，是確保用戶輸入是校驗過的合法數(shù)據(jù)，否則進(jìn)入系統(tǒng)后造成連鎖反應(yīng)，修復(fù)成本太高。

 

我服務(wù)過的很多公司，界面輸入缺乏基本的校驗，譬如長度，用戶輸入長一點(diǎn)就爆了。郵件格式也不判斷，系統(tǒng)發(fā)送郵件的時候各種爆。

 

公司S，系統(tǒng)設(shè)計有問題，實現(xiàn)有問題，運(yùn)作有問題。拿各種通知客戶的定期報表郵件，地址完全不校驗，同一個客戶出現(xiàn)幾十種的郵箱域名，譬如正確的是foo.com.au，實際出現(xiàn)：foo

coma.u, foo.com,foa.com.au, foo.com.....，一些明顯是不合法的格式，一些是不存在的域名，等等，發(fā)送的時候也不校驗[攤手]

 

公司X，系統(tǒng)各種安全漏洞，SQL注入輕而易舉。

 

遇到過各種奇葩軟件/系統(tǒng)設(shè)計，譬如LinkedIn Android版，經(jīng)常告訴你無法發(fā)送內(nèi)容，不告訴你為什么，之前打的長長內(nèi)容都丟了，根本草稿等臨存功能。一些銀行的app，允許你增加、減少每日轉(zhuǎn)賬額度，但根本不告訴你要增加到多少或者減少到多少[攤手]。

 

公司S，現(xiàn)有的系統(tǒng)10多年前開始寫的，技術(shù)陳腐，其中一個功能是根據(jù)不同客戶不同產(chǎn)品從可自定義模板那里動態(tài)生成表單，這個功能是用的第三方的，本來不復(fù)雜，但隨著業(yè)務(wù)發(fā)展，現(xiàn)在單純渲染界面的代碼行超過10,000。我在用angular改造，目前代碼行200，可以顯示了，接下來就是做一些交互[攤手] 。

 

公司S，Web系統(tǒng)性能差，有幾個原因，其中一個，是HTTP壓縮都沒有啟用，頁面/資源加載都要用較長時間，我發(fā)現(xiàn)之后，順手啟用了[攤手]我司的Web系統(tǒng)性能差，有幾個原因，其中一個，是HTTP壓縮都沒有啟用，頁面/資源加載都要用較長時間，我發(fā)現(xiàn)之后，順手啟用了[攤手]。

 

公司K，系統(tǒng)的數(shù)據(jù)庫設(shè)計很多奇葩的事情，就命名這塊就看不下，用戶標(biāo)識(UserId)這個，同一個數(shù)據(jù)庫里有以下各種形式：UserId、UserID、user_id、userid、iduser、USERID、id_user等，而且大部分是同一個人搞的 。

 

公司E，隔三差五發(fā)現(xiàn)公司印度菊苣們寫的代碼好多坑，譬如前端js肯定就不判斷對象是否null，直接取屬性，然后后續(xù)的代碼都無法跑了。后端的代碼更奇葩，直接try/catch抑制錯誤（catch無任何邏輯），今天發(fā)現(xiàn)一功能無法跑，分析后發(fā)現(xiàn)，數(shù)據(jù)庫表字段類型是nvarchar，代碼里定義是int，菊苣不解決抑制錯誤就完了

 

這么多年來，各種平臺，看見過各種軟件的奇葩實現(xiàn)。

 

公司Z，現(xiàn)在的業(yè)務(wù)系統(tǒng)，一個復(fù)雜的申請流程，所有數(shù)據(jù)都暫時保存到cookies，今天終于爆了，客戶的一個下單JSON后超過4k，boooom！

 

寫爛代碼的人多用舊版本的語言，這樣他們就能名正言順地不用新版本的語法糖來精簡代碼。譬如c?的自動屬性，expression body、LINQ等，他們都不會用。更惡心的是重新發(fā)明更爛的輪子，數(shù)值TryParse、DayOfWeek等重搞，最惡心的是壓制錯誤：一個對象幾十個屬性，不判斷null，幾十個try/catch逐個屬性輪 。

 

公司A，數(shù)據(jù)庫這塊，因為某GIS產(chǎn)品Web服務(wù)的特點(diǎn)，把數(shù)據(jù)庫分割為：每個客戶3個數(shù)據(jù)庫，然后呢。。。然后服務(wù)器就幾十個數(shù)據(jù)庫。。。。其實做到一個數(shù)據(jù)庫是沒有什么難度的。。。?？梢灶A(yù)見以后各種血淚 。

 

公司A， 開發(fā)這塊。。。之前弄過Windows Mobile，后來用Sharepoint（怨念！） + Silverlight（怨念?。。?。。。。加上某GIS產(chǎn)品+.NET插件（啊啊?。F(xiàn)在在上馬#WPF#（怨念?。。。?，然后準(zhǔn)備招聘iOS開發(fā)人員和Android開發(fā)人員（啊啊啊啊。。。

 

公司A， 做的產(chǎn)品主要是基于GIS的產(chǎn)品，給服務(wù)人員提供地理任務(wù)標(biāo)注/指示，然后開展工作。然后呢。。。。#沒有自己寫的服務(wù)器端#，#不直接存取數(shù)據(jù)庫#，完全用某GIS產(chǎn)品提供的Web服務(wù)。。。。然后性能各種爆。。。。。。。

 

公司A，是典型的傳統(tǒng)使用微軟產(chǎn)品的企業(yè)，IT/基礎(chǔ)設(shè)施這塊都是AD/exchange server/SCCM等，最近弄了個JSP寫的helpdesk系統(tǒng)，所有東西都往那里扔，連新產(chǎn)品/新項目/改進(jìn)都放那里，還包括bug管理。。。

 

公司B， 系統(tǒng)是Web應(yīng)用，引用了大量的第三方Web前端代碼，超過2500個JavaScript、CSS文件。。。。每次發(fā)布要等好久好久。。。其實絕大部分都不需要用到，就是硬度碼農(nóng)買1送10地狂塞進(jìn)去，而且grunt build那套也不用，打開首頁的時間都夠我去找菲律賓妹子了

 

公司B， 相比上一家公司，這公司的產(chǎn)品狀況要好很多（盡管很多問題）。上一家公司的產(chǎn)品我接手之前只是基于第三方產(chǎn)品做擴(kuò)展，完全不是自主知識產(chǎn)權(quán)，午飯商業(yè)化，我從頭寫，大半年完成，比第三方產(chǎn)品還好很多功能多很多。好歹現(xiàn)在的直接自主產(chǎn)權(quán)，技術(shù)較新，但坑多。

 

公司B， 這公司是和這行業(yè)的領(lǐng)先者之一合股搞的SaaS解決方案，軟件+硬件結(jié)合，市場很大，不過，合股公司總部就是倉庫，大家繞著會議桌開發(fā)，旁邊的沙發(fā)坐了一堆五湖四海的合股公司員工吃各種風(fēng)味的午飯。。。新公司的工作場所還在裝修，隔壁，其實還是倉庫改造。。。

 

公司B， 需要使用的第三方系統(tǒng)，其市場占有率超過50%，但用的Visual FoxPro開發(fā)。。。。。。。。因為官方?jīng)]提供API，我們的玩法是直接逆向工程數(shù)據(jù)結(jié)構(gòu)然后自行山寨業(yè)務(wù)邏輯玩弄數(shù)據(jù)。。。。。、、

 

公司B， 8個硬度碼農(nóng)（已經(jīng)炒掉5個）做出來的web系統(tǒng)，后臺ASP.NET MVC+nhibernate。。。每個controller都automapper create一次map。。。還直接數(shù)據(jù)CRUD。。。前端angularjs，每個controller直接http req。。。各種null ref問題。。。

 

公司A， 我發(fā)現(xiàn)了，代碼的質(zhì)量很差，主要原因是：大量復(fù)制粘貼、反復(fù)操作(譬如反復(fù)的獲取同一個值做而不是讀一次做變量)、冗余的循環(huán)、沒有使用較新的語法糖(譬如lambda)而自行弄10多行代碼實現(xiàn)一行LINQ搞定的、很多情況都沒考慮大小寫敏感，強(qiáng)行catch異常而不是判斷

 

公司A， 入職一個半月，發(fā)現(xiàn)前任挖了很多很大的坑，一些短期內(nèi)無法填，一些長期也無法填，怎么辦？逐步填，一天填一個唄。

 

公司A， 開發(fā)，是典型的四無：無設(shè)計、無文檔、無規(guī)范、無流程，無法無天（噢，五無了）。數(shù)據(jù)庫設(shè)計亂七八糟，性能極渣，處理幾百萬數(shù)據(jù)的ETL也要跑幾個小時，還會內(nèi)存耗盡（32G）。。。。代碼那個就下次繼續(xù)吐

 

公司A， 產(chǎn)品用的C#開發(fā)，Visual Studio做IDE，代碼管理用的SVN，陳腐得很。產(chǎn)品開發(fā)還是waterfall，新版本發(fā)布用windows登錄觸發(fā)復(fù)制更新，無力吐槽。。。給CIO建議，改用Visual Studio Online，搭配scrum，項目管理/代碼控制關(guān)聯(lián)起來，這只是第一步，還有很多 、

 

公司A， 雖然不同州不同客戶不同的業(yè)務(wù)需求，但絕大部分業(yè)務(wù)/邏輯是一樣的，完全可以把基礎(chǔ)部分標(biāo)準(zhǔn)化，但是呢，現(xiàn)在的做法是每個客戶單獨(dú)有3個數(shù)據(jù)庫。。。每次基礎(chǔ)功能/邏輯更新，就要更新幾十個數(shù)據(jù)庫。。。

 

公司A， 數(shù)據(jù)庫的更新允許通過sharepoint修改任意記錄，然后呢，沒有后臺邏輯封裝，然后呢，一些表大量觸發(fā)器，一些觸發(fā)器幾百行代碼。。。

 

公司A，產(chǎn)品的日常數(shù)據(jù)查看/修改，除了專門的管理工具/客戶端，還可以通過sharepoint來，有一個自定義的數(shù)據(jù)列表WebPart來綁定一個數(shù)據(jù)源，還有一個數(shù)據(jù)編輯WebPart，根據(jù)PK來更新數(shù)據(jù)，竟然允許直接修改任意記錄。。。。。沒有后臺邏輯，沒有存儲過程。。。我靠

 

公司A， 系統(tǒng)的部分?jǐn)?shù)據(jù)導(dǎo)出和通知是用的python腳本，質(zhì)量放一邊（容錯、復(fù)制/粘貼等），產(chǎn)品環(huán)境根本就沒成功跑動過，一個月多月了，沒有人去排錯。。。今天開會，我一下子就找到問題了，print組合輸出某數(shù)據(jù)庫值null。。

 

公司S，審查代碼，發(fā)現(xiàn)多個地方都出現(xiàn)一個詭異的邏輯，文件輸出的時候，定義編碼是GB2312，我跟寫代碼的碼農(nóng)說：“可是，咱們不在中國啊[攤手]，而且，那可是10多年前的做法啊[捂臉] 。

 

職業(yè)與事業(yè)

現(xiàn)實

鐵打的營盤流水的兵，大家都是可以被拋棄的卒子，不想成為邊角料，就要不斷提升自我。

 

職場如古代的歡場，上班族都是出來賣的小姐，區(qū)別是一些天生麗質(zhì)技術(shù)過人的成了頭牌、花魁，日子自然滋潤，如果碰上要么色中惡鬼的土豪劣紳或一見鐘情的傻情郎給之贖身(大量股票&公司上市)，那就可以安穩(wěn)過下半輩子。否則等到徐娘半老只能被拋棄。少數(shù)早早財務(wù)自由，轉(zhuǎn)個身，還是做了老鴇(老板)

 

職場如古代的后宮，上班族都是佳麗，區(qū)別是一些天生麗質(zhì)技術(shù)過人的成了各級妃嬪，日子自然滋潤，如果碰上皇上寵幸，成為高人幾等的貴妃(大量股票&公司上市)，如果懷上龍種誕下皇子，那就可以成為寵妃甚至皇后(技術(shù)帶頭人)。否則等到徐娘半老只能被拋棄。少數(shù)早早財務(wù)自由，拿個封地自立為王(老板)。

 

追求

如果人沒有理想，那和咸魚有什么區(qū)別？

 

我不是普通碼農(nóng)，我是傳說中的那種10x碼農(nóng)，效率是普通碼農(nóng)的10倍，但我的待遇是普通碼農(nóng)的10倍嗎？不是。所以，我今天還得起床去搬磚。

 

出污泥而不染，濯清漣而不妖，用這個來形容我每日在爛代碼的槍林彈雨中匍匐前進(jìn)而幸存下來，挺適合的。

 

追求，除了代碼質(zhì)量，還有崗位，和待遇。

 

我那“離職公司就上市”段子大家都知道了，我經(jīng)歷過幾次，2次錯過，1次主動放棄。中午請公司Z的技術(shù)總監(jiān)吃飯，他是老員工，整個系統(tǒng)主要是他搞起來的，公司最近拿了幾億刀的授信，市值是1.85億刀，但公司只給了他價值6萬的刀股票。另外一個所謂的CIO，來了沒多久，沒啥大貢獻(xiàn)，但他要求不拿工資換股份，現(xiàn)在有4%，價值約740萬刀 。

 

追求，就是不甘于只完成任務(wù)，而是要做得更多。

 

多年前，因為要監(jiān)控不同公司的不同系統(tǒng)運(yùn)行狀態(tài)，寫過多個針對性的監(jiān)控程序。做過一個分布式計算，c井寫的，RESTful API通信，cluster server發(fā)送計算模塊(動態(tài)的c井代碼)到所有tenants，每個tenant跑完代碼結(jié)果送回server，就是map reduce的過程。這種模式，可以做很多事情，譬如以前做過分布式查詢，任意客戶端(臺式電腦、手機(jī)等等)查找結(jié)果然后匯總 。做監(jiān)控系統(tǒng)，遇到狀況就觸發(fā)條件然后通知相關(guān)人。后來改用第三方的，譬如Nagios，再后來，改用云服務(wù)。以前用過monitis.com ，還行，現(xiàn)在公司要這個功能，所以再做了比較，發(fā)現(xiàn)還monitis最適合 。

 

做公司S，我發(fā)現(xiàn)公司沒有這種監(jiān)控系統(tǒng)，我主動做了出來，效果很好，找出不少問題，damage control比以前好多了。剛才監(jiān)控到物理內(nèi)存突然占用多了600M，分析后發(fā)現(xiàn)一個業(yè)務(wù)邏輯把整個數(shù)據(jù)表取出來在內(nèi)存出來，空間占用1.6G。這就是追求。

 

公司S，花了些時間，給公司的系統(tǒng)做了個高度可配置的數(shù)據(jù)歸檔功能，可以指定任意來源和目標(biāo)服務(wù)器、數(shù)據(jù)庫、業(yè)務(wù)表、數(shù)據(jù)記錄條件等，自動創(chuàng)建目標(biāo)數(shù)據(jù)庫、表，完了自動備份壓縮、遷移等等，這個，是之前沒有人能做出來的。這就是追求。  

 

http://www.cnblogs.com/unruledboy/p/DevLif.html