業務開發：永遠被業務驅使或者**，越來越忙，支援業務越來越疲於奔命。產品、業務上線快，bug也很多。
這可能是大多數業務開發的寫照吧，換了份工作之後，自己也是一直在寫業務相關的東西，想說說最近業務開發的經歷
經常做的是熟悉需求、梳理業務、新的，舊的系統功能點、討論、寫**。而寫業務**，基本上用到的都是公司封裝好的框架，使用起來簡化了很多開發步驟，並且根基本上是參照之前**的寫法。
熟悉需求，肯定要做新功能啊，但是新功能從最老大的**提出來，產品梳理好之後告訴我們，開發不在第一線，產品與開發各自分工，文件給了開發，要做功能，只有梳理需求，需求文件基本上在整個開發過程都用得到。
梳理業務，新員工都要熟悉公司的業務，時間比較久的公司業務複雜，所以需要梳理。
新、舊系統功能點，也在和梳理業務，需求有很密切的關係，舊系統的功能是超級多的，有需要的都要看。新功能要理
討論，需求宣講會，功能點討論，設計方案討論等， 完全取決於會議是否高效
寫**，比重不是很大，但一切都要落實到**上，寫**才能實現需求啊。
總的感覺，不是像網上傳的天天碼**，熬夜加班， 這裡基本不存在。反而覺得寫業務**太簡單...梳理流程重要而且複雜，麻煩。
寫業務**對技術要求不高，公司提供的基礎設施比較豐富。
既然是業務開發，那就是業務很複雜，覺得都在試著理解業務。業務**乙個舊的模組幾十萬行**，幾百個對外服務介面，呼叫其它模組也很多。而重構是我們要做的事，梳理幾十萬行**。
業務方面每個公司的業務都不同，而寫業務**技術不會有太多提高，所有的業務依賴的都是技術。
提公升技術能力，研究輪子，自己造輪子，或造產品
提公升對業務的理解能力，如下建議，優化業務架構
業務開發：除了滿足產品提出的各種需求外，需要給留20%-40%的時間（用加班也行），想著怎樣優化本身的業務架構：如怎樣提公升原來設計不合理的架構，優化之，提公升穩定性、效能（容量）。一些通用的架構，需要提交到架構組，討論方案。個人認為，能滿足未來至少3年以上需求的架構方案，才算合格。
針對自己的情況，我時間還算過得去，這些時間取決於自己怎麼利用，最終會產生不同的結果
晚上：20點多點以後基本上都是自己的時間
堅持做一件有意義的能讓自己成長的事吧
共勉，早日實現程式設計師的百萬年薪！
開發後的思考與分析
事情是這樣子的，我們打算迭代開發這個功能，新增5個功能點，頁面算是重做，新增兩個狀態。所以我打算重構這個功能，原因有二，其一因為之前版本 臃腫，不適合查詢問題，而且存在許多使用問題 其二因為修改的東西有點多，所以得重構，用之前的 無法完成和修改使用。由於關係到公司隱私問題，這裡不貼出相關設計原型，並...
提公升自己深入思考的能力
而且，這個使用者行為之前就是乙個列舉型別，所以我們可以構造乙個map,遍歷獲得資料，然後將資料set進統計資訊的物件。這時我忘記了，列舉的遍歷，所以又重複寫了很多 顯然又錯了，又開始更改我的 重複意味著可以精簡，一段 重複寫就意味著可以寫成乙個方法呼叫。根據師兄的原則是，乙個方法不可以超過30行，否...
業務和技術的本質思考
現在it技術，基本都是需要和業務打交道，但是你真正理解業務 技術的本質嗎？怎麼利用各自的優勢？業務，是指某種有目的的工作或工作專案 技術，是指人類對機器 硬體或人造器皿的運用，也包含更廣的架構，如系統 組織方法學和技巧 維基百科 業務具有強目的性，是為特定問題而生的 而技術具有弱目的性 普遍性和通用...