周五幫以前部門的同事查乙個測試環境的許可權錯誤的問題。乙個使用者在系統裡的許可權設定，一切很正常。但是從中間層的許可權檢查老報錯。雖然這個系統的許可權檢查部分是我一年多以前做的，而我已經換到另外乙個部門有一段時間了，但是看到同事為難的表情，還是義不容辭的過去幫了忙。
大家把問題的排查主要集中在許可權檢查部分。其實，這個許可權檢查的設計很簡單，當時由於檢查的資料非常多，而且全部存在乙個資料庫中，所以我把核心邏輯全部封裝在乙個資料庫函式中，然後為不同的檢查情況提供了不同的儲存過程介面。核心邏輯在當時根據不同資料情況也設計了上千個單元測試。每次對核心邏輯進行修改或者優化的時候，都要經過嚴格的測試檢查。同事給我看了使用者的許可權設定，和中介軟體的儲存過程呼叫，都沒有問題，但是為什麼會報錯呢？而且這個許可權模組當時經過了嚴格的測試，難道真的到兩年後會找到這麼明顯的問題？經歷了乙個小時的痛苦除錯，最後終於發現問題不是發生在許可權模組，而是在前端的flex部分。前端在介面切換的時候錯誤的使用了快取中的資訊，導致把錯誤的引數發到了中介軟體中，造成真個的問題。
問題找到了之後，我自然接受了一頓感謝。看著同事給前端和中介軟體的程式設計師打**解釋問題，又寫了一封冗長的郵件要求他們修改**，我只能一笑：乙個小時前還頤指氣使的前端程式設計師有的忙了。這個故事其實很平淡無奇，每天發生在不同的it公司，不同的it部門。寫程式就是這樣，發現問題永遠比解決問題難，更有意思的是問題往往不在我們所關注的地方，所以程式設計師加班調程式找bug，可以說是再正常不過的了。
看到這裡，大家肯定要問你為什麼要在週末花時間寫這麼乙個無聊的故事呢？難道真的是閒的蛋疼？你不嫌浪費時間，不要浪費我們看的時間啊。呵呵，其實下面開始才是今天要討論的問題，那就是it開發部門的分工和協作問題。這個問題在很多年以前其實本不是問題。在那時候，大多數程式設計師都是像iron man一樣的孤單英雄，乙個人從客戶需求，編寫**，到測試，上線和生產支援全部搞定。隨著軟體開發產業化和規模化，這個手工作坊式的經營慢慢被拋棄了。一是由於乙個人的精力實在有限，二是隨著it系統越來越重要，公司無法接受這種一人包攬的風險性。it軟體行業的第一次分工也就這樣形成了：軟體需求，軟體開發，軟體測試，軟體部署，軟體維護。
今天我們不在這裡討論以上分工是否合理，不去研究為什麼搞需求的為什麼後來都成了專案經理，而寫**的卻還是程式猿。我們在這裡只看軟體開發這部分。隨著軟體越來越龐大，軟體開發分層理論的提出，軟體功能又被細分為表示層，中介軟體，後台，和資料庫。很多公司也就根據這種橫向的軟體層次劃分對開發部門進行行政劃分和管理，程式設計師也就根據自己的術業專攻被安排在某乙個功能層面上了。很多程式設計師也樂於這種模式，因為這樣可以專注於某一領域，而不是什麼都搞，什麼都不精通。這樣的模式使用長了，it公司和部門也就自然而然的按照這種模式去劃分公司的行政部門了。發展到這個階段，一旦軟體出現問題，我們就會看到幾個部門的經理在一起和自己底下的程式設計師加班加點，問題嚴重的話，不免也會互相推卸責任。而程式設計師呢？由於只了解自己的**，但只見樹木不見森林，所以不免相互推脫。這樣不但解決問題的效率非常低，而且會產生很多不必要的人事矛盾。
其實，我們應該更推崇另外一種it部門管理模式，那就是根據業務的功能劃分，每乙個小組來實現front to back的功能，這樣，乙個小組，一撥人會掌握乙個相關功能的全部知識，當問題出現了，由於整個功能都是乙個部門做的，不但不會有互相推卸責任的問題，問題解決起來也會比較快，因為每乙個程式設計師都應該對整個業務流程有理解和認識。
對上面說的這種模式，很多it管理者都會不以為然，因為，他們會認為這樣做的話我要為每個團隊配備dba，中介軟體開發，和前端開發的人，他們還要幹自己不精通的東西，這不是重複勞動和提高成本了嗎？其實不然，只要作為管理者鼓勵這些團隊互相交流，並且對每個團隊的技術方案進行整體審批，當你開啟了大家交流的通道，聰明的程式設計師們都會自己互相學習的。管理這方面其實我不想多說，因為明白的管理者是不需要我說的，而糊塗的管理者看到我說的也不會去改變什麼。當然，還有一種管理者，他們明白事情該怎麼樣，而自己的影響力卻不能改變什麼。
從我們每個程式設計師的角度來說，究竟哪種模式好呢？很多人會認為精通乙個領域，成為專家大牛是理想的，所以前一種模式會優於後一種。我個人並不否認成為技術大牛是很厲害的，但是在這裡我提出一種新的思維方式。首先，我們要考慮幾個問題，有多少程式設計師可以成為領域的大牛呢？有多少企業在it領域是靠技術吃飯的？有多少it專案是因為技術而不是人事管理搞砸的？在公司招人的時候，是乙個高階管理難找，還是乙個會特定技術的人難找？這些問題的答案告訴我們兩點，那就是，成為技術大牛很難，而技術不是在it行業最安身立命的本錢。對於像我一樣的大多數程式設計師來說，其實一味的去鑽營技術並不是什麼好的出路。相反，學會在it公司於人打交道，把事情做成，將會使你的職業發展如虎添翼。作為一名程式設計師，如果你現在的工作允許你接觸很多東西，請你一定要珍惜。如果你現在的工作只是整個軟體中乙個層中的一小部分，那麼，其實也不要擔心，沒有條件，我們可以創造條件。這幾年流行跨界，其實程式設計師，最需要跨界。
委託開發合同與合作開發合同的區別
委託開發 合作開發 責任不同 委託方支付研究開發經費和報酬，提供技術資料 原始資料等，研究開發方憑藉自身的努力和具備的 知識完成研究開發成果。各方當事人共同從事研究開發工作，實現合作開發合同目的 技術能力只需要 研究開發人具備上述 能力 人員和條件。合作開發合同的各方當事人都必須具備一定的技術能力 ...
企業常見的三種資料部門架構優與劣
問題 為什麼傳統bi沒有達到今天網際網路資料應用的高度呢?在之前的傳統bi可能因為這些因素，所以沒有達到今天的資料在高度，可能是網際網路本身發展的因素，資料對於網際網路企業價值。但其中有乙個很大的因素，可能是傳統的bi，更多是偏重資料倉儲的架構，根據需求來幫報表。在資料部門沒有一批主動去思考業務，思...
促僅開發者間交流與合作的胡思亂想
之前提出了乙個sourcesafe.light的專案，定位於遊戲內的原始碼管理。現在可以對於sourcesafe.light做進一步的梳理。1.會使用開發功能的玩家已經脫離了玩家變成mod開發者。那sourcesafe.light，其本質功能是為了mod開發者服務的。給mod開發者提供的後台，可以暫...