浅聊下对app开发成长有益的一些技能

站长

2024年03月28日 14:12 · 阅读数 2

序

做个app开发, 表面工作好像就是画画UI. 但实际上涉及到各种点也不少, 而且很多还蛮复杂的. 以一个Android开发为例, 是否专精Android就够了呢? 我个人感觉不是的, 多学点其它方面的东西对自己的职业生涯是有益的, 而且也能反补回Android的开发上来. 那计算机行业各种各样的知识, 哪些才能对app dev们有益, 或者说有更大益处的呢? 本文就是想抛砖引玉, 也希望能帮助到一些初级中级的开发们.

p.s. 其实也是公司招了新人, 我正在手把手教人呢, 于是有感而发写了本文.

强烈推荐的技能

1. git

在版本管理上, 我使用过最初的CVS(好慢), SVN(单分支), Git. 可能现在应该是Git为主流了吧, 已经好多年没见过SVN了, 更不用提最早的CVS了. 而git自己也并不是简单的git commit, git push这么简单啦. 下面就挑几个有用的方面, 希望对还不知道的同学有益处.

1.1 git stash

当你正在做一个feature, 结果来了个紧急bug, 只好丢弃手上的工作(feat分支), 转开另一个fix分支来解决bug. 这时feat分支上已经有的工作怎么办?

我以前不会git stash时, 用的办法就是clone三个我们的代码库. 这样一个库做一个分支. 基本上就够用了. 碰到上面的情况, 我不用切分支, 用Android Studio打开另一个仓库就行了.

当然, 要是你的Mac硬盘不这么够, 如只有256GB, 可能对于一些大仓库(如几个, 甚至十几个G),这种方法就不太适合了

这时你可以用git stash来存储你的工作. 等解决完了bug, 再切回feat分支, 用git stash pop来取出刚刚存储的工作.

git stash  //把本地的修改保存起来, 再把分支变成最初的状态 
git stash save -m "save message" //进阶版的保存, 加上自己的注解来标识这次的保存是个什么东东

git stash list //查看有多少个保存的快照
/* 结果类似这样的: 
stash {0} branch_name1 "save message1"
stash {1} branch_name2 "save message2"
stash {2} branch_name3 "save message3"
*/

git stash pop // 取出第一个快照, 即 stash {0},  并恢复到IDE里
git stash apply 2 // 取出index = 2的快照,  即stash {2}, 并恢复到IDE里

1.2 git amend与force push

若是想多次提交, 但只有一次提交记录, 那就可以用ammend的commit

若是git amend过一次, 并push到远端了. 这时再push就会出问题. 这时就需要: git push -f, 表示是force push

1.3 解决冲突

刚开始从事开发工作时, 我更习惯于在IDE中操作Git. 但当有了冲突, 并且自己解决了冲突后, 我却总是苦于在IDE中找不到一个"conflict resolved"的按钮.

其实这时你只要git add这个文件, 即把这个冲突文件重新加入到git里, 就算向git表示, 这个文件的冲突已经得到解决了. 后续你就可以提交与push了.

1.4. git hook

git hook就相当于git提交器. 一些常用的使用场景有:

每次push, 都要求先通过了所有单元测试, 才能提交. 这时写一个hook, 强制push前走单元测试就行了
或者是每次push, 要求走lint来检查代码
...

这个技术上不是问题. 不过我实践操作过, 发现这样让push变得慢多了, 开发人员Push个代码还要等好久, 有点难受.

所以我目前就没有加任何git hook到我们工程里. 要单元测试之类的就在远端CI/CD上做, 不在本地做, 就不影响开发的时间了.

1.5 git分支策略

我见过最多的两种策略就是:

1).

main代表上一次release的稳定代码.
这时要是想新开一个release, 就从main上开一个release分支. 以后的feature, bug ifx全从release分支上来
等release完了, 再把release分支合到main上

2).

main代表最新代码
等到一个release快完成时, 再新开一个release分支, main则进入到下一个release版本了.

这两种策略都行, 我个人更倾向于第二种方式. 因为我对于"长期独立于main分支之外的工作分支(或release分支, 或是epic分支, ...), 都有种不放心. 因为以后要是合起main分支, 可能就要去解决很多很多问题. 所以我更倾向方案2, 即只有短期游离在main分支之外的release分支 (是在快发版了时才创建的分支, 发版了就合并到main上来了).

p.s. 对于Android开发, 可能没什么太大感觉. 但对于iOS开发, 每个开发的新加或删除文件都会触动project.pbxproj文件的修改, 这样大家再合起来时就很容易有冲突. 当年我在开发RN时, 就吃过这方面不少的苦头

浅聊下对app开发成长有益的一些技能

总之, 就是要尽量让所有非main分支的分支, 生命短一些, 免得最后合并时一堆冲突.

2. 一门外语, 如英语

这个基本上所有开发都是初高中就学过英语了. 但对于英语的掌握可能有多有少. 我个人感觉还是有必要学习门外语的.

一个是外国好多书籍, 等引入版权, 再等翻译, 排版, 印刷, ... 可能要花一两年才能看到中文. 若是你英语可以, 你可以直接看国外的英文技术书籍, 不能等翻译了, 相当于你又可以看中文书, 又可以看英语书, 学习知识的渠道就变多了.

二是github上, 和别人交流, 如提交pull request, 可能就得用英语.

三是很多文档, 可能就是英文的. 比如最新的iOS, android, kotlin, swift等文档都还是英文的. 你为了了解, 也不得不学英文.

上面是书面英语. 要是你想在口语或听力上有所进展, 方便你以后出国工作或是和国外同事交流, 你可以分两步来: 1). 工作英语 : 多从技术书籍, 技术博客上上学习如何描述一种技术上的行为 2). 生活英语 : 你可以多听听六人行的音频之类, 很生活化, 又不是很难. 我以前学习英语时, 把六人行的音频当成音乐一样, 来回播了几十次, 对于外国人的生活化用语, 语气腔调, 个别俚语慢慢熟练了.

= = = = = = = = = = = = = = = =

当然, 你要是主要做对日软件外包, 像大连等地方就不少对日的软件开发, 可能就要学点日语.

或者你对Ruby感兴趣, 很多Ruby书籍以日语为多, 你也可以学点日语.

总之, 就是学门外语, 多一些吸收知识的渠道.

3. 后台技术

现在少有app不联网了, 这就造成了: 我们app开发, 其实学一点点后台知识, 也有益于我们的日常app开发工作.

后台技术的选择

看你的喜好啦,

若是你懂JS, 那可以用Node.js与Express
若是你懂Python, 那Django可能适合你
若你懂Kotlin, 那Ktor也行
若你喜欢Ruby, Rails也行,
.... ....

我个人做过React Native, 因此学过JavaScript与TypeScript, 所以我更喜欢用Node.js与Express. 而且Node.js的相关资料较多, 有问题时很方便查阅

好处1: 提前给出假数据

若需求出来了, 但后台的开发工作要几天后才能完成. 在这时, 你就可以用自己的后台技术, 提前搞出一个自己小型服务器, 让自己和app开发团队的其它同学来访问它, 先得到假数据, 从而能不delay移动端的开发工作.

一个小技巧就是, 你不用自己去写response返回什么样的json数据, 你完全可以放一个json文件放到后台工程里, 这样返回时就直接访问这个静态文件就行了. 以Node.js为例, 那就是:

const express = require("express");
const app = express();

app.use(express.static("../public"));
// 这会把public目录中的所有文件当成静态文件, 可以直接被mobile端访问到.

好处2: 验证一些技术点

比如后台tech lead和你说, 他们的新接口可能会返回个304给你, 让你看着etag来决定访问的结果. 这时你可能就不知道HttpClient, HttpUrlConnection, 或是OkHttp这些mobile端的网络工具会如何处理etag, 要你自己去存储上一次后台接口的数据吗? 要自己存储每次的etag吗? offline时也能得到数据吗?

为了验证你的这些疑问, 你可以自己写一个后台, 来看下OkHttp如何处理这些工作:

app.get("/data", (req, resp) => {
  app.set("etag", true);
  const requestVersion = req.headers["if-none-match"];
  const eTag = "W/20220307";
  resp.setHeader("ETag", eTag);
  
  if (eTag === requestVersion) {
    console.log(`/data 命中etag`);
    resp.statusCode = 304;
    resp.end();
  } else {
    console.log(`/data 无匹配, 返回新数据`);
    resp.json({ id: 34, name: "banana", price: 0.5 });
  }

});

好处3: 能够人为制造延时

若是你想测试一下skeleton的shimmer效果, 或是loading的动画是否正常, 但正常访问后台, 得到数据太快了, 看不到效果. 这时怎么办?

或是你想测试mobile端的请求timeout是否有效, 你就需要后台接口迟迟不给你响应.

正常的公司后台很难满足你的这种需求. 这时你就可以用自己的后台, 来模拟这种情况

app.get("/data", async function(req, resp) {
    const result = generateRandomWord(count);
    // 做到了延时的效果, 这样来模拟网络较慢的情形, 或是想看loading动画时
    await waitMs(3000);
    console.log(`response returns`)
    resp.json(result);  
});


const waitMs = (n) => new Promise((resolve) => setTimeout(resolve, n));

好处4: 能人为出现错误

同理, 除了自己的后台能很方便地给出延时, 你自己的后台也能很方便地给出error. 这样你就可以测试你代码中的关于出错时的edge case了.

总结

从上面几种场景来看, 学习一门后台技术, 真真很有必要. 特别是你越进阶, 跟后台的协作就越多, 这时你的一些提前研究, 自主的, 不依赖于后台的自己的服务器就能帮到你很多次.

3. 写脚本

脚本就是一些简单的自动化工具, 比如说每天几点上传build包到仓库里, 每次提交要求检查Lint, 自动把kotlin-android-extension的写法转成ViewBinding的写法(kotlin 1.8已经没有了KAE了), .....

这种工具能大大解放人力, 也就提高了开发的效率, 是很有必要的存在. 那使用什么来写脚本呢?

java写起来还蛮累的, 一个简单的hello world都要包到一个类里. 所以不在考虑范围之内. 其它的, 如Python, Ruby, Groovy都可以用来写脚本. 甚至我在github上还看过Jake Wharton以前就用kotlin写过脚本, 比如说这个diffuse.

这些语言的特点就是能直接用, 不用包到一个类里去. 所以使用起来很方便.

我个人极其喜欢ruby, 以及跟ruby很像的Groovy. 特别是Groovy, 天生兼容java, 同时处理起xml与json时又很方便. 所以我的大多数脚本都是用的Groovy.

总结: 这一小节就是讲要学一门易上手的新的编程语言, 主要就是用来写各种脚本.

总结

所谓'逆水行舟, 不进则退', 我们app开发也要不断地学习, 不断地成长.

而且你在做开发时要学的东西, 和你在做tech lead时要学的东西还不一样, 所以我觉得上面各个点还是很适合想进阶为tech lead的同学来学习的.

文尽于此, 欢迎批评与指教. 也希望本文对你的职业规则有这么一丁点作用, 谢谢.

浅聊下对app开发成长有益的一些技能

序

强烈推荐的技能

1. git

1.1 git stash

1.2 git amend与force push

1.3 解决冲突

1.4. git hook

1.5 git分支策略

2. 一门外语, 如英语

3. 后台技术

后台技术的选择

好处1: 提前给出假数据

好处2: 验证一些技术点

好处3: 能够人为制造延时

好处4: 能人为出现错误

总结

3. 写脚本

推荐的技能

4 数据库与SQL

5 CI, CD

6 跨平台的开发

6.1 为什么学一门跨平台开发有用呢?

6.2 是否native开发就会灭亡?

6.3 跨平台的选择

推荐程度不这么强的技能

7 另一移动平台的开发

7.1 好处1: 有利于跨平台开发

7.2 有利平团队协作

8 html, css, javascript

总结