說實話，這次的需求並不是很明確。雖說這種小系統，沒必要每次需求都搞個資料字典，每個資料之間的關係什麼的。但是如果這些最基本的要素都缺失，那**怎麼寫下去？
最起碼基本的大框架邏輯要有。
乙個功能，交給新人。他會一步一步摸著黑往前走，然後摔倒了，爬起來，換個方向——他喜歡在黑暗中摸爬滾打。這並非壞事，但是可能這樣拼拼湊湊寫出來的東西，後面的維護成本，測試代價，都非常之高。而且也降低了他自己 的工作效率。作為leader，我能做的是，首先搞清楚這個功能主要是什麼流程，有幾個主要的部分。
和團隊成員一起討論，大家集思廣益，得出這個流程有哪些基本的部分。大家討論比自己乙個人思考，不管是效率方面還是完善程度，都要好很多。確定框架後，其他的事情會清晰明朗很多。
將乙個大的任務，分成一些小的「零件」，讓他先去造這些零件，最後再讓他把這些零件組裝起來就行了。告訴他每個小零件有什麼樣的入參，需要完成什麼樣的功能, 我希望的輸出是什麼格式等等。至少我把握了大的邏輯沒有低階bug。至於他的零件造的好不好用，因為是小零件，發現bug，除錯也會相對容易。
好愁，這次的**review要受苦了。
人員管理的一些感悟
1 乙個好人頂十個 爛人 個體的能率究竟有多大差距？市場的回答往往是最靠譜的，以架構師為例，有的年薪百萬，有的僅區區十萬。身價的背後是可以給公司創造多少價值。那些亮了紅燈的專案團隊人數往往不少，烏央烏央一屋子人，可以客戶就是不愜意，可見人頭多沒用。關鍵是有合用的人。這種人不僅要具備深厚的技術積累，還...
關於遞迴的一些感悟
前些天筆試思科時碰到了一道c的遞迴題目，當時一直糾結在退出遞迴時，其輸出應該只有最後一次printf吧。好吧，我承認我真的很菜，不過我現在弄明白了，遞迴說白了就是自己呼叫自己，當遞迴深度條件不滿足時就退出了遞迴，關鍵點在於退出遞迴後的函式是如何返回的。其實我們可以把遞迴認為是幾個函式在一層層的呼叫，...
關於專案管理的一些思考
好記憶不如爛筆頭 所以還是要記錄下來的。關於專案管理，作如下的簡要描述，可以給自己乙個明確的提示。it 行業，一般的專案分為七大模組，分別為 需求分析，概要設計，詳細設計，和單元測試，系統測試，安裝和移植，專案管理等，當然還可以細分為其他的模組，不過主要可以從這些方面來著手。可是很多時候，我們在專案...