軟工大做業·傾物語（二）

文章來源：中國軟工亞洲指揮中心（Steins;Gate）
共同做者：紀神，爵爺，老闆，小男孩（按首字拼音排序）
責任編輯：爵爺

    本週末咱們組已經完成了《需求規格說明書》和《可行性分析報告》兩份書面材料，具體內容見提交的文檔。

    此次想聊一下咱們團隊對於以後開發工做的構想。

    就大的方面來講，咱們在前端儘可能使用現成的解決方案，並配合手寫「膠水」，後端使用LeanCloud解決方案。

    前端要展開有很是多的東西，由於Android的前端比HTML更加底層一點，要涉及的東西更多，考慮的面也更廣，加之運行在移動平臺，限制也頗多。
    可是在參考現有解決方案（好比這個）以及基於咱們以前的開發經驗上，前端是能夠跌跌撞撞地走的（固然是在不考慮外行的設計、咄咄逼人的PM、永不知足的客戶的狀況下）。
    至於爲何不使用FB的react-native或是MUI等來作跨平臺的界面，一是在性能上H5相對原生仍有不足，而且這一點在Android版本和手機性能差別極大的安卓市場上更爲明顯，二是一個移動端的應用不管幹什麼頂部都有一個小綠條咕咕咕地動在咱們看來很是難受（純我的觀點）。所以咱們考慮只在一些不重要的信息展現界面和時間上來不及的擴展功能上使用H5，其餘狀況仍然使用原生API開發。
    還有就是JetBrains（筆者免費IDE的提供商，由於有教育帳號）的親兒子Kotlin，筆者沒有深刻了解，可是簡單看了一下，第一感受就是好玩，尚未感覺到特別強大的地方（固然是瞭解很是不足），基於學習成本的考慮，咱們仍是使用了Java來做爲主開發語言。

    後端咱們使用現成且強大的解決方案LeanCloud。筆者屢次被問到過「用LeanCloud這麼簡單方便甚至能夠說是無腦的東西，還算是程序員嗎？」。這種想法筆者以前也有過，可是若是不接受更快更好更方便的東西（並非說LeanCloud就必定是這樣，LeanCloud的適用場景其實限制仍是蠻大的，這裏不展開。可是相對於咱們目前的開發需求，LeanCloud就是這樣的），咱們如今想用計算機還得在竹簡上鑽孔呢（笑）。另外筆者琢磨過算法，寫過彙編優化的編譯器（特別指明：最後什麼都沒作出來），也裸寫過socket以及RESTFUL，因此對於「不方便」的東西筆者多少仍是有發表意見的權利的。出於學習目的或者對於要求特別嚴格的解決方案，惟有從底層慢慢寫，可是就目前的場景來看使用LeanCloud是很是好的選擇。應該針對不一樣的開發需求使用不一樣的方案，這就是咱們使用LeanCloud的緣由。

    另外在開發上，咱們目前的想法是先下手開始寫代碼，而不是先作細緻的設計。由於目前團隊總體的項目開發經驗是不太夠的，沒有足夠經驗的支撐，一上來就作細緻的設計頗有可能會忽略了重要的東西而把精力放在了其實無足輕重的地方，並且作出的設計並不必定效果有多好（編者我的認爲能夠參考Java第一代UI庫的設計）。固然先寫代碼並非說「先寫了代碼再提取設計以完成任務」，而是先用粗糙的代碼把流程簡單走一遍，探探路上都有什麼坑，而後再回頭作設計，這樣內心會踏實不少，設計結果也會更加可靠。這也是咱們這個月的主要任務：作初版最小化原型。

    目前編者已經搭好了基於Viewpager的Swipe View以及4個Fragment做爲主界面，下週先分工把這四個主界面按照原型設計作出來。而後依次跟進其餘代碼任務。下面是應用效果以及項目規模統計（是的我知道很醜，請不要再吐槽→_→）。

---