1、需求研究透徹，想清楚，再動手寫**
2、看了需求要溝通！要溝通！要溝通！
3、文件要寫！要寫！要寫！
4、寫注釋！寫注釋！寫注釋！
5、需求變化很平常！很平常！很平常！
6、業務高於技術！
7、感覺有bug的地方，想清楚
8、測試自己先做幾遍！
9、自己解決問題。解決不了的帶著自己的看法去問大佬
10、用新技術要謹慎！
資料庫的設計：
命名：
以後寫資料庫，要把每個功能點抽出來（tmp_***_yyy），綜合性的資料展示（根據需求來），從這些小表裡查取結果表
表必備三欄位：id, create_time, update_time。 這是個規範。主要還是取決於業務。
以上就是軟體開發過程的五個階段，但是有的時候在軟體開發過程中並不是必須按照這個過程進行的。每個階段都至關重要！
總的來說就是 開發->測試->上線->維護
關於測試補充：
系統內部整合測試(system integration testing) sit基於需求把頁面寫出來，個人覺的，如果需求設計到位，介面自然就出來了，只不過是樣式的選擇和框架的選擇。效能也是考慮的一部分：如：過多的引入檔案和**量的控制，後期修改問題？需求變了怎麼辦？都要有應急方案。使用者驗收測試(user acceptance testing) uat
sit(system integration testing)系統整合測試，也叫做整合測試，是軟體測試的乙個術語，在其中單獨的軟體模組被合併和作為乙個組測試。它在單元測試以後和在系統測試之前。整合測試在已經被單元測試檢驗後進行作為它的輸入模式，組織它們在更大的集合，和遞送，作為它的輸出，整合系統為系統測試做準備。整合測試的目的是校驗功能、效能和可靠性要求，配置在主設計專案中。
uat(user acceptance testing)使用者驗收測試，通常是由最終軟體的使用者（通常這些使用者不了解軟體的具體邏輯，而對業務邏輯卻相當熟悉）進行的測試，因此是面向終端使用者的測試，結束之後通常就可以發布生產環境了。
區別與聯絡：
參加專案以來大大小小的會議參加了不少，都是確定專案的整體計畫，需求的討論分析，工作的安排，問題的解決方式，解決辦法…
印象深刻的就是每日的站立會：
這樣做的好處：可以清楚的看到自己的開發進度，每天也都會有收穫，而且對於專案的整體把控也非常有幫助。
ERP系統開發隨筆系列六（論ERP的設計模式
最近設計模式在網上很是個焦點，什麼這個模式，那個模式的，有用論，沒用論，這些對於軟體開發設計很重要嗎？一點都不重要。大家為這些花了不少時間，其實我覺得不必太要在意你的功能採用了哪些設計模式，因為那些是概念性的東西，只有真正參與實質開發經驗的人才知實用最重要。我在開發erp過程中我確實用了不少設計模式...
硬體設計最佳實踐 微調嵌入式系統開發的4大要素
嵌入式硬體裝置在當今的互聯世界中被廣泛採用。但是，設計乙個能夠適應不斷變化的需求的安全硬體是挑戰所在。硬體設計團隊需要在整個設計和開發周期中遵循某些原則來應對這一挑戰。如果你環顧四周，你會發現你周圍有許多嵌入式硬體裝置。你和他們互動的次數比你理解的要多得多 它們無處不在，從您的咖啡機到可穿戴裝置，可...
某店鋪收銀系統開發過程中出現的幾點問題
1 我們在開發該收銀系統過程中出現了一點 虎頭蛇尾 的苗頭，尤其是我們組，完成時間脫延，沒被挑中，大家都有點士氣低落。做到後來針對自己負責的模組不能最大程度上保持高度負責的態度，甚至有些技術問題出現的時候，更是 不假思索 將這類問題推出去。可喜可悲，可喜的是，如此機遇好好利用便能長人一步 可悲的是，...