頁:
[1]
想要寫cross APP
如題,要寫這種類型的APP感覺上好像用python比較好,但是kivy看起來不是很成熟. QML又像是地獄
不知道有沒人有這方面的經驗?
<div></div> 用習慣的程式碼來寫就好，難不難寫了才知道適不適合{:41:} Cross Platform 這問題基本上不會有完美的解決方案，相關的套件也不會有完美的一天。所以不要期待有完美的選項出現，遇到一個看起來還不差、寫起來也不討厭的選項，就可以投入了。 不是要不要完美的問題,
而是開發的時候要先考慮"時效","瓶頸"還有之後"維護"的成本
我曾經遇過開發一套軟體花了3年的經驗, 因為時間太長, 當開發完之後已經不再具有產品優勢
之後, 當要開發產品的時候我會盡量先認清產品的目的跟意義
就現狀而言目前還在評估,
開發的時候會分成 GUI 和 program language 來進行評估
寫python 會覺得方便, 因為理論上大部分的環境是共通的
只有在跟底層像是filesystem溝通的時候才需要針對各自的平台去調整
所以寫起來很快,當然缺點是慢
GUI部份
QML我真的覺得很雷, google 完後再加上有一些開發經驗,
我覺得用這個來開發,完成之後要還要花更多的人力去維護
kivy我還有study, 所以先不做評論
javascript為基礎的mobile app 琳瑯滿目, 所以我也搞不清楚
所以想問看看大家有沒有什麼建議
...<div class='locked'><em>瀏覽完整內容，請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div> stephenwei_lu 發表於 2018-12-19 10:14 AM static/image/common/back.gif
不是要不要完美的問題,
而是開發的時候要先考慮"時效","瓶頸"還有之後"維護"的成本
我曾經遇過開發一套軟 ...
就像你說的，需要評估市場需求
你要先想一下你要做什麼系統的Android、IOS、Windows
以Android來說
我會安裝Android Studio，許多東西Google都幫你做好，且也有一堆完整的框架，了解後再去套用而已，其實蠻快的，不是說python不好，而是目前資源較多的就是Android Studio，既然久那麼多資源給我用，謂何我還要去學那些資源少的程式語言?
你要理解市場需求之外，程式的資源也很重要，寫app就我知道的可以用C++、C#甚至VB都能寫出App，但你要看網路上的資源多不多，Github的源碼能不能理解
雖然用一種語言去做3個平台的App很快，但該系統的特性你理解了嗎?都有專屬的開發工具可以使用，且學習起來也很快很方便，Android我研究大概一個月就寫出一個完整的App，有完整的會員機制、後台服務，Ios也是大約一個月，只是Ios除了花時間之外，還要有一點資金
至於為什麼不用一種語言來維護就好?原因很簡單，因為大家所研究的新事物都會先從這些開發工具下手，所以學習起來比較會，官方也會釋出程式範例，學起來也方便...<div class='locked'><em>瀏覽完整內容，請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div><br><br><br><br><br><div></div> stephenwei_lu 發表於 2018-12-19 10:14 AM static/image/common/back.gif
不是要不要完美的問題,
而是開發的時候要先考慮"時效","瓶頸"還有之後"維護"的成本
我曾經遇過開發一套軟 ...
這講法其實有點問題～。
我在上面講到「完美」這個詞，想要講的是「跨平台」這個問題本質上就是有許多難以克服的障礙，這會導致不同的工具會為了克服某些障礙而做出不同的選擇，也就是會極容易發生 A 工具在 X 方面糟透了、但 Y 方面卻很棒；B 工具可能在 X 方面很不錯，Y 卻有些糟糕。所以說想要在不同工具之間找到合適的選項，關鍵在於你想要哪個部份的優點、以及可以忍受哪部份的缺點？
另外在評估的時候，不要意圖牽扯太多概念進來。舉例來說，上頭提到的「我曾經遇過開發一套軟體花了3年的經驗, 因為時間太長, 當開發完之後已經不再具有產品優勢」，這段其實正確來說是專案管理的問題，不是開發框架的問題。（如果不認同的話，建議認真去了解一下敏捷式開發是怎麼運作的）
各種跨平台的解決方案中，最成熟的應該還是網頁式的方案吧。它有個很明確的缺點是無法跟系統深度整合，執行效率相較來說也沒那麼好，但如果這些問題在你的需求中都不是很重要的問題，那其實這估計會是最適合的選項。...<div class='locked'><em>瀏覽完整內容，請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div> 題外話
我沒開發過App, 確實不知道要多久
但是我遇過App 開發半年, maintain了3年還不穩定的
上述的3年是一個Application, 一個Application 開發1~2年在某些領域上是很稀疏平常的事
甚至開發完就直接棄用 本帖最後由 kwj 於 2018-12-20 11:53 PM 編輯
stephenwei_lu 發表於 2018-12-20 10:00 AM static/image/common/back.gif
題外話
我沒開發過App, 確實不知道要多久
但是我遇過App 開發半年, maintain了3年還不穩定的
APP 開發半年，但維護了三年還不穩定，說老實話～這很明顯是寫程式的人的問題。
stephenwei_lu 發表於 2018-12-20 10:00 AM static/image/common/back.gif
上述的3年是一個Application, 一個Application 開發1~2年在某些領域上是很稀疏平常的事
甚至開發完就直接棄用
對於一個應用程式開發一兩年是不是很稀鬆平常...其實這要看狀況和定義。
以傳統的瀑布式專案管理來說，對於稍大一點的系統，通常會定下一年或超過一年的目標，然後讓開發團隊開始按照計畫實行開發。通常在這種模式底下，系統會在接近 deadline 時呈現終於能夠把整個系統串接起來，然後開始做整合測試。所以對於驗收系統來說，大多會在專案的尾巴時才能真正地驗收。
不過對於敏捷式開發的管理模式來說，其實一樣終極目標會設定成跟瀑布式管理一樣，但中間會切割成很多個小目標，每個目標的基本準則都是可以 release。所以在正常運作的情況下，敏捷式開發的每個月都可以有新的 release，而不會像瀑布式那樣等到一年結束才能夠有 release。
舉例來說，假設整個系統有 A、B、C、D、E 五個主要組件要完成，專案為期一年。瀑布式開發大多會在前 9 個月都在開發各個組件，最後 3 個月開始整合以及做測試。所以 release 的時間點多半會是最後一個月。而敏捷式開發則會設定成例如最初兩個月完成 A、接著兩個月完成 B、接著兩個月完成 C、....，以此類推。所以在專案開始的兩個月就能夠 release 系統，只是這時系統只有 A 組件的功能，其他功能都還沒做。到四個月時，系統就會有 A、B 組件的功能，以此類推。
所以說，如果假設都不 delay，而且只以「包含 A、B、C、D、E 的完整系統」作為標的的話，瀑布式跟敏捷式的專案管理方法的結果是一樣的，最終都會在 12 個月結束時釋出完整的系統。但如果單純以「能夠 release 系統」作為標的，敏捷式的系統就會早在剛開始兩個月時就能夠 release 具備部份功能的系統了。
舉個更實際一點的相同例子～假設我要開發一個拍賣系統，為期一年。那麼第一個月設定的目標就是拍賣系統的基本功能，要能登入登出、上架商品、購買商品，然後系統就可以開張上線了。第二個月我可能就設定要支援 SSO 和 OAuth、第三個月可能設定要支援買家和賣家評分功能、.....，以此類推。雖然實際上我還是要過了一年才能把完整的系統開發完，但我在第一個月時系統就上線了，不用等到一年過完才上線。
實務上就我個人看過、參與過的大型 Web 系統的專案來說，其實大多會導致專案耗時的原因都是需求一直改變，並不是真的因為系統複雜到需要曠日費時地工作。而這個問題，在「正確地採取敏捷式開發」的狀況下是可以明顯改善的。不過還是要提一下，這裡強調的都是「正確採取敏捷式開發」，開發團隊的心態以及做事方法如果沒有轉換，那結果並不會改變。...<div class='locked'><em>瀏覽完整內容，請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div> 真正耗時的是廠商的需求，一直改一直改，合約相對就會延長，因為認證也需要時間，改東西就要多時間給工程人員做測試跟Debug，真正寫程式的時間其實不到兩個月，加上debug往往要拖到四、五個月，其他時間則是認證跟討論
拖到三年，算很誇張了，廠商也不會等到三年那麼久，一般都是一年約...
很好奇，到底是什麼專案可以拖那麼久
頁:
[1]