若是重來，我會如何作在校項目

一直在反思當時在學校裏面作過的項目，想着若是重來，我會怎麼去作。有一些小的想法，按照我所理解的作項目的順序總結、梳理一下。主要分爲：明確目標；如何部署；如何開發；數據收集。因爲以前在學校，和如今作得項目都是在線項目，因此所說的想法都是基於在線項目。

明確目標

在校項目每每是根據研究方向，先作點東西，而後找買家。這種模式的問題在於，當前作出來的產品，和用戶最終指望的東西之間可能有一些距離。不少時候每每會爲了知足用戶但願，而修改產品。這樣作也沒有什麼，可是必定要記住本身的底線。這個產品是爲了解決什麼樣的問題，它的核心價值是什麼。這方面我沒有太多的經驗，就只寫這麼多。

如何部署

如何部署包括了：新版本的部署，版本回退，數據恢復，應急響應等等方案。當時咱們作得東西，因爲一些鏈接語句是hard code的，致使部署須要大量的人工干預，成本很高。可是反觀如今在單位，很大的產品，在azure和sql環境配置好的狀況下，能夠快速實現本地部署。並且如今每週能夠實現小改動的發佈，每個月發佈新的feature。這之間的差別是何等巨大。

若是週期性的迭代發佈，當人員增多的時候，可能互相併不瞭解彼此之間的改動，可能造成衝突。另外，當測試覆蓋率不夠高或者其餘因素致使新部署的版本有一些災難性的問題，須要把在線版本回退到之前版本，該如何去作。爲了不一些開發當中致使的數據問題，咱們也應該將開發數據庫和真實數據庫分離。

作在線服務，總會遇到這樣或者那樣的問題，如何快速響應？如何trouble shooting？怎麼快速的發佈hot fix。

若是我從新作在校項目，我會先集中精力把這些基本的問題解決掉。考慮到當時實驗室的狀況，我可能會用一臺性能好的機器作產品的服務器。而後用另一臺機器，當成內部服務器。每週定時把全部新的改動發佈到內部服務器，每兩週或者每月發佈一次到正式版本。而每一個人都是基於本身的機器上的local的系統和db進行開發。

如何開發

根據個人理解，敏捷開發和瀑布模型並無本質上的不可調和。理想的開發模式是，在更短的週期裏面完成設計、開發、測試、發佈的流程。由於週期更短，因此每一次迭代的成本更低，犯錯的代價更小。因此不用等到萬事俱備再去開發，能夠更大膽的嘗試。由於開發週期變得更短，因此測試和開發可能更加須要並行，甚至基於產品測試(TIP, test in production)。

對於校園項目而言，可能人手緊缺，尤爲是優秀的人手緊缺是永恆的痛。那麼能夠資源的分配就更加劇要。可讓相對熟練的人承擔更爲重要的工做，而剛接觸項目的人從事在產品上測試的工做。這並非說測試的角色不重要或者要求更低。而是說低水平的人工測試的門檻相對較低，能夠經過這個工做來更加熟練產品。同時，我認爲開發人員保證邏輯部分的代碼測試率是一件很必要的事情。UI部分的自動化測試，我的以爲對於校園項目來講，有點要求太高。

一些好的開發習慣也應該引入到項目開發中：code review和bug tracker。Code review能夠幫助新人更快的提升，同時使得你們知道彼此在作什麼。Bug tracker能夠幫助記錄問題解決的過程。這樣遇到相似的問題能夠借鑑。同時這個也對你們當前正在進行什麼工做能有一個更好的瞭解。

數據收集

收集數據對於項目來講是一件很是重要的事情。對我而言，數據分爲兩種：1. 用戶行爲相關；2. 產品相關。前者包括用戶點擊了什麼，動做序列是什麼模式。從中咱們能夠知道用戶到底怎麼使用咱們的產品。後者包括一些關於performance的信息、異常信息。這些信息能夠幫助咱們作trouble shooting，以及產品質量上的改進。因此，寫Log對項目來講，很是重要！收集到了數據，好好分析也很重要！