團隊交流記錄 - 2020-04

算法練習

從「想通了碼不出來」進階到「想通就能碼出來」，咱們須要足夠熟悉編程語言，須要足夠多的編程實戰經驗。團隊制定一個活動幫你們進階：每週2、週四集體刷 leetcode 每日一題，週五總結分享。

但 leetcode 太注重代碼時間、空間效率，會有如下問題：

• 對遞歸不友好，寫遞歸容易內存佔用過多或者堆棧溢出，
• 對函數式不友好，寫 map filter reduce 不如寫循環效率高，
• 爲了提升效率，用技巧略去一些中間步驟，例如本應該是「輸入->樹->字符串」，會經過技巧把「樹」省略掉，

這些都會引誘人寫爛代碼。所以團隊先達成一致：刷題的目的是鍛鍊你們把思路快速轉化成代碼。咱們要追求高效的思路、清晰的代碼，不要追求技巧和捷徑。

---

以後還討論了一個問題：

若是咱們已經達到了「想通就能碼出來」，後續的目標是什麼？

後續努力的方向有 2 個：

• 看問題要看清本質，用最直接的招式給問題致命一擊；
• 瞭解產品現有功能及發展趨勢，可以在架構上考慮全。

---

先設計再編碼

咱們在總體框架上有設計，但開發頁面或者組件時，咱們大都直接上手就寫，邊寫邊想，邊寫邊重構。因爲你們的習慣、經驗不一樣，最終你們寫出的數據流千差萬別。咱們須要尋找一種圖，它可以表達組件之間的數據流。你們用這個圖來思考設計、表達設計，而後一塊兒 review，簡化數據流，以後再動手編碼。

---

轉管理崗

轉管理崗是否是都是這個過程？

1. 技術獨擋一面
2. 帶幾個新人作產品
3. 團隊擴大，變成 manager

我是這麼走過來的，但我相信必定存在別的方式，只是我不瞭解。

我經歷過如下幾個階段：

1. 技術獨擋一面，工做駕輕就熟。
2. 上面分配幾個新人，讓你帶着一塊兒作。以爲帶人真費勁，還不如本身幫他們作了。
3. 帶出了幾個得力助手，編碼靠他們，本身天天分分工做、發發郵件、開開會就行。
4. 焦慮感襲來：我這樣下去會不會完蛋，萬一有人離職，或者更嚴重公司開了我怎麼辦？
5. 繼續上進，抽空學習、抽空寫代碼，確保團隊任何人走了，本身仍然能 hold 住項目；確保本身的技術能力是領先的。
6. 關注範圍從前端到產品，再到後端。