看到這篇文章:html
我腦海中的優秀技術團隊算法
以爲講得很不錯,須要學習。編程
關於人安全
1. 好奇心。由於好奇心,對未知領域的探索,用技術來作不少神奇的事情,例如炫酷的動畫?碉炸的算法?人工智能?遊戲?物理引擎?漂亮驚豔的頁面?想一想你是否是由於這些技術而義無反顧的衝入編程大軍的。架構
有時候若是實在看不到一我的對於持續學習的熱情,我甚至直接生硬的問對方,「你業餘時間會作些什麼跟技術相關的事情」,而後獲得的回答,
一般是「看書」「看論壇」「看源碼」。其實這就是敷衍了事了,這些事情只是一個程序員最基本的一些學習方法。
你是如何「持續學習」的,你看過一篇文章以後,對於其中涉及的一些知識點,你如何去強化?如何去實踐?甚至如何引入到工做中來?
你的工做或者是項目都作得平平無奇,那你看書看論壇都是在看什麼呢?看了以後又解決了什麼問題?
如何判別一個解決方案的正確性?你如何一步一步分析問題?如何debug你的代碼?而後,解決問題以後,你作了什麼思考?
是不是你的知識面有問題,須要系統補充下某個方面的技術點?你是否研究了它周邊的知識?寫一篇博客,備忘順便分享給網友?
這裏又涉及到知識管理的方面。總之每次遇到問題其實都是一次對你的知識面的擴充時機,最終這些都會變成你的經驗。
在工做多年以後,這些潛移默化的知識會讓你可以快速對一個問題做出判斷,會在你腦海中造成一套體系,幫助你快速分析和解決問題,
不論是你的方向是架構師,仍是業務leader,都須要這些能力。
一般,你作事的方式態度,就決定了你的將來。工具
最終目的都是經過這些細節發現一我的的潛力:學習
好奇心決定了你能在技術這條道路上走多久;測試
學習方式決定了你可以在這條道路上越走越高;優化
而解決問題的方式則決定了你可否造成方法論,成爲一位真正的資深工程師。
做爲一名普通員工,我還指望有這些關鍵字:
樂於分享,讓我能夠被動擴充知識面;
和藹真實,不爲人情世故操心專心作個寫代碼的美男子;
牛逼哄哄,讓我大開眼界的牛人那是最好不過的,光聽那些名詞就足夠我出去吹半天了,對於開闊思路視野有奇效。
關於團隊
不少團隊,基本沒有「管理」。所謂管理,不是說有個老大管着你,指揮你作這個作那個,而是你這個團隊是否有
「目標」 「規劃」 「預期」。
你的團隊是單純的實現業務?仍是有所規劃?你理想中的團隊架構是如何的?人員分配如何?技術棧如何?規範如何?流程如何?如今有何不足,做何改進?這些其實就是對「管理」的拷問。
而這些拷問,其實關注點主要就是你的團隊是在健康成長,仍是放養或者原地踏步?若是進入沒有方向的團隊,恐怕自身的成長也不會有大的進步。
這裏的規範化有幾種含義。
代碼規範,這個不用多說,最基本也是最容易達成的,方法能夠有eslint等,加上按期的代碼review,以及團隊內的規範文檔等。
方法規範,如何引入新技術?多人開發如何進行?如何保障代碼可用性?如何保障發佈安全?如何有效利用日誌?等等,
這些問題都須要造成方法論,有一套流程來保障。例如引入新技術,咱們須要
調研試用 - 產出優劣報告 - 產出腳手架 - 多人review腳手架 - 分享+文檔 - 新項目試驗 - 問題總結分享 - 優化 - 全面投入使用,
過程當中會要求一些產出,目的都是爲了評估好優劣,而且造成一套規範,而不是隨意引入一些不可控的技術。
上面說起的其餘問題,咱們都會造成本身的一套規範,落地分享和文檔,跟蹤執行。這就是團隊規範的方法論。
流程規範,一個需求如何產生?如何評估其用戶價值和可行性?如何進入開發手中?如何排期?是否有完善的項目管理流程?測試發佈如何進行?
一個團隊的開發若是是亂哄哄沒有標準秩序的話,開發會很累,這些實際上是項目經理的職責,
從開始對需求的把關,到產品經理的把關,到交互視覺把關,到技術方案排期評估,到聯調跟進測試發佈。作好不易,作很差你們就會很累。
規範化的最終目的,一個是提升開發效率,另外一個是確保團隊開發的可持續性,減小「坑」出現的概率。這些問題一般是創業公司技術團隊的通病。
一,讓你們共同成長;
二,你們各司所致,找到本身在整件事情中的價值定位;
三,事情自己推進了團隊開發效率,這是其最基本的價值。
做爲一個我的,其實對團隊的指望大致還有:
很難作一些方法論或者是管理思路的分享,一個是由於還不夠成熟,你們都在摸索;另外一個重要的緣由是,不少方法論其實就是一句話或者幾句話,更重要的是執行到位,不然說出來都會很虛。
可是團隊到了必定階段以後,必定要有目標和方法論,不然仍是原始的行軍狀態,你們都會迷茫,內耗也會很是高。