众所周知,当下流行的编程语言有Java、PHP、C、C++、Python、Go等。其中,稳坐榜首的仍然是Java编程语言,且在以面向对象思想占主导的应用开发中,Java往往成为其代名词。Java语言的背景强大,开发者众多,一直发展都不错。从普遍的企业的角度来看,存在的问题是:后台被认为是技术核心,客户端却被认为技术含量不高,甚至小企业会让后台人员顺便开发简单的客户端,或者让后台的架构师管理客户端几个人。事实上,客户端技术和后台技术的侧重点完全不同,连编程语言都不同(Android使用Kotlin编程语言的逐渐普及)。另外,后台的人跟用户相对离得太远,而客户端是直接面向用户的,与产品人员沟通更直接。所以,我认为企业产品真的是为了给用户用,那么选客户端背景的人员去做架构更好一点。
(1)移动架构师公认的职位描述是什么?
事实上并没有非常准确的职位描述。不过我可以尝试给出了一个:
1.设计当前架构。包括新技术方案的制定或评审。
2.改进过去架构。根据业务的发展或者技术债务的原因,重构当前技术方案并且推进实施。
3.前瞻未来架构。技术方案调研和分析,随时准备好对新技术的使用。
4.推进技术方案实施。解决实施过程中具体的技术问题。
5.技术分享和培训。推进技术交流和新技术的使用。
6.人员的招聘。技术面试。
(2)移动架构师是否还要日常编码,如果需要,比例是多少?
虽然带有管理色彩,但仍然以技术为主。所以代码是必须要写的,架构师不写代码,就成管理了。写代码的比例应该至少是 40% 的工作时间以上。
(3)移动架构师的成长路线是什么样的?
可以先试着解决当前业务中的技术问题,然后再培养自己的技术前瞻性,为业务的未来储备技术。架构师立命的根本还是技术,所以在移动开发技术上研究的事情都要尝试去做。另外,技术人员通常不善于表达,而架构师的很多工作(例如技术分享,培训,面试,推进技术方案实施)都是需要沟通工作的。另外优秀的移动架构师能够对业界都有所影响。所以,作为一个移动架构师,锻炼自己的表达能力也是必要的一条成长路线。
(4)移动架构师是否需要学习前端、后端开发技术?
这等于问要不要扩展技术“广”度,而架构师标签之一就是“广”。不过是看个人的精力能够达到多大的广度和深度了。
(5)移动架构师是否需要设计整个 C/S 架构?
这点倒是夸张了,配合后台人员设计应该是可以的,总负责的话,挑战略大了一些。
(6)移动架构师如何进行团队沟通工作?
1、与CTO总监的合作。
首先从思想上要认识到两者是利益完全一致的。总监为架构师拓展上升空间,而架构师将总监的规划切实落地。保证足够的沟通,可以约定一个固定沟通机制,比如每2周一次,让双方在思想上保持同步和一致。架构师应该带着方案和CTO沟通,讲清楚A、B方案的优缺点。可以让CTO根据从上层去考虑做决定,就算架构师本职的决策,也最好先取得CTO的认可。如果出现意见分歧,最好的方式是先搁置,等条件成熟了,很可能意见会趋于一致。如果不能等,只要CTO的意见不是太离谱,还是按照CTO的意见执行比较好。如果有十足把握,认为自己的方案很好,那么也要得到CTO的许可和谅解,否则千万不要擅自去做,因为最后的锅不是你一个人能背的。
2、与其他部门的合作。
产品部门一般不懂技术,架构师的作用就是帮他解决这个问题,这个很好理解。在理解了产品需求后,进行技术可行性分析。在不改变整体方案目标的前提下,从技术的角度,提出改善意见,修改设计,目的是方便实现。与后台架构师搞好合作,从后台到前台,整条链路太长,一个人管不过来,需要两人好好合作,共同把好技术关。拉拢好测试部门,要当作开发的朋友看待,是自己人。如果关系够好,考虑让测试人员在“自测”阶段提前介入,帮助开发人员提供测试案例。运营部门的关系稍微远了一点,关键点是及早介入。防止临上线了,加入一堆的运营需求,就可能影响产品投放时间了。总之与其他部门以合作为主,挣取及早沟通,将风险消灭在反生之前。
3、与团队成员的合作。
移动开发团队人数不多,但是部门和开发语言多。有IOS,android,还有JS和Java网关。如果一个部门超过3个人,应该设置一个Team-Leader,进行授权实现间接管理。对于自己擅长的技术亲自去实现,和兄弟们一起战斗,深入到团队中。思考团队提升和储备,应让中层人员在一线作战,高层人员作指导,初层人员打酱油学习。对于自己不擅长的技术,可以采用“结对编程”的方法,让两个开发者在一台电脑上开发,一个编写另一个观察,程序基本是相同的,还是能够理解和参与讨论的。与几个Leader,要重点在于沟通,在大方向上保证思想一致,给他们空间适量授权,并协助他们做出成绩。重点注意团队的正能量以及活跃的气氛,人不是机器,和谐的氛围比冰冷的制度和惩罚要好得多。记录团队的功绩和成果,提高团队成员集体荣誉感,将奋斗目标引导到“自我价值”上来。
(7)移动架构师项目新需求处理的注意事项
1、开发流程。新的产品方案从市场运营提出需求开始,再到产品经理制定新的功能需求,最后开发手里进行研发。
2、全局视野。在产品与开发首次会议时,首先从整个项目的全局出发,掌握需求的目的和意义和其他需求之间的关系。
3、完善补漏。向产品提出的需求的不足之处,从用户和开发的角度进行补漏完善,从而保证项目正常的运行。
4、接口数据。与后台数据接口开发人员定制数据在那个接口里给比较合理。
架构与设计
研发工具
移动安全
专项技术
软技能
周边技术
移动测试
性能优化
编程语言
如果你看到了这里,觉得文章写得不错就给个赞呗!欢迎大家评论讨论!如果你觉得那里值得改进的,请给我留言。一定会认真查询,修正不足,定期免费分享技术干货。
感兴趣的小伙伴可以点一下关注哦。谢谢!