「全棧」工程師筆記/記一個完整的項目流水帳

　　引語：相信不少人都自認爲本身是個全棧工程師，無論有沒有驗證過，我也不例外。心中總有一種傲氣，事情都能作，只是作得好很差，時間夠不夠的問題！因此，對不少事情，我實際上是一點不怕的，隨着時間的推移，人老是應該要進步的，去作一些沒作過的事，纔對得起成長二字！
　　恰好上上個月，公司有一個新的項目需求，須要作一個全新的系統，可是看起來也不難，因此任務就交給了我。我能夠說我是這個項目負責人嗎？應該是能夠的！可是，最開始就已經存在了一些坑，等着我去跳，好比過需求的時候，我卻不在場！整體算下來，流程是這樣的：

　　1、過什麼項目需求？
　　　　需求確定是要過的。
　　　　1. 要作什麼？
　　　　2. 哪些能作，大概要多久能夠作好？
　　　　3. 哪些不能作，爲何不能作，替代方案是什麼？ 
　　　　4. 功能的必要性，哪些功能是必須的，哪些是可選的，哪些是多餘的，之後的方向是什麼？
　　　　 整理過需求後，大概就知道整個項目是什麼樣的了。

　　2、寫什麼計劃文檔？
　　　　因爲是公司內部使用的平臺項目，說什麼不須要美觀之類的，所有的基礎就只有一些抽象的原型圖，其餘的所有工做就交給開發人員（最開始就只有我本人，後來加入了一位多年開發經驗的大師兄），所以在我計劃裏寫了，靜態頁面模板編寫：3天。
　　　　由於只有我本人幹，因此，在寫項目計劃文檔的時候，我只管按照個人我的意願，就把時間給評估上去了（這最後被證實是本身給本身挖了大坑），各類功能，我幾乎都以1天2天或0.5天來算，功能點也是寫得比較抽象。由於畢竟，計劃這東西，就是一拍腦門想出來的事。
　　　　最後，把計劃發給領導時，領導說，開發時間太長，能不能再短一點（我當時幾乎是崩潰的，由於我已經儘可能把時間壓縮了）。其實我也理解，領導的意思是儘快完成。
　　　　基本上全部的計劃都會被必定程度上的延後，因此，領導讓你早一點的意思，其實基本上也是讓你按照這上面的時間來完成。
　　　　計劃就是你作事的證據，不可大意了！

　　3、劃分什麼模塊？
　　　　這一塊嚴格來講，不少項目基本算不得是一個流程的，至少我這個項目算不得，由於，其實就幾個字就描述清楚，扯那麼多幹嗎呢，哈哈哈。。。

　　4、設計什麼數據庫？
　　　　這個是很是重要的環節，若是把這一塊作好了，會給之後的工做減輕很多壓力，若是沒作好，後面將致使各類問題，尤爲在不是你一個在作事的時候，又會增長許多的溝通成本！
　　　　設計的基本原則就是，看須要些什麼信息，有哪些信息是公用的，會在哪裏產生其餘效果，詳細參照需求文檔，適當考慮擴展性！
　　　　這個環節，必定要讓領導過一下的，他知道的比我多，考慮的點和我也不同，關鍵是，最後出事了，也算是內心有個底，畢竟領導本身看過了！
　　　　然而，很奇葩的是，對於這個重要的環節，我幾乎只花了不到一天的時間就完成了！

　　5、搭建什麼框架？
　　　　因爲公司不讓使用外面的框架，並且其餘項目的代碼，目錄結構混亂，因此決定使用內部框架，進行構建系統。可是，內部框架還明顯不成熟，就連一個像樣的幫助文檔都沒有，惟一的一個幫助文檔是框架目錄中的一個readme.md,使用了極爲簡單的文字描述了功能。
　　　　不過，最終，我仍是看懂了他的框架，並順利使用到項目中，固然，繼承框架的一些東西，改掉很差的以適應項目或者我的習慣，這是必需要作的工做。並將須要使用的插件，目錄，擴展都給弄好！這樣之後，只要往既定的目錄下寫本身的代碼，修改便可，相對來講，結構仍是很清晰的！
　　　　把前幾天寫好的靜態頁面嵌入代碼中，這樣，整個項目就算有了真正的樣子了！
　　　　把最基本的驗證一類的工做作在這裏，能夠不實現具體功能，可是位置必定要預留！
　　　　使用到的東西有：內部PHP框架、bootstrap、Jquery、Jquery.form.js、My97Date、validform、layer、cron、Redis、微信接口、內部通訊接口...

　　6、寫什麼主要功能？
　　　　根據業務需求，首先把主要的功能給實現了，讓頁面動起來。其實，大部分的需求，都只須要經過增刪改查，就能夠完成效果，可是複雜的邏輯，仍是須要仔細屢屢的。
　　　　主要功能實現後，還須要其餘各類基礎數據輔助，把這些環節給作出來。
　　　　在這期間，遇到了一些有難度的問題，發現時間不夠用，領導也發現了，偶爾會來催一下項目進度，最後，讓那位大師兄加入其中，輔助完成任務。若是沒有他的加入，我想，這個項目真的要延後不少了（儘管他加入後，也有必定程度的延後，因此，領導畢竟是領導，他纔是掌舵人）。
　　　　前面寫的計劃，其實在這個時候是不太起做用的，由於以前不少功能點都沒有評估到，在這時候加進來，只有本身默默加班遇上，說多了，就是無能！

　　7、作什麼腳本輔助（消息處理）？
　　　　需求中，須要服務器中進行處理一些工做，完成後通知到數據庫及相關人員，因此，須要寫相應的腳本去作這些工做，主要爲配全redis進行隊列接收，另外一個定時腳本隔幾分鐘執行一次，按期處理消息隊列的東西。這個工做在我本地來講，相對是不容易操做的，由於須要模擬服務器處理的工做，完了以後再進行通知，再進行定時腳本執行，若是我是在linux環境下進行開發，那這也是ok的，然而我是在windows下開發...
　　　　把這一步作完之後，基本上大的東西就算作完了，這裏要注意的就是併發和鎖的問題，你能不能容許同時執行多個實例，得考慮清楚。

　　8、頁面優化，項目部署
　　　　把主要功能實現之後，能夠好好再去調一下頁面了，固然，幾乎全部的工做都是在以前作的，可是這個時候，最好仍是要有這麼個過程，算是檢查一下也是能夠的！鏈接到測試服務器，進行本身測試的階段，服務器也已經部署完成！

　　9、轉接測試，迅速更改
　　　　項目進度沒有及時到位，可是，我仍是將工做推動到下一步了，轉接給測試人員。固然，有幸我遇到一個好測試，他絕對算得上半個開發了，沒有他的監督，這個項目怎麼敢上線，一方面，測試在測試功能，另外一方面，咱們加班加點，把問題解決，這個時候的工做推動仍是挺不錯的，只是，本身的bug列表裏面，添加了許多的記錄，多得你都不敢想！
　　　　但無論過程如何，最後的榮耀始終是有的，在上線的那一刻，全部的bug都不是問題了，哈哈哈。。。

　　10、產品介入測試
　　　　測試經過以後，產品纔算是正式介入到檢驗中來，雖然我的以爲這怎麼也有一種，事不關已高高掛起的感受，可是事情也就這樣吧。再一次有人介入，項目又再一次進入快速更改狀態，可是都已經不那麼多事了，改起來也很是快。進度快速推動！

　　11、線上刪檔測試
　　　　刪檔測試，這TM誰想出來的，所謂的線上測試，不過是對本身產品的不信任，咱們再一次在線幹起了測試的工做。可是，至少能夠能夠向上上面的領導交差了吧！

　　12、正式上線
　　　　終於，上面催得急了，趕忙上線，上線，上線。終於能夠回家睡大覺了，那一晚，真的睡得很爽。。。

　　十3、補設計文檔
　　　　忙着開發的事，一直沒時間寫文檔，作完以後，把這東西補上，不然，新來的人怎麼看？？

　　十4、監控措施
　　　　沒有監控措施的系統，是不信任的，出了問題你都不知道，這可不是一個有經驗的人乾的事，不過晚點補也是能夠的，畢竟這東西也有一個完善的過程！

　　十5、後續功能
　　　　本覺得把東西作到這裏，就算差很少了，可是，明顯後續工做還有不少，好比功能增長（幹），好比數據壓力變大（分表分庫集羣），好比與其餘系統的對接（接口），我拭目以待。。。

　　本項目其實算一個小項目，可是，從最開始的一無全部，到最後系統造成，幾乎全部地方都介入，這個我不知道算不算全棧的表現，至少也算是以前沒有的體驗吧。之前都是跟着大牛們作事情或者拿現有的系統進行更改，不少基礎的東西，都不用你來作，若是一直這樣，我想，經歷不能算是完整的！

　　隨着時間的推移，故事還在繼續，用時間經驗填寫的故事，纔夠真實，至少對於本身來講，是這樣的！