在當下許多關於研發報道中，不時可以看到如下的描述：某研發團隊一年來，每週工作都超過80小時，研發人員加班超過晚上1到2點是家常便飯，經過大家的努力，公司新產品終於上線，大老闆也特別喜歡這樣的研發團隊，經常點名表揚。
對於這樣研發出來的產品，我是持懷疑態度的，如果本身具有豐富開發經驗的話，我相信也會深有體會。
另外記起報紙上的曾經報道，國家的某個科技人員，連續帶病工作，最後終於攻克了科研難點，最後這個科技人員也因為耽誤了**時間而因病去世云云。
在學生時代是非常的欽佩，但是，現在更多的是感到荒唐和無奈。
不僅想起了古語的張弛有道，「張弛有道」一詞出自《禮記*雜記》。 原文如下：
「張而不弛，文武弗能也；弛而不張，文武弗為也。一張一弛，文武之道也。」
解釋： 張，拉開弓弦。弛，放鬆弓弦。 比喻工作的緊鬆和生活的勞逸要適當調節，有節奏地進行。
軟體研發專案，是具有內在規律的，《人月神話》中關於沒有銀彈的文章，我想大家都耳熟能詳，高質量的軟體產品不是通過人海戰術，通過連續高強度的加班，就能夠取得成功的。如果不能夠做到張弛有道，可持續發展肯定會有問題，很可能的情況是軟體發布後，缺陷不斷，**質量難以維護，換過一撥開發人員後，軟體產品基本報廢。
所以，當有經驗的專案經理，作專案計畫的時候，肯定會考慮專案組什麼階段緊張，什麼時間放鬆，什麼時間需要加班，什麼時間需要進行培訓，讓團隊以最滿意的方式完成，這就是軟體專案管理的藝術。同樣的情況可以看看運動員，例如羽毛球，頂尖的選手，上場就絕不會一味的大力猛殺，肯定是有節奏的，否則不可能贏得比賽。
作為研發的管理者，必須對研發的節奏進行把握，當你看到研發團隊天天加班，或者每天下班到點走人的時候，是該警覺，思考，把研發節奏調整到「張弛有道」的時候了。
論有道難題
資料結構的書中有這樣的描述,程式 演算法 資料結構。我不同意這樣的觀點。這樣的觀點也不知誤導了多少的初學者。軟體開發再不斷的發展，這樣的論調早已過時，但還在程式設計界不斷的相傳。不知是書本的悲哀還是 高手 的悲哀。我們不斷的強調演算法的對程式的重要性，通過對演算法的熟練度來看乙個人程式設計水平的高低...
2015有道實習生研發筆試
回憶版 有些題記不清了 基礎題 1 下一段 輸出什麼 int a 5 int b int a 1 cout a 1 b 1 return 0 2 巨集 define fuc a a a int x 5 x func x cout 求輸出的值是多少 3 中序遍歷為abcde，前序遍歷不可能為什麼 4 ...
論 「運營主導型的研發」 和 「產品主導型的研發」
當我寫下這篇飽含我的經歷和磨難所體會到的文章後，勢必要得罪很多人，但是就事論事，不是要爭個你死我活，只是想單純的分享個人體會，並與大家討論進步 吸取更多的想法。首先，運營主導型的研發，缺乏統一的目的性 其次，運營主導型的研發，工作結果缺乏成就感，容易淪為工具 最後，運營主導型的研發，工作過程容易陷入...