上午在給新上的項目排期，之前在實驗室做項目階段，最怕的就是估時間，估多了甲方不同意，估少了自己做不完，但這個問題肯定要解決，從啟蒙那學了估期的方法，將任務分解，分成小模塊，感覺難度不大就 0.5 天，感覺比較復雜就 1 天，感覺非常復雜就繼續(xù)劃分模塊，再將這些劃分出的模塊進行排期，用這種方式很容易就可以將任務拆解完，最后將每個模塊的估期匯總，便可以得出整個項目需要的時間，聯(lián)調(diào)的時間根據(jù)接口數(shù)量以及復雜度進行估算，最后再給自己兩天 buffer 時間以防萬一。

這樣的方式使得項目排期變得不再無處下手，讓整個流程清晰，不過對于開發(fā)的要求就相對嚴格，必須在規(guī)定的時間之前完成相關模塊的開發(fā)，這就回到之前提到的，給自己一個合理的時間規(guī)劃，并且嚴格執(zhí)行。這應該是一個非?；A的習慣，但是之前沒有養(yǎng)成，只能現(xiàn)在來補，亡羊補牢，為時未晚。

中午吃飯時，啟蒙問我在公司的感覺如何，個人而言，對這家公司非常有好感，很幸運能加入，他鼓勵我好好加油，說這段時間會是成長最快的時間，對此我深信不疑，這段時間我能感受到我的進步，接下來還有更多的挑戰(zhàn)，希望通過這些挑戰(zhàn)上升到一個新的境界，因此不能放松對自己的要求。面對未來，即緊張，又興奮。

這段時間想清楚了一件事，技術沒有非此即彼。沒有最好，只有最合適。記得來公司面試，二面我問教主，為什么后臺不統(tǒng)一用 JAVA 或者 PHP，前端沒有統(tǒng)一使用框架，為什么不用 vue，而是用 react。現(xiàn)在看這個問題，大概因為一個人做項目做久了，太理想化，學校作業(yè)和實際項目工程差距很大。

學生時代，在項目里遇到很爛的代碼，看不順眼就想著重構(gòu)，在百度實習期間也看過很多很爛的代碼，但不敢碰，原因是因為不知道改了之后會出現(xiàn)什么問題，這就是問題關鍵所在，什么是好代碼？什么又是爛代碼？在生產(chǎn)環(huán)境中，首先需要確保的是項目的穩(wěn)定性，保證項目的正常運行，所做的一切改動的前提都應該是項目的穩(wěn)定運行。我時常吐槽爛代碼都是以開發(fā)者的角度看問題，出于代碼潔癖，并沒有從項目的角度看待問題。從這個角度看，我可能是個好的編碼者，但是不是一個合格的開發(fā)者，開發(fā)者應該以解決問題作為思考的方向，而不是為了編碼而編碼，只有編碼者才會糾結(jié)編碼方式，開發(fā)者只會考慮解決方案。但往往好的開發(fā)者都會養(yǎng)成好的編碼方式。

前幾天我在 less、sass、stylus 之間糾結(jié)，思考哪一個才是最佳的方案，最后發(fā)現(xiàn)這個問題本身就是個偽命題，因為作為一個合格的開發(fā)者，我應該三者都會，在處理問題的時候立刻上手解決問題，我可以選擇一個作為個人偏好，語言之間沒有最好，只有最合適，在需要的地方使用合適的語言，理解了這一點，頓時感覺視野開闊。

反思之前非此即彼的想法，實屬懶惰的想法，學習好一門框架也好，構(gòu)建工具也罷，難以掩蓋的是我懶惰，不想學習新框架新工具的小心思。因此面對選擇時，我會很自然的選擇自己熟悉的框架或者工具，而不是出自于項目需要的考量。這樣看來，我永遠不可能成為一個好的開發(fā)者，

不應該局限一隅，哪有什么最優(yōu)解，只有相對最合適的解。