寫了第一篇總結之後，發現更細節的展開比自己的想想要麻煩多了....
不過習慣的養成本就不是容易事兒。於是，還是開始寫下來吧....
這是真實的故事，並非來自枯燥的軟工課本：
查好友ios1.0版的開發開始的很匆忙。
我和ll兩人一起接手開發。在此之前，我有兩個月的ios開發經驗，而ll則是剛開始學習。
缺少對商業產品細節的把握，最初我樂觀的**開發周期為兩三周。
8月26日，粗略了解了產品形態後，就一頭紮進了**的編寫中，忽略了詳盡的需求採集和設計。
和ll不停地摸索前進
，遇到不了解的功能或互動再詢問主管產品的yy，遇到不了解的介面再詢問負責後台開發的lp。
----------------------------------------------
回顧乙個半月的開發歷程，我和ll所燃燒的激情足以稱道，但計畫性的缺失讓我們走了很多彎路，對開發節奏把握的不夠讓我們在後期陷入了疲勞的困戰。
根據個人的**經驗，我將適合自己現階段的開發過程抽象為乙個recerd模型：
requirements：根據原型和用例，明確產品功能，盡量理清**架構邏輯，區分開c和e模組。因為缺乏對架構的認知和經驗，在這一步上，或許沒有辦法拿出足夠完備的架構設計，好在不斷重構的方法能很大程度彌補這一步的過失。
comfort：這部分的**實現邏輯相對常規和簡單，甚至有已有的**做支撐。這是**產量最大的時期。
explore：實現所使用的技術沒有使用過，需要先做測試，再應用到開發中，需要花較長的時間週期，並有更多的debug隱患。最需要慎重的時期，較大的學習成本。
當然，e和c並不可能完全區分開來，比如加入一段曾經沒寫過的業務邏輯，可以將它理解尚未實現過的e，也可以是無新技術元素支援的c。當然，不論怎樣，這樣的區分原則，是為了協調好整個開發周期中的精力分配，保證良好的開發勢頭。實際的執行中，e和c應該細分為更多小塊，在不打破區域性性原則的情況下，讓e和c交叉執行，並保證總體上e處於c的優先順序之前，避免開發過程中todolist過於乾癟或太過飽和，那樣會直接影響到開發組的心理狀態和程式設計效率。
refactor：增加新功能時，發現原有**擴充套件性不夠，時間允許的情況下，可以理解執行重構，一方面增加軟體的擴充套件性，另一方面增強對**的理解把握。需要將這一步提到與其他開發步驟平齊的位置，是為了彌補之前設計時的不足。
debug：最後階段的測試debug是為了過濾設計時沒有考慮到的特殊情況。程式設計師需要為自己的**負責，在測試debug之前需要確認已實現了需求的功能點（自己對**的單元測試等不屬於測試debug的範疇）。測試debug需要分配充足的時間，否則極容易出錯。
查好友ios1 0版發布總結V 開發流程規範化
經過了查好友ios1.0版第一階段的開發 也是查好友產品的第二個milestone 開發流程中的許多問題已經躍然紙上。本文對部分關鍵點做了簡要總結。產品設計階段，遞交給開發組的產出以產品原型和使用者用例 場景為核心。傳統的軟體工程實現中，在開發之前需要做好需求調研，並完成srs software r...
ios10 問題總結
1 使用藍芽相關的，cbcentralmanagerstate廢棄，使用cbmanagerstate替代。cbcentralmanager直接繼承與cbmanager，裡面直接宣告的屬性 property nonatomic,assign,readonly cbmanagerstate state ...
查好友ios版1 0發布總結 0
從7月26日加入seeme團隊開始，到現在已經乙個半月了，都在緊鑼密鼓的開發ios版本，一直沒空寫篇部落格，記錄下開發的歷程和經驗。這些不足，就是我們的潛力和上公升空間。趁著這幾天研究生開學和遞交版本後的休整期，我想將這些經驗歷程記錄下來，更全面客官的審視開發的過程，以激勵自己的進度和團隊產品能力的...