開(kāi)篇
從其他前輩口中聽(tīng)過(guò)這樣一句話:
軟件開(kāi)發(fā)，coding能力只占40%，稱為硬技術(shù)。剩下的60%的軟實(shí)力更大程度上決定了軟件的質(zhì)量。
做人篇
帶新人
自己慢慢熬成了團(tuán)隊(duì)中的老人，自然開(kāi)始承接了傳承的工作，讓新鮮血液們快速融入LEADAL研發(fā)大家庭。
但是，這個(gè)過(guò)程中發(fā)現(xiàn)了自身存在很多問(wèn)題。
比如：
- 講解過(guò)于理論化，不能很快地幫助對(duì)方解決當(dāng)下的問(wèn)題，反而讓對(duì)方感到困惑或是有炫技嫌疑。
- 不知道怎么去合理地切割模塊，導(dǎo)致最后雙方本應(yīng)各自維護(hù)的js有沖突的部分。
- 說(shuō)話方式有時(shí)候會(huì)比較尖銳，會(huì)傷人自尊。
- 還有一個(gè)印象非常深刻，就是我忍受不了新人的bad code,于是竟然親自去改對(duì)方的代碼，結(jié)果對(duì)方一更新代碼發(fā)現(xiàn)命名和程序思路完全變了，竟然不知道怎么繼續(xù)編下去。上了對(duì)方自尊不說(shuō)，還耽誤了項(xiàng)目的進(jìn)度。
其實(shí)這里面大部分責(zé)任在我，畢竟是我在帶人，我起主導(dǎo)作用。
如果再讓重新走這樣的一個(gè)過(guò)程（這是一個(gè)經(jīng)典的反思方式）。
首先，我會(huì)多花些時(shí)間在模塊的劃分上，定義好邊界，井水不犯河水，各自維護(hù)各自的模塊，避免代碼維護(hù)上的沖突。其次尊重新人的勞動(dòng)成果。每個(gè)人都有當(dāng)新手的過(guò)程，如果自己的勞動(dòng)成果輕易就被別人改掉了，刪除了，無(wú)疑是一種否認(rèn)和打擊。指出存在的問(wèn)題，不要親自去改。
關(guān)系從破裂到和解再到復(fù)原
關(guān)系破裂的開(kāi)始。
曾經(jīng)因?yàn)橐粋€(gè)小誤會(huì)（或者說(shuō)是我好心辦壞事），其實(shí)是想激勵(lì)對(duì)方（類似于激將法），說(shuō)了一些打擊新人自信心的話語(yǔ)。導(dǎo)致對(duì)方對(duì)我有些負(fù)面意見(jiàn)。
關(guān)系的和解。
后來(lái)在團(tuán)隊(duì)領(lǐng)導(dǎo)的指導(dǎo)下，我們進(jìn)行了開(kāi)誠(chéng)布公的談話，說(shuō)開(kāi)了，也就沒(méi)事了。其實(shí)是我以為沒(méi)事了。結(jié)果至少很長(zhǎng)一段時(shí)間我漸漸能感覺(jué)出來(lái)我們之間還是有隔閡了，有種別扭的感覺(jué)。
關(guān)系的復(fù)原。
這是從放低自己的姿態(tài)開(kāi)始的。真誠(chéng)地去關(guān)心對(duì)方，真誠(chéng)地在對(duì)方需要幫助的時(shí)候幫助對(duì)方（渴時(shí)一滴如甘露，醉后添杯不如無(wú)），發(fā)自內(nèi)心地降低自己有些膨脹的意識(shí)。所謂“路遙知馬力，日久見(jiàn)人心”。既然初心是好的，也就不怕人家誤會(huì)。最后還是能成為朋友的~I believe~
處事篇
平衡研發(fā)時(shí)間和產(chǎn)品質(zhì)量
慢慢成為了項(xiàng)目負(fù)責(zé)人才發(fā)現(xiàn)需要去平衡研發(fā)時(shí)間（研發(fā)成本）和產(chǎn)品質(zhì)量，有些東西是要基礎(chǔ)功能必須實(shí)現(xiàn)的，就要先執(zhí)行。有些用戶體驗(yàn)的東西尚且不影響功能的情況下，就可以在下一版本進(jìn)行優(yōu)化處理。畢竟我們是要為交付期限負(fù)責(zé)的。
say No——學(xué)會(huì)合理地拒絕需求
有一段時(shí)間，大家人人都成了緊繃的彈簧，任務(wù)量大，交付時(shí)間緊。技術(shù)總監(jiān)已經(jīng)明確表示，X項(xiàng)目的需求盡量不接了，但我還是不懂得拒絕。
最后自己忙的半死。
平衡研發(fā)時(shí)間和產(chǎn)品質(zhì)量的部分已經(jīng)提到了，實(shí)際上軟件開(kāi)發(fā)是在交付壓力的情況下進(jìn)行的，非常講求平衡（當(dāng)然，良好的項(xiàng)目經(jīng)理盡量不讓壓力丟在研發(fā)人員身上，因?yàn)檫@樣做對(duì)項(xiàng)目質(zhì)量有害無(wú)利）。
于是我就親身被教育了怎么去拒絕需求。更接地氣的說(shuō)法是砍需求。
原本一個(gè)多群柱形圖（基于d3.js實(shí)現(xiàn)），還需要提供群組的差異化顯示，我的回復(fù)是：“可以做，但是需要消耗一定時(shí)間。”總監(jiān)直接就說(shuō)，單個(gè)的柱形圖有沒(méi)有？有是吧，那你把多群柱形圖拆分成n個(gè)單個(gè)柱形圖。
起初我還沒(méi)理解，停留在固有思維上，還解釋計(jì)算位置啊之類的成為實(shí)現(xiàn)難點(diǎn)。后來(lái)總監(jiān)又解釋了一遍我才清楚。
我對(duì)砍需求的理解就是：找替代方案，優(yōu)雅降級(jí)~
定位篇
給自己一個(gè)定位。
就目前的工作側(cè)重分配而言，20%研發(fā)新產(chǎn)品，40%維護(hù)老項(xiàng)目（修復(fù)bug以及處理版本升級(jí)的新需求），40%在思考如何推進(jìn)公司整體web開(kāi)發(fā)模式的優(yōu)化。
比如：
- 挖掘前端框架初始設(shè)計(jì)不合理或已過(guò)時(shí)的地方，進(jìn)行優(yōu)化。
- 接觸新框架思想引入公司內(nèi)部框架。vue和angular同樣都是MVVM模式的框架，但vue是基于getter setter的單向數(shù)據(jù)流，但angular是基于臟值監(jiān)測(cè)實(shí)現(xiàn)了雙向數(shù)據(jù)綁定。這種MVVM模式的設(shè)計(jì)模式怎么更好地引入公司。（要的是本土化的解決方案，而非直接生硬引入）
- 如何更好地將Node引入公司現(xiàn)有地開(kāi)發(fā)模式，利用Node命令行及其小工具提高全員開(kāi)發(fā)效率。順便引發(fā)對(duì)前端工程化及打包機(jī)制的思考。
- 怎樣更好地讓前端和后端協(xié)作（前后端分離）。比如后端集成后的前端頁(yè)面插入了大量后端模板指令的東西，將導(dǎo)致頁(yè)面沒(méi)有復(fù)用價(jià)值或很難再被移植復(fù)用。再比如，后端改js會(huì)和前端的部分js沖突掉，目前公司的集成大部分是由后端人員來(lái)做。這種模式是否可優(yōu)化，前端怎么更好地參與進(jìn)集成工作？
- 前端如何更優(yōu)雅地mock數(shù)據(jù)。現(xiàn)在我們mock數(shù)據(jù)都是手動(dòng)一個(gè)個(gè)在拼json,這個(gè)過(guò)程能否簡(jiǎn)化，提供一些特殊語(yǔ)法？可參考：活兒好又性感的在線 Mock 平臺(tái) - Easy Mock
- 代碼審查。其實(shí)目的有兩個(gè)，一方面是幫助green hand更好地成長(zhǎng)，另一方面是想發(fā)現(xiàn)組件命名風(fēng)格，設(shè)計(jì)思路，那些可以進(jìn)行合理的統(tǒng)一規(guī)范。
- 怎么才能更好地形成技術(shù)交流（討論分享）氛圍，而非停留在相互問(wèn)問(wèn)題的階段。比如對(duì)近期的項(xiàng)目做匯報(bào)，闡述技術(shù)細(xì)節(jié)。比如介紹目前前端領(lǐng)域流行的思潮，圍繞這個(gè)展開(kāi)討論，如何更好的有機(jī)地融入公司框架。
- 讓組件更加精小，而非多功能戰(zhàn)車。玩過(guò)紅警的人都知道多功能戰(zhàn)車，它既能打天又能打地，還能承載運(yùn)輸戰(zhàn)斗部隊(duì)的工作，因而獲此名。但是對(duì)于維護(hù)人員來(lái)講，維護(hù)多功能戰(zhàn)車可能會(huì)是夢(mèng)魘。因?yàn)門A必須先大概了解原組件的設(shè)計(jì)思路，之后要考量修改點(diǎn)是否會(huì)影響其他功能。通常情況下，新增了一個(gè)功能需求，可能對(duì)做大量兼容。比如目前最難維護(hù)的組件就是ui:workspace。而且現(xiàn)象是越新增東西，越膨脹，越難維護(hù)。
維護(hù)者最希望維護(hù)那些功能少而精（相對(duì)專一）的組件了。于是這個(gè)過(guò)程其實(shí)對(duì)抽象能力要求很高。對(duì)公共的部分要有高度抽象的意識(shí)和能力。 - 如何讓組件的設(shè)計(jì)（至少是整體設(shè)計(jì)思路上保持一致性）。曾有機(jī)會(huì)，我有幸（之所以說(shuō)有幸，是因?yàn)檐浖_(kāi)發(fā)上一般要求誰(shuí)作為原作者找誰(shuí)反饋）維護(hù)到了其他人的組件。發(fā)現(xiàn)在某功能的實(shí)現(xiàn)上，對(duì)方的思路和我完全不同，而且引入了一些莫名奇妙的magic number（魔法數(shù)字，就是那些不加注釋，寫死的，容易讓人困惑的數(shù)字）。這給維護(hù)工作帶來(lái)了麻煩。
我在想如何在整體思路上統(tǒng)一組件開(kāi)發(fā)的代碼結(jié)構(gòu)，命名風(fēng)格，讓代碼更易讀。畢竟，團(tuán)隊(duì)協(xié)作中，代碼并不是只給自己看。
整體而言自己漸漸就是走向了中觀與宏觀之間的技術(shù)把控。但并不是說(shuō)忽略了微觀層面的東西。也會(huì)根據(jù)興趣，去學(xué)習(xí)es2015，es7，svg，canvas，深入css等等。但很明顯，微觀層面的影響力太小了，頂多是個(gè)人成為技術(shù)大牛。但我更想做到的是大家伙一起成功，這樣的幸福感是不一樣的量級(jí)。
結(jié)語(yǔ)
再過(guò)一百零一天，就是我來(lái)到LEADAL的整整第二個(gè)年頭了。
101，百尺竿頭，更近一步！
整整兩年的時(shí)光，學(xué)到的太多，創(chuàng)造的也多，改變亦多，可謂青春無(wú)悔！
