引語：相信很多人都自認為自己是個全棧工程師，不管有沒有驗證過，我也不例外。心中總有一種傲氣，事情都能做，只是做得好不好，時間夠不夠的問題！所以，對很多事情，我其實是一點不怕的，隨著時間的推移，人總是應該要進步的，去做一些沒做過的事，才對得起成長二字！
剛好上上個月，公司有乙個新的專案需求，需要做乙個全新的系統，但是看起來也不難，所以任務就交給了我。我可以說我是這個專案負責人嗎？應該是可以的！但是，最開始就已經存在了一些坑，等著我去跳，比如過需求的時候，我卻不在場！總體算下來，流程是這樣的：
一、過什麼專案需求？
需求肯定是要過的。
1. 要做什麼？
2. 哪些能做，大概要多久可以做好？
3. 哪些不能做，為什麼不能做，替代方案是什麼？
4. 功能的必要性，哪些功能是必須的，哪些是可選的，哪些是多餘的，以後的方向是什麼？
整理過需求後，大概就知道整個專案是什麼樣的了。
二、寫什麼計畫文件？
由於是公司內部使用的平台專案，說什麼不需要美觀之類的，全部的基礎就只有一些抽象的原型圖，其他的全部工作就交給開發人員（最開始就只有我本人，後來加入了一位多年開發經驗的大師兄），因此在我計畫裡寫了，靜態頁面模板編寫：3天。
因為只有我本人幹，所以，在寫專案計畫文件的時候，我只管按照我的個人意願，就把時間給評估上去了（這最後被證明是自己給自己挖了大坑），各種功能，我幾乎都以1天2天或0.5天來算，功能點也是寫得比較抽象。因為畢竟，計畫這東西，就是一拍腦門想出來的事。
最後，把計畫發給領導時，領導說，開發時間太長，能不能再短一點（我當時幾乎是崩潰的，因為我已經盡量把時間壓縮了）。其實我也理解，領導的意思是盡快完成。
基本上所有的計畫都會被一定程度上的延後，所以，領導讓你早一點的意思，其實基本上也是讓你按照這上面的時間來完成。
計畫就是你做事的證據，不可大意了！
三、劃分什麼模組？
這一塊嚴格來說，很多專案基本算不得是乙個流程的，至少我這個專案算不得，因為，其實就幾個字就描述清楚，扯那麼多幹嘛呢，哈哈哈。。。
四、設計什麼資料庫？
這個是非常重要的環節，如果把這一塊做好了，會給以後的工作減輕不少壓力，如果沒做好，後面將導致各種問題，尤其在不是你乙個在做事的時候，又會增加許多的溝通成本！
設計的基本原則就是，看需要些什麼資訊，有哪些資訊是公用的，會在**產生其他效果，詳細參照需求文件，適當考慮擴充套件性！
這個環節，一定要讓領導過一下的，他知道的比我多，考慮的點和我也不一樣，關鍵是，最後出事了，也算是心裡有個底，畢竟領導自己看過了！
然而，很奇葩的是，對於這個重要的環節，我幾乎只花了不到一天的時間就完成了！
五、搭建什麼框架？
由於公司不讓使用外面的框架，而且其他專案的**，目錄結構混亂，所以決定使用內部框架，進行構建系統。但是，內部框架還明顯不成熟，就連乙個像樣的幫助文件都沒有，唯一的乙個幫助文件是框架目錄中的乙個readme.md,使用了極為簡單的文字描述了功能。
不過，最終，我還是看懂了他的框架，並順利使用到專案中，當然，繼承框架的一些東西，改掉不好的以適應專案或者個人習慣，這是必須要做的工作。並將需要使用的外掛程式，目錄，擴充套件都給弄好！這樣以後，只要往既定的目錄下寫自己的**，修改即可，相對來說，結構還是很清晰的！
把前幾天寫好的靜態頁面嵌入**中，這樣，整個專案就算有了真正的樣子了！
把最基本的驗證一類的工作做在這裡，可以不實現具體功能，但是位置一定要預留！
使用到的東西有：內部php框架、bootstrap、jquery、jquery.form.js、my97
六、寫什麼主要功能？
根據業務需求，首先把主要的功能給實現了，讓頁面動起來。其實，大部分的需求，都只需要通過增刪改查，就可以完成效果，但是複雜的邏輯，還是需要仔細屢屢的。
主要功能實現後，還需要其他各種基礎資料輔助，把這些環節給做出來。
在這期間，遇到了一些有難度的問題，發現時間不夠用，領導也發現了，偶爾會來催一下專案進度，最後，讓那位大師兄加入其中，輔助完成任務。如果沒有他的加入，我想，這個專案真的要延後很多了（儘管他加入後，也有一定程度的延後，所以，領導畢竟是領導，他才是掌舵人）。
前面寫的計畫，其實在這個時候是不太起作用的，因為之前很多功能點都沒有評估到，在這時候加進來，只有自己默默加班趕上，說多了，就是無能！
七、做什麼指令碼輔助（訊息處理）？
需求中，需要伺服器中進行處理一些工作，完成後通知到資料庫及相關人員，所以，需要寫相應的指令碼去做這些工作，主要為配全redis進行佇列接收，另乙個定時指令碼隔幾分鐘執行一次，定期處理訊息佇列的東西。這個工作在我本地來說，相對是不容易操作的，因為需要模擬伺服器處理的工作，完了之後再進行通知，再進行定時指令碼執行，如果我是在linux環境下進行開發，那這也是ok的，然而我是在windows下開發...
把這一步做完以後，基本上大的東西就算做完了，這裡要注意的就是併發和鎖的問題，你能不能允許同時執行多個例項，得考慮清楚。
八、頁面優化，專案部署
把主要功能實現以後，可以好好再去調一下頁面了，當然，幾乎所有的工作都是在之前做的，但是這個時候，最好還是要有這麼個過程，算是檢查一下也是可以的！連線到測試伺服器，進行自己測試的階段，伺服器也已經部署完成！
九、轉接測試，迅速更改
專案進度沒有及時到位，但是，我還是將工作推進到下一步了，轉接給測試人員。當然，有幸我遇到乙個好測試，他絕對算得上半個開發了，沒有他的監督，這個專案怎麼敢上線，一方面，測試在測試功能，另一方面，我們加班加點，把問題解決，這個時候的工作推進還是挺不錯的，只是，自己的bug列表裡面，新增了許多的記錄，多得你都不敢想！
但不管過程如何，最後的榮耀始終是有的，在上線的那一刻，所有的bug都不是問題了，哈哈哈。。。
十、產品介入測試
測試通過之後，產品才算是正式介入到檢驗中來，雖然個人覺得這怎麼也有一種，事不關已高高掛起的感覺，但是事情也就這樣吧。再一次有人介入，專案又再一次進入快速更改狀態，但是都已經不那麼多事了，改起來也非常快。進度快速推進！
十
一、線上刪檔測試
十二、正式上線
終於，上面催得急了，趕緊上線，上線，上線。終於可以回家睡大覺了，那一晚，真的睡得很爽。。。
十
三、補設計文件
忙著開發的事，一直沒時間寫文件，做完之後，把這東西補上，否則，新來的人怎麼看？？
十
四、監控措施
沒有監控措施的系統，是不信任的，出了問題你都不知道，這可不是乙個有經驗的人幹的事，不過晚點補也是可以的，畢竟這東西也有乙個完善的過程！
十
五、後續功能
本以為把東西做到這裡，就算差不多了，但是，明顯後續工作還有很多，比如功能增加（幹），比如資料壓力變大（分表分庫集群），比如與其他系統的對接（介面），我拭目以待。。。
本專案其實算乙個小專案，但是，從最開始的一無所有，到最後系統形成，幾乎所有地方都介入，這個我不知道算不算全棧的表現，至少也算是之前沒有的體驗吧。以前都是跟著大牛們做事情或者拿現有的系統進行更改，很多基礎的東西，都不用你來做，如果一直這樣，我想，經歷不能算是完整的！
隨著時間的推移，故事還在繼續，用時間經驗填寫的故事，才夠真實，至少對於自己來說，是這樣的！
python全棧工程師完整版教程
教程目錄 day01 python 全棧開發 基礎篇 05 python 全棧開發 基礎篇 day01 電腦簡史02 06 python 全棧開發 基礎篇 day01 計算機結構01 01 python 全棧開發 基礎篇 day01 開課介紹 03 python 全棧開發 基礎篇 day01 開課介...
《全棧增長工程師指南》筆記1
當全棧工程師有兩個原因其他 1.後台在不知不覺中已經被服務化了，即只提供api介面和服務。1.全棧工程師來說，他們喜歡依賴於外部的思維，用於產生顛覆式思維 2.而專家則依賴於內部的條件，創造出不一樣的適應式創新專家們也在強調 一專多長 1.這個世界充滿了未解的迷，但是我只想解開我感興趣的部分 2.沒...
全棧工程師基礎知識與筆記
一，開發工具 記事本txt subkime dreamwear webstorm hbulider title 主題，題目，url 是 body 是 內容 body的內容考 實現的。html 語言超文字標記語言 結構 標籤 段落內容 ctrl s 儲存ctrl c 複製ctrl v 是貼上ctrl ...