聊技术聊什么
- 技术点
Android的技术点太多了, 10年是肯定没办法遍历所有的Android客户端技术的, 如果有人说别人技术不行, 那么他也有可能没做过别人做过的技术, 拿一个对他来说的新的技术点很容易就能触碰他无知区域. Android同胞要避免自以为是, 因为Android的技术栈的广度几乎是远远超过ios, web前端, web后端, windows开发, 等等 - 技术问题
每次在一个技术领域都不是懂得某些技术点就能实现需求的, 即便实现需求，也会遇到需求实现的效果不理想, 这在web前端眼中几乎是难以想象的, 因为他们在chrome里面体验不到在小型设备编程会遇到的卡顿问题, Android手机比iOS便宜这么多, 用1-2年卡很正常, 很多Android需求要尽可能的避免bitmap的滥用, 就是因为Android开发者眼中的安卓应用很容易卡, 所以需要小心处理
为什么同样是Android工程师, 有的Android工程师写出来的bug就少, 有的写出来的就多, 同样大家都是实现了需求, 但是"保证需求在各个情况下均能运行"就很困难了, 需要抽象各个情况, 写出很碎的代码, 然后再将很碎的代码抽象出简洁的代码. 话又说回来, 如果考虑1种情况需要2天, 考虑10种情况下能运行, 可能就是2个星期了, 这里面的时间消耗如果不是站在测试角度是很难让产品理解的, 这对于把产品理解为"UI产品"的产品经理来说, 他们几乎没有耐心梳理一个需求的10个功能点对应的100个测试case, 所以很普通的产品经理是远远无法理解正常水平的Android程序员
Android开发需要什么能力
- 基本的编程语言能力, 比如int类型集合类型要会
- UI编写能力, 传统的UI组件以及每隔几年层出不穷的新的UI组件和框架
- 理解需求的能力, 开发眼中的理解需求是包括对需求的程序方案的理解, 所以不会像产品那样采用"记忆"的方式去理解需求, 而是带有思考, 这种思考还会带有停顿, 因为可能在听需求的时候不会立即想到方案. 假如程序不去在理解需求的时候去想程序方案, 后续当这个需求需要多方面协调的时候, 需要产品经理或者项目经理去理解为什么会出现他们想不到的情况的时候, 产品和项目就会责备程序"你为什么不早说", 所以程序在理解需求的时候是要想很多事情的. 侧面也足以说明, 产品经理和项目经理在没有程序告知他们的情况下, 他们对产品的了解和理解都是非常差的. 甚至程序就算告诉他们, 他们可能也不会当回事, 因为想象力是有限的, 理解不了程序遇到的复杂情况.
- 对于需求的全面思考的能力, 产品眼中的需求只包括需求的正常情况, 实际上需求的异常情况可能远远超过正常情况, 比如做直播和连麦, 仅仅因为网络断开导致的异常就很多种, 当然所有人都很难做到全面到100%, 能全面到80%就已经超过很多很多人了
- 既然需要"全面思考", 假如考虑到了100个测试case, 那么每个测试case对应10行代码, 那就是1000行代码, 实际上如果程序真的写的这么碎, 维护成本几乎是难以想象的, 所以程序非常需要"抽象和重构"的能力, 抽象容易很容易理解, 但是除非是非常熟悉的领域, 比如2年都在干这一种类型的工作, 很难一次性就写出易懂的代码, 这就需要花2-3次去重构以前的代码, 比如这次做了Google内购, 如果后续没有重构, 直接做Google订阅, 就会发现为了快速迭代需求, 写了很多和内购一样的代码, 后续改bug也是改两套, 效率可想而知, 效率低不仅仅是加需求效率低, 如果出现一个bug, 改bug的时间取决于自己对这块逻辑忘的快慢, 2个月就足以忘记需求的80%, 后续改一个bug就得2个小时去回忆代码, 1个小时改和测试. 重构代码的能力几乎被所有人忽略, 传统意义上对程序员的要求是"实现需求"
