我們專案組做的專案是乙個老專案，大部分時間都在維護，少部分時間在做新需求。專案類庫是用2.0的，一直沒有更新。
這個需求的週期是乙個月， 需求初期都在討論邏輯和資料庫的設計， 沒有討論編碼風格和一起共同遵守，共同呼叫模組的問題，需求確認後，資料庫設計好後，大家都都著手工作了， 專案採用傳統三層開發，除了model, bll就是aspx，專案也比較大， 每次編譯一次我需要4分鐘左右。 專案管理源**採用vss2005管理，資料庫用sql2008， ide用vs2008， 專案中沿用的習慣： 資料庫字段統一小寫， 類名首字母也是小寫， 也沒有使用駝峰命名法，orm用的是公司自己的類庫，全自動化的，使用起來不是很好用，有一點比較好用， 就是可以封裝表單字段為實體類。
開始開發這個需求了，我在做自己的模組過程中，沿用專案專案的風格，類名，屬性，變數，跟專案保持一致。這一部分東西就完了，此時專案組一位老員工就問我，為什麼類名首字母不大寫，命名也不規範，我回答，跟專案保持一致。 而後我繼續開發，隨後寫了乙個列表的查詢，查詢時我從頁面封裝查詢條件，查詢到後台，在類庫里用拼接查詢條件，然後查詢檢視， 大概20行左右吧， 隨後老同事又問我， 你寫的這些行**想幹啥呢，底層都跑那去了，還select呢。 首先我表示程式開發過程中，由於經驗不足，確實有不足的地方，同事，領導，老員工提出來，那麼我們就一定想辦法去優化他，但是在這次共事過程中，從那位老員工的口氣中，讓我感覺到好像我是在給專案搞破壞，我想表示自己的想法，說了兩句，老同事表示別跟他說話了，趕緊改就完了，讓我感到無語， 既然有人負責這次的需求開發， 開發時又有規範要遵守，那麼為什麼不提前開會說明呢，偏等開發一半了才提出來， 提出來後又是這種口氣， 作為乙個coder，一些最起碼的職業道德和職業操守我們還是懂的吧，面對自己寫的**，我們每天都會不斷的思考，那些地方還能寫的再好，那些變數是多餘的，那些地方邏輯處理不是很好，又或者是自己寫的**別的同事能看懂不等等。 溝通有這麼困難嗎？ 就是個民工整天在工地上搬磚壘牆也得有點說話的權利吧,我們用的自己的orm，常見的curd使用起來也非常方便，當然有些地方還是需要手動寫sql，而且有的查詢必須配置model，在model裡利用屬性操作，有幾個類區別很小，我用了繼承，但是在配置orm時又出現了問題，無法使用，我又不得不把**在copy,paste一下， 隨後還有幾個刪除方法我手動寫的sql，原因很簡單，刪除時沒有使用主鍵刪除，故老同事檢視**說這刪除怎麼不用底層啊，我又表示，能用orm的地方我一定用，更何況手動寫個sql總不至於弄的見不得人吧。
我想說大家有緣在乙個專案組裡共事，目的都是為了把專案做到極致，實現共贏，這麼大的專案，做了幾年了也沒做完，出問題應該不是什麼大事吧，有問題直接提出來，咱們想辦法優化它，而不是拐彎抹角的說這個扯那個，大家都有自己的原則， 也有自己的底線。
規範化對於每個專案組都很重要，專案管理，敏捷開發更是重要，當然我們對於敏捷還有很長的路要走，在這次的開發中，我很用心， 既然對規範化對我們很重要，又老專案維護，那麼我覺的有必要在心需求開發前培訓編碼風格和一些遵循的地方，也或者為了省時間，拿出來自己寫的東西，讓大家看一看，學習下好的風格，好的習慣，同時大家也可以看看到底同事寫的**是不是優質產品呢， 我想這些事情，對於大家來說都是學習的過程吧。
經驗尚淺，還請大家指導。
程式設計的路還遠，繼續努力！
Openfeign開發過程中，對請求引數的要求
無參的情況 無參情況就是說我們的方法內不接收引數 get請求 aa a public voidaa post請求 value aa a method requestmethod.post public voidaa value aa a public voidaa 單個引數的情況 get請求方式接參...
遊戲開發過程中需求變化那些事
隨著軟體專案越來越龐大，為了提高開發效率和有效的質量管控，開發過程中的專案管理越來越重要，流程分工也在不斷細化。傳統的軟體開發過程分大致分為如下幾個步驟 需求提出 可行性分析 需求分析 概要設計 詳細設計 編碼測試 整合交付 產品的最終形態和功能都是第一步的需求所決定，蝴蝶效應 在開發過程中體現特別...
軟體專案開發過程中的需求分析心得
目錄參考 需求分析是軟體計畫階段的重要活動，也是軟體生存週期中的乙個重要環節。該階段是分析系統在功能上需要 實現什麼 而不是考慮如何去 實現 需求分析的目標是把使用者對待開發軟體提出的 要求 或 需要 進行分析與整理，確認後形成描述完整 清晰與規範的文件，確定軟體需要實現哪些功能，完成哪些工作。1 ...