經過了查好友ios1.0版第一階段的開發（也是查好友產品的第二個milestone），開發流程中的許多問題已經躍然紙上。本文對部分關鍵點做了簡要總結。
產品設計階段，遞交給開發組的產出以產品原型和使用者用例、場景為核心。傳統的軟體工程實現中，在開發之前需要做好需求調研，並完成srs（software requirement specification），作為開發的指導。網際網路產品要求有更高的迭代開發速度，為了達到這個目標，擯棄不必要的設計、文件相當必要。這裡我們做出的最大讓步界限暫定為產品原型 和 使用者用例、場景。產品與開發的交接，要求開發者認真理解原型的功能和互動，這些步驟的完成需在寫**之前（準確的說是**結構設計之前）完成。
1.產品原型不以文件或圖形來限制形式，以讓開發者明確實現為目的。
2.使用者用例、場景是產品原型的功能互動的詳細解釋。這是傳統軟體工程開發過程中需求採集的重要步驟。用例在軟體開發的前期，可以集中、整合需求，規範設計。在測試階段，用例可以驅動系統測試行為。
簡單講，用例就是對全部用例場景的抽象，用例場景就是從用例中例項化出來的一組活動。這部分過程可以大家共同設計完成。
在嚴格規範的軟體開發流程中，crc卡片（類—職責—協作）可以用來更清晰的展現各個部分之間的職責關係，有助於在設計階段思考一些關鍵問題。不過這種方法的複雜性在我們的開發經驗限制下，並無法展示其優越性：對物件導向程式設計和設計模式的經驗不足，我們的**經常試探性的嘗試各種形式程式設計，這也意味著無法在設計期間構建良好風格的類設計，而crc正是匯出類設計的前置步驟。
**設計時，還可以借助許多的uml工具。比如繪製泳道圖、時序圖等。
現階段我們可以跳過這些規範化的設計階段，直接在現有的經驗的基礎上粗略設計模組，節省設計時間，用之後的重構來替代設計的劣勢。當然，這並不代表著永久的放棄這種規範化的操作，到了某個階段，如果有必要，我們也可以拾起這套方法。檔案，也有一直聽到一種聲音，「即使是大公司，也很少使用到軟體工程的那一套流程」。鑑於此，長期來說，我們需要進一步調研，吸取其他開發團隊的經驗，來持續改進開發流程。
**結構設計完成後的重要後續是專案排期。參照《查好友ios1.0總結ii：開發節奏的把握》，並結合人員配置，合理的分配模組，進行任務分派。
由於交流的倉促，在之前的開發過程中，我們遇到過很多不的不順利。這些不順都是計畫性和規範化的缺失的結果。
具體來說，協同開發的計畫性和規範化包括：
1.設計步驟確定後，方可進行專案排期以及任務分派；
2.分派任務時，需要結合原型和用例，給出規範的srs說明；
3.獲得任務分派後，在提交**到svn trunk之前，需要通過自己的單元測試，以確保功能實現完備。提交時，需要在log中記錄下自己的更新模組的描述，一
來作為開發日誌的反應，二來以備不時之需（新**汙染了原來的**，需要找到原來的回滾點等）。
[附一篇使用的svn使用指南，講到了很多基礎概念。來自
[另附一篇博文，其中介紹了svn中branch的使用。這在開發過程中會經常遇到，比如用來備份自己還未完成的**而不影響主版本庫的**。
總的來說，乙個半月遞交審核對於乙個剛組建的二人無經驗ios開發小組是很有挑戰的。倉促之中，測試環節做的有欠妥當，以致第一次提交後的三天又發現了相對嚴重的bug，不得不修正後重新提交。
在規範了開發的整體流程後，測試也獲得了乙個較好的開展空間：
首先是功能測試：
1.單元測試：模組**提交之前需經過程式設計師的
2.設計時的用例場景可以驅動測試：包括回歸測試和探索性測試。其中，回歸測試指對乙個新的版本，重新執行以往的測試用例，看看新版本和已知的版本相比是否有退化
(regression)，這些都可以依靠現有的用例來驅動實現（這也是之前我們所缺少的，即每次更新、debug後對整體進行回歸測試，而這個測試成本相對較大，也就對每次測試、修正的節奏提出了要求：不可太過頻繁的提交產品到測試，要慎重）。
3.正式發布之前，應進行alpha測試（軟體測試人員
在真實使用者環境中對軟體進行全面的測試）和beta測試（公測）。
其次是非功能測試，也叫服務質量測試（quality of service requirement），這些測試是建立在軟體已實現了基本功能。
1.壓力測試；2.負載測試；3.效能測試；4.相容性測試；5.安全性測試
----ps-----------------
除此之外，對於整個專案的規範化，這裡也拋磚引玉的陳列幾點：
2.專案管理：專案管理的必要性在我上課的那乙個學期裡著實沒有發現，到了實際應用中，卻暴露無遺。8個人的團隊也構成了專案管理的最小規模了。
也就不套條條框框了，一些專案管理的要素在小團隊裡不需要，但這類需求也得根據團隊的變化而即時變化。比如，績效考評、進度管理、風險控制等。
之前的很長時間裡，我用開發日誌的形式來記錄工作，後期由於時間太緊，就放棄了。開發日誌記錄的問題在於，如何統一管理。
查好友ios版1 0發布總結 0
從7月26日加入seeme團隊開始，到現在已經乙個半月了，都在緊鑼密鼓的開發ios版本，一直沒空寫篇部落格，記錄下開發的歷程和經驗。這些不足，就是我們的潛力和上公升空間。趁著這幾天研究生開學和遞交版本後的休整期，我想將這些經驗歷程記錄下來，更全面客官的審視開發的過程，以激勵自己的進度和團隊產品能力的...
查好友ios1 0總結II 開發節奏的把握
寫了第一篇總結之後，發現更細節的展開比自己的想想要麻煩多了.不過習慣的養成本就不是容易事兒。於是，還是開始寫下來吧.這是真實的故事，並非來自枯燥的軟工課本 查好友ios1.0版的開發開始的很匆忙。我和ll兩人一起接手開發。在此之前，我有兩個月的ios開發經驗，而ll則是剛開始學習。缺少對商業產品細節...
ios10前台收到推送 iOS10推送通知開發教程
開始在xcode中啟用推送通知是很容易的,但你需要幾個步驟。建立乙個新的工程，給它起乙個唯一的bundle identifier.當您已經建立了project,去project settings頁選擇capabilities欄。開啟推送通知,如下所示。注意 如果你是蘋果的付費開發者成員，你就能看到推...