红袖添香项目小结

红袖添香项目小结

前言

从5月28创建工程到8月10号内测,两个多月的封闭开发。已经太长时间没有写博客了。最近这几天空闲,回顾了两个月的工作,觉着有必要记录一下。一是年纪大了,记性不好,二是以后回头再看,也许观点已经不同了。

红袖添香是我到阅文以后的第二个新项目,第一个是元气阅读。两个都是阅文在网文市场垂直深耕的领域,元气阅读是二次元,红袖添香是女性阅读。女性用户一直是一块很大的市场,正如马云在双十一的庆功会上感谢千万女性一样,我们也期待着几个月后的庆功会能有机会感谢一下。


以下是近两月的开发感悟:

前端&客户端

在阅文之前,我一直在深圳的TCL互联网事业部做海外App,由于Tcl是手机厂商,所以开发平台局限于Android。而阅文除了大量的编辑和法务,其技术部是一个多平台的互联网公司,每一个阅读品牌都有Web、Android、iOS平台的应用。

在阅文最深的印象,也是最不好的印象,就是客户端的没落。无论是Android还是iOS,目前的开发效率和灵活程度都落后于前端。再加上前端大神张鑫旭在阅文非常受宠,而客户端没有与之匹敌的人,所以客户端完全不受重视。抛开公司内部斗争,开发效率的差别是一个非常值得思考探究的点。

人员配比

目前团队内Android开发4个,iOS开发3人,前端开发6人。前端比客户端人数比几乎1:1,当然这并未考虑开发人员的年限与工作能力,所以只是一个参考。

页面&逻辑

近两月的开发任务看,前端多负责页面的展示,而客户端负责复杂页面、以及给前端提供业务能力,例如语音播放。

混合开发

前端开发的页面可以同时在Android和iOS上使用,很大程度上减轻了工作量。但是同时也带来了一些问题。例如:
1、页面与交互统一
当一个ui组件既出现在前端页面又出现在客户端页面,需要保证展示相同,并且交互相同。比如一个下拉转圈的加载动画,在前端与客户端需要保证下拉的距离以及转动的转速相同等等。
2、前端与客户端页面的交互
前端与客户端的交互多是异步的,频繁交互的场景会非常复杂。

新人

6月份客户端Android和iOS都只有两个人,迫于项目的压力陆陆续续加人。Android端加了两个人,一个校招生,一个实习生。

氛围

在996的工作环境中,新人的到来对于团队的气氛有很大的缓解,多个人多张嘴,在吃饭散步的时候聊的也多了。

新人的培养

我工作的第一个项目也是996的环境,那时候我的感觉是想做事但是很难帮到同事,又没有人教,自己又学不到东西,能做的事情就是解简单的bug,刷简单的UI。与新人沟通了的情况几乎与我当时一模一样。

当然我的观点,这不完全是996的问题。996的工作环境虽然压力很大,每个人自顾不暇,但是TeamLeader完全可以营造一个新人的成长环境,给新人一些成长性的任务。而不是给其他组员打杂,分配简单无脑的任务。

如果新人与我当年的体验相同,只能可惜没有遇到一个会培养人的leader。

996

工作三年了,一直做的新项目。三年做了大大小小近10款App。每款App从0到1的过程都免不了加班和高强度的工作。

996与效率

加班与效率的关系从来不是正比。长时间的十点十二点下班,早上十点上班,明显感觉团队内解决问题的能力越来越弱,尤其是到了晚上,一晚上都解不了一个bug,或者写出了更多的bug。

关于996的情况下如何高效的工作也是一个不错的思考点。个人觉得关键的点在于如何解乏。例如开一些CodeReview、技术非技术的分享、聚餐等等。

996与薪资、晋升

在公司工作,倘若付出与收获不成正比,一定会失衡。
现在有很多公司明确表示自己公司加班很多,例如头条、拼多多、华为等,同时也许诺了高额的薪资。然而有些公司并没有这么好的福利,却也是同样的工作环境,自然而然有很多人划水。所以现在我经常劝朋友去高薪的996公司拼一拼,或者去工资一般又不忙的公司沉淀技术,而不要去工资一般又忙的要死的公司当狗。

除了薪资还有晋升制度,有些公司明文或者默认一年两年以后才能开始提晋升,这种制度也只能让人消极了吧,无可奈何。

996与责任

在上述困境下,如果越陷越深,无疑使工程Delay,对于自己的发展也是不利的。

这种情况下,如果没有一个心理的标杆,就找一些鸡汤喝喝吧。

敏捷开发

两个月的时间,一款功能完善的app从0到1已经非常敏捷。但是对于一家拥有众多同类型阅读产品的公司而言,有点太慢了。阅文公司旗下阅读App,大的有QQ阅读、起点读书,小的有海外WebNovel、言情小说吧、元气阅读等,在此基础上开发一款功能几乎相同的阅读App,2个月的时间还是太长了。

技术架构

为什么耗时这么久,是老板一直追问的事情。所有阅读App功能雷同,界面完全不同,所以至少要刷一遍界面,然后还有交互的改动,一些控件需要重写。当然这是假设App架构不需要改动的情况。实际呢,老的App使用Hybrid架构,而新的使用ReactNative架构,所以完全不能复用。

另外新项目开始都是忙于功能,基础架构搭的破破烂烂,倘若又开一个新项目,虽然部分代码可以复用,但是埋下了长远的坑。

公共组件

老板期望极短的时间内完成一个项目,很大一部分原因是成熟的大团队提供了所谓的公共组件。

我对于公共组件也是支持的态度。完全解耦、使用灵活、扩展性强的组件无疑会大大提升开发效率。

然而实际使用过程中,很明显遇到了几个问题。
1、扩展性差,很多UI组件都没有暴露修改属性的方法。
2、无人支持,所谓的公共组件其实是属于某个团队的,对于其他团队使用上的问题,没有人支持。
3、没有文档,组件的使用,期望是与Github的一些热门工程一样,有文档有Demo,然而公司内部的组件库什么都没有。唯一的Demo就是线上的工程。
4、不可维护,组件库一直在针对某团队的项目升级,完全没有考虑其他团队正在使用的情况,当其他团队想要升级时,整个工程都会崩溃。
5、组件质量差,组件中包含各种try-catch,每一个try都让人怀疑开发者是一种怎样的心态,是想晋升?还是邀功?

针对上述情况,已经踩坑的团队,已经在逐步放弃“公共”组件库,转而自己开发一套组件。这与“公共”背道而驰,却也是无奈之举。

设计

设计毫无疑问是整个App的颜面。但是我想说的是不专业的设计会使开发的难度大大提高。

就举一个例子。阅读App中用到了多种字体,其中一种字体有没有上边距,却有下边距,导致所有自适应的文字下边都有空白,所有居中的文案都向上偏移…mmp!

不多吐槽,到此为止。