開發人員的是根據技術性和商品反映價值，針對App開發設計而言，除開完成業務流程以外，最重要的莫過開發設計的速率、品質和可擴展性，速率決策你可否支撐點公司佔領app design hong kong市場，品質決策大家是否可以使坐穩部位不被快速踢走，可擴展性決策大家繼續前行時可否維持歡快的腳步。
速率、品質和可擴展性
對速率、品質和可擴展性的規定，實際上便是又快，又穩，又清楚的規定。
快
快實際上是最非常容易保證，也就是說最非常容易瞭解是否可以使保證的事兒，瞭解app開發的盆友都瞭解，假如能梳理領域模型，不會受到影響地資金投入開發設計，開發設計速率能夠迅速，一般一般經營規模的App，一到兩個星期就能進行。
穩
穩不象快，能夠簡易用時間開展及時的量化分析點評，我們要等很多bug出現以後，才知道穩不穩，但是一般趕工期速率一快起來，就非常容易出現很多bug。實際上ios app 開發疑難問題只不過是運行記憶體、多執行緒、回應等，要清除和處理這種難題非常容易，難的是如何保證 不出現這種難題。
清晰
清晰難以保證，快速可以根據時間量化分析，穩定可以根據錯誤的統計分析量化分析，但清晰難以量化分析，代碼檢查和擴展性都是主觀評價，而且非常落後，在很多投標情況下，通常需要完成擴展，更換他人接管代碼。
對於開發者來說，如何快速、穩定、清晰的開發設計App，下面是我的一些體會。
更有限地參與業務流程設計
從職責許可權來說，業務流程設計方案是業務單元和產品運營的工作，不能由產品研發來承擔，我說的是參與。產品研發(包括測試)應儘快參與業務流程設計方案，一方面及早發現問題，另一方面正確引導和提出關鍵技術。
產品研究開發參加設計方案，可以避免通信工作壓力、載入速度、時間延遲、硬體設定負荷等移動應用開發的獨特難題，希望經營和商品能夠像技術專業的產品開發一樣充分考慮周翔。
另外，產品R&D參與設計也能正確引導關鍵技術，比如選擇原始應用程式，混合應用程式或者ReactNative模式，選擇一般使用者管理系統，或者多客戶管理系統，以及選擇何種收費模式。
在運行過程中，業務流程設計如基於收費的方法，異常提醒，擔心密封域模型，很可能會發現系統漏洞。
當然，參加設計方案一定會佔有產品開發的時間，也有人覺得為商品工作，但實際上產品開發參加設計方案，節省了自己的時間。無論商品如何設計方案，最後都必須技術完成產品開發。如果設計方案有問題，更改編碼的資金投入，比商品更改文字檔的資金投入多。
自然，公司也需要有清晰精准的定位。產品R&D在設計方案上的資金投入必須是有限的和規範的。如果很多人把R&D投入到設計方案工作中，它就會以另一種方式被消耗掉。
錯誤處理
在具體的開發設計全過程中，除了錯誤，實際上占了非常多的勞動量，有時也有好的計畫方案，很多奇怪的錯誤必須遲到半天，所以說更文5分鐘，錯誤2小時。所以儘快解決異常對開發設計的高效率是非常有害的。
解決異常是我的一些經驗：
提前考慮錯誤處理。在編寫所有正常步驟的業務流程代碼之前，考慮異常情況的發生，“先不要擔心贏，先擔心輸”，按照工作流分支，先解決所有異常情況，比如獲取一個線上資料資訊顯示資訊的目錄，先考慮網路連接逾時、網路服務器錯誤、資料資訊不成功等異常現象。，並陸續得到相關提醒，最終解決所有資料資訊正常的情況。本來需要寫所有正常的業務流程代碼和錯誤處理代碼，只需要在工作中替換順序即可。其實你投資的開發設計階段並沒有提高，但是你的效率有了很大的提高。一旦發現異常，我們可以快速識別異常的原因，節省大量時間。
這樣做還有一個好處。在你的邏輯思維陷入複雜的領域模型之前，解決相對簡單的異常分支系統，防止你在領域模型中得到腦缺氧後，回家解決異常分支系統時，一時疏忽，填寫錯誤或填寫錯誤。
保護前後左右連接的api介面，最好不要立即應用後臺管理提示的資料資訊，在中間投入，另一方面，如果後臺資料出現問題(資料資訊異常，欄位名稱變更等)，在投入資料資訊時可以發現正確定位，另一方面，選擇更適合App的資料資訊方式
另外，建議做一個專門的工具來記錄和檢查通訊端，但是在維護前後可以很容易的維護左右通訊端，最好能自動識別來自通訊端的回饋是否正常(網路服務器超載、功能變數名稱變更、協力廠商服務過期等)。
異常資訊內容和資料資訊內容的收集、收集、歸納和持久性
假如發現異常，最重要的是收集到出現異常編碼行(如MainActivity第61行)和出現異常緣故(如空指標異常)，並紀錄為本地檔以便提交和查詢。
高內聚的資料資訊層集中了與資料資訊讀寫能力、互聯網讀寫能力、本地讀寫能力、快取檔案等相關的解決方案。，包括模擬資料資訊，根據回呼函數或鏈啟動向業務流程層拋出資料資訊，根據多版本號系統轉換模擬資料資訊和真實資料資訊。
鬆散耦合的活動，頁面應該是與業務流程關係最小的，關鍵是要顯示一個介質資訊，打開生命週期解決方案，活動應該很容易被替換。
單獨且便捷檢測的業務流程層，業務流程層應當能夠完成功能測試，這十分關鍵，即便 你沒去執行功能測試，把編碼寫出能夠功能測試的，也可以幫你提升編碼，該抽象性的抽象性，該脫離的脫離。
必要時，抽象是一種獨特的控制，如果控制需要重複使用，則不需要控制和活動，而抽象是一種單獨的顯示資訊控制，可以去除蓮藕，方便重複使用。
不必過多設計方案
敏捷的開發有實踐活動標準。不需要太多的設計方案。開發設計的使用價值不取決於寫漂亮的代碼。完成商品並支持一切正常運行。在能夠完成產品功能的前提下，代碼邏輯性實際上越簡單越好。簡單通常代表高可靠性+低維護成本。如果將來必須擴大作用，則可以根據變更和重建。
自然，簡單並不意味著隨意。惡性事件很容易複雜化，但很難簡單化。邏輯清晰，執行緒安全，運行記憶體安全，非常容易變更和擴展，另外，代碼簡單，實際上可以更加磨練基礎。
事實上，不僅在發展防止過度設計的作用，在維護和擴展舊代碼中，還要注意所有正常運行的代碼、代碼、所有良好的代碼，我認為在維護舊代碼中，還可以用來維護封閉的標準，必須更改的舊代碼，不變，對外開放，可以更改；可以所有正常運行的代碼，即使你不覺得好看，癢，那是封閉的，不能更改的。
返回這句話，開發設計的使用價值不取決於寫一個漂亮的代碼，而取決於完成商品並支持一切正常運行。
共用庫的創建和維護
專案風險管理有時間、成本、範疇、品質四個要素，這四個要素一般不能兼顧。如果需要時間，就必須切斷幾個範圍的專案目標，降低成本，就容易放棄品質。但是，製作和維護通用庫是有益的。
時間
更少精英團隊成員理解新專案的成本，展示新開發設計的基礎知識，加快開發和設計反覆運算，快速發佈版本號
成本
平穩的公共性控制模組採用元件庫方法，向各業務流程線提供合作應用，降低反復開發設計和升級維護勞動量。
範疇
對已經完成的作用/業務流程、通用控制模組抽象化，有近似的要求，可以迅速完成，更容易完成新專案的業務流程要求。
品質
常用的功能/業務流程控制模組採用元件複用方式，更有利於暴露不足，一改多得，提高產品品質。
專用工具與模版等
事實上，談到提高工作效率，前面的許多工作經驗必須在具體的開發設計中逐漸感受到，不能很快開始，相反是專用工具範本，實際效果好，一次安裝，終身利益。
就我的工作經驗而言，一件高度開發和設計的事情，包括編碼範本、通用設備和設計軟體的開發，以及其著名的程式pima朋友聊天網站github。
代碼注釋
一般來說，程序員對他一個月前寫的代碼完全不熟悉，我也是，大部分一個月都沒列印出來，但是想改/擴充怎麼辦？此刻，我不得不看代碼注釋。關於本人的工作經驗，有很多地區，必須寫注釋：
插座
特別是MVP的Contract插座，在這裡基本定義了你的重要業務流程的個人行為，誰來輸入資料資訊，誰來顯示資訊資料資訊，誰打開的下一個實際操作，寫下這個內容，然後讀代碼，看插座
服務專案、廣播節目
因為服務專案和廣播節目沒有頁面，所以非常容易分散在領域模型的傳動鏈之外，如果領域模型沒有前後文的話，一定會有詳細的注釋，表示業務場景。
如果重置、介紹
自主決定一些擴展角色或控制，實施一些重置涵洞，或者介紹一個特殊角色，必須寫注釋，提醒調用者進行必要的實際操作。
TODO，所有工作優先，部分工作暫時延期，自身記錄無效。精英團隊最終使用代碼進行開發設計，所以需要寫TODO來提醒開發者這是一個未完成的情況，以防止不必要的誤解和延遲。
