这个文章整体的内容比较新手向。
不过作为半年上架了 6 个小玩具的 iOS 开发者而言,还是有点想从快速开发小玩具这一点来做一点经验分享。
明确自己的功能范围是很重要的一件事情,什么该做什么不该做,不一定要写出来,但是脑子里要有个大概的样子,而且这个样子要比较清晰,做到哪里,不做到哪里,明确边界是很重要的。
或者可以理解为粗略的需求文档。但是需求文档的投资存在着那么一个甜蜜点:投入不高,收益很大。超过了甜蜜点之后,可能就是负面收益了。
我的所有 App 的组件虽然没有非常明确的组件化,但是不同 App 间的设置、日历、数据库、其他的常用方法,基本都是沿用我第一个日记 App 衍生出来的。
写代码的时候,要有良好的习惯,把不同功能的代码按照功能分块,这不是为了什么代码洁癖,而是为了让自己减少重复工作。所有的功能都为了将来可以快速移植到其他项目来写。
如果没有自己的 Code Base ,那就从现在开始投资,第一个项目为 Code Base 加的时间,后续的项目会得到收益的。
并且这是一个持续的过程,后续的项目要拨出一些时间维护加固自己的 Code Base ,尽量让 Code Base 有益于自己的项目,也让自己的项目有益于 Code Base 。有点像一种定投。
项目伊始就该支持多语言,现在的项目可以直接用 String Catalog ,首批支持的一般是英文/中简/中繁,将来万一要支持其他语言的时候,可以节省很多时间。
遇到不太想处理的问题的时候,可以丢给 ChatGPT ,遇到自己代码冗余可能存在高阶语法优化的时候,也可以丢给 ChatGPT ,甚至你想找人 Review 自己的代码,也可以丢给 ChatGPT 。最后理解清楚 ChatGPT 的方案之后,再把代码放进自己的项目。
ChatGPT 是这个场景下,你能找到价格+效果最好的产品。
做的过程中一定会发现一些功能很想添加的,这时候往往就会纠结:做吧,时间可能比预期会超出,不做吧,内心空落落的。
此时,一定要有开发纪律/开发原则,至于开发纪律/开发原则是什么,看个人。
有的人日期是死命令,不能加活,加活就必须另外一部分减活。
有的人要尽可能完整的呈现功能。超期一些时候完全可以。
关键是要有“纪律”/“原则”的这个意识。这个意识没办法帮你加快开发时间,但是可以避免你在矛盾犹豫中,不停的精神内耗,很多时候有内耗的时间,可能开发都开发完了。
写代码很多时候看个人状态的,有些时候状态不好,就是状态不好,强撑着写不如去睡大觉。睡觉醒过来,可能就好多了。
个人推荐现在( 2024 年 1 月)开发如果选择 UIKit 方案,可以从 iOS 15 开始。
然后同时支持 iPad/iPhone ,但是可以把 iPhone 横屏支持给移除了。这部分对很多应用没啥意义,徒增 bug 。
UICollectionView/UITableView ,多看看官方的 Modern Collection View ( https://developer.apple.com/documentation/uikit/views_and_controls/collection_views/implementing_modern_collection_views ),熟练掌握了可以节省很多工作量。
多用系统的 UIMenu 做菜单。其他的 UI 轮子也是同理,第一方有提供的时候,尽量选择 Apple 的方案。没有的话,看看能不能砍掉这部分。
StoreKit 直接用 2 。要更简单还能找一些三方服务商来简化流程。
我的 UI 其实是很弱的,虽然已经是我能拿出手最好的效果。但是整体而言,我的原则是这样的,能省就省,先做出一个用户在功能方面能使用的东西,再去讨论美观不美观。
App 的图标,如果找得到合适的 Emoji ,我就把 Noto Emoji 放到很大,然后找个顺眼的纯底色 + Emoji 右下角。
UI 上尽量用系统的组件,很多时候尽量做到,清清爽爽不花里胡哨,自己过度干预可能弄巧成拙,不干预也是省下一大波时间。
刚才基本是一些比较务实的点来展开讨论的,如果务虚一点抽象一点差不多可以这么总结
现在 App 君全家桶 抽奖活动正在进行中,还有最后 3 小时(到 2024 年 01 月 10 日 16:00 ): https://v2ex.com/t/1006860