自動化平臺的幾個小計劃

前幾天聽同事感嘆了一句，說web前端的東西還是挺多的，每一個東西要弄明白用起來都得花上一些功夫。真可謂遠行無輕擔，看起來好像是那麼回事，做起來是另外一回事，所以也就間接讓我會感覺到我啥也沒幹。

不管具體是怎麼做的，做的好不好，程式碼寫得優美不優美，這些在從0到1的過程中不是最緊要的因素，最緊要的就是設計和功能提煉。

這裡所說的設計是基礎的架構，就好比水手要出海捕魚，是劃一個小漁船，還是一艘大船，前期的基礎設計不佳，在後面接入業務的過程中就很快遇到瓶頸，如果業務都跑起來了，然後大改，那這個影響可就大了，可能原來幾行程式碼的事情到後面得迭代很多的驗證步驟，分階段分批來最終滿足需求。當然也不能讓自己的系統設計的過於龐大，一下子成了航母級別，每張表都很不得放一個單獨的資料來儲存，管場景裡面用到了沒有，但是開源技術方案要多要炫，這樣也是不好的。

高屋建瓴，最終不落地，脫離了實際，也就脫離了價值。

然後是功能架構，這個部分的工作其實就有些偏產品經理了，因為需要明白需求的通點，需要分門別類的對需求進行功能抽象，最終想的和看到的產品能夠銜接起來。至少不會出現太多彆扭的介面操作或者是有歧義的細節。

這個部分的重點工作之一就是按照優先順序來梳理。哪個階段做哪些事情，按照一定的方式來組織起來，最終就會呈現出一個日程和計劃來。

做這些事情還是希望形成閉環，要不分門別類，面鋪的大，但是很難看到一些連線或者閃光點。就好比一個看起來比較基礎的功能，如果大家看了以後，發現這個東西好，那麼都願意去接入，都會把一些基礎的功能需求激發起來。

技術工作者的一大價值就是解決問題，解決的問題越多，才會得到成長。

這些工作做好之後，目前已經接近尾聲，我計劃儘快實現閉環，當然實際和自己預期的還是有差距，而且越深入瞭解，發現差距越大。

所以這個工作不得不放入一個並行的過程。接下來需要考慮實現的幾件大事，主要有指令碼管理，不能的功能模組和業務型別可以對應不同的指令碼，比如shell,sql,python等，總之指令碼需要管理起來，算是指令碼化的一個開始。

然後加入流程的部分，把這些指令碼化的操作能夠組織起來。