前兩天其他問答平臺推薦給我了一個問題：
一個JAVA學生的自述，很迷茫，這樣的現(xiàn)在我該怎么辦呢?
看完，想起這兩天一直在想的問題，就想把原來一些想法綜合起來寫一篇文章。
先說我看到的一些現(xiàn)狀：
- 大量學校在教授計算機專業(yè)，從清華、北大、985、211到大專、函授、青鳥培訓。
- 市面上出現(xiàn)大量IT公司，每個城市都需要IT公司支持智慧小區(qū)、健康碼到智慧城市、智能政務(wù)等本地化服務(wù)。
- 新一線城市IT公司大量出現(xiàn)，原來是北上廣深程序員支持全國IT建設(shè)，現(xiàn)在是新一線崛起，省會城市攜綜合本地公司支撐全省。
總的來說，寫程序這個行業(yè)，你發(fā)現(xiàn)越來越普通化了，他變成了日常生活中經(jīng)常看的見的普通職業(yè)，原來一個程序員可能是白領(lǐng)，現(xiàn)在可以明確的說，就是一個藍領(lǐng)了（大廠除外）。
這很好，說明我們社會越來越現(xiàn)代化，需要更多的IT支撐，但從行業(yè)內(nèi)部來看，我覺得卻有些與時代發(fā)展脫節(jié)。
比如我問一個問題，你們的架構(gòu)辦或者CTO、架構(gòu)師，向你們交付什么文檔？
詳細設(shè)計？ERD圖？或者干脆就是一個腦圖，一次項目講解說明？或者干脆就讓設(shè)計出圖，開發(fā)自己評估？
大多數(shù)公司，我估計真正負責架構(gòu)或者整體設(shè)計的大佬們，其實交付的應(yīng)該都逃不出這些東西吧？
這說明一個什么問題，軟件行業(yè)的管理，其實是指導形式的，中高層對下層工作人員所能起到的主體作用是指導你如何工作，而不是參與工作的過程。
換句話說，其實軟件行業(yè)還是學徒制，傳統(tǒng)作坊一貫的做法。
前幾年的時候，作為一家創(chuàng)業(yè)小公司的CTO，也這么做，我覺得這樣做很合理啊，我教授你做工作，你學習并做好就好了。
直到我發(fā)現(xiàn)這樣做似乎完全不起作用。
因為招聘的程序員，基本只接受了學校的普通IT教育（Java程序、數(shù)據(jù)結(jié)構(gòu)等讓大學生學起來一頭霧水的教程），然后去了一個培訓機構(gòu)學了幾天Spring框架，對我所提到的概念完全不能理解。
講個例子，有一次客戶說管理員里要設(shè)置一個超級管理員，把我們的經(jīng)理設(shè)置成權(quán)限高點，我就說小王（程序員），客戶說一個管理員層級不夠，需要設(shè)計多級管理員，包括管理員和超級管理員兩類，然后把xxx的權(quán)限設(shè)置成超級管理員，然后我的程序員就在程序里寫了如下代碼：
if (admin.Id == 43) {
admin.Role = "super"
}
我說這個43是什么啊，他說就是他們老大的系統(tǒng)ID啊。
我很無語，我嚴厲地批評了他，他也很委屈，從項目的角度看，他確實達到了這樣的現(xiàn)實目的，他認為沒有什么不妥，但是我覺得，我清楚的表達了幾個層面的事情：1）設(shè)計多級管理員，包括管理員和超級管理員兩類；2）把xxx的權(quán)限設(shè)置成超級管理員，你怎么能簡單的簡化成這樣，導致這個邏輯沒有擴展性，無法重復部署呢。
這個示例有點極端，但是普遍這種情況在大多數(shù)研發(fā)，特別是外包項目研發(fā)的時候存在。
從第二年起，我就開始認識到，簡單的教育不行，我必須要更加清楚地表達一些具有固定含義的要求，包括：
1）寫大量的文檔，任何指導工作都寫成指南，寫過的包括1）java設(shè)計要求，2）后臺設(shè)計要求，3）數(shù)據(jù)庫設(shè)計要求，舉個例子：
不使用0，或者“”、false等默認值作為正常情況
例如一個數(shù)據(jù)有status字段，表明其可以使用或不可以，則比如使用非默認值作為正常情況，例如1，“true”，true等，以避免因默認值導致流程在沒有指定該數(shù)值的情況下被認為是合理流程。
這個要求不僅公司要求，客戶也經(jīng)常性會要求
程序中使用0作為正常值是古老的C語言程序遺留下來的老毛病，當時，常常使用0作為正常，而使用負數(shù)作為系統(tǒng)異常，而正數(shù)通常拿來表示業(yè)務(wù)分支，這是因為c的語言模式造成的，任何我公司的正常代碼不應(yīng)該再應(yīng)用這種邏輯。
2）我開始在程序中，明確的以注釋形式要求哪些代碼哪些人可以改，哪些人不能改，以及改了之后的后果：
// 這是底層區(qū)塊鏈的調(diào)用函數(shù)，在任何情況都不得注釋，發(fā)現(xiàn)一次，處罰一次
recorder.AddRecord(GetOwner(info1.getSfz(), "2"), LocalService.getKabaoCallerid(), s.getDataid(),
GetNowTime(),
output.get("code").toString());
以此為起始，其實就引出了我今天的觀點：
以后的程序員會明確的分成程序員和碼農(nóng)兩類，程序員將類似工廠中的技術(shù)員，出圖紙，碼農(nóng)就相當于工廠的工人，只負責按圖紙?zhí)畛渚唧w邏輯代碼。
現(xiàn)有的架構(gòu)辦體制不再適用，架構(gòu)辦擴編成技術(shù)部，產(chǎn)出物從設(shè)計說明擴展為某種智能文檔，可擴展為代碼，可進行復核，可進行協(xié)作。
其他研發(fā)人員歸集為開發(fā)部，負責填充細節(jié)代碼，人員要求進一步降低，很可能靈活用工平臺會占據(jù)大部分人員供給，隨派隨用。
有人可能覺得我要不就是危言聳聽，其實很多國企早就這么做了，自己只招核心員工，大量的都是外派公司派來駐場的人。只不過協(xié)作界面現(xiàn)在的智能化和自動化程序還做不到像工廠圖紙那樣標準化。
這既是行業(yè)發(fā)展的必然，也是行業(yè)發(fā)展的需要，我也不想把自己的行業(yè)說的跟落后產(chǎn)能似的，但是未來可能他還真就這樣。
