Goal is not always meant to be reached, it often serves simplyas something to aim at.
Goal is not always meant to be reached, it often serves simplyas something to aim at.
脱离业务的架构就是耍流氓。架构师必须要深入理解需求、参与需求、看透需求背后的业务本质。
你作为前端负责人,来开发一个 h5 页,某个抽奖功能的运营活动,如上图。 假定 PM 和后端 RD 都是实习生,技术和业务都不熟练。你要从 0 开发这个页面,你会要求 server 端给你哪些接口和能力?
抽奖接口
。否则,他就不是一个合格的程序员了。用户信息接口
,否则都不知道奖品给谁,总得登录一下。或者直接输入手机号抽奖也行,但需求没说这里有手机号。抽奖接口
埋点统计
这个面试题不是考察知识点和技术能力的,完全就是在考察你对一个业务的理解能力。由此你就可以看出,程序员对于需求和业务理解能力有多么重要!直接会影响到你的 API 接口设计,进而影响到你的开发。有些时候,PM 和 RD 比较靠谱,他们能考虑清楚整个流程,你也就顺利的完成了,这很幸运。但大部分情况下,你都会遇到一些不靠谱的人,或者太忙没空理你的人。这个时候就要靠你去承担起来,而你有没有这种能力呢?
任何看似复杂的设计,都是让整个系统变的更简单
“很多程序员学了大量的算法和计算机基础,然而在工作中却派不上用场。这是非常正常的,因为这些内容是为了在科学领域做研究准备的。而在业务领域,大多是如何把现有业务在软件中模拟出来的问题,并没有太高深的数学问题。并且现在的计算机硬件,比如 CPU、内存、存储都很便宜,也不需要斤斤计较的去抠空间和时间复杂度。这些都导致所学不能致用。反而如何能够高效的把业务用软件表达出来,并能够随着业务的增长,让软件也快速长大,则变成了一个更重要的问题。这一点可能是当前计算机软件教育需要思考的问题。” —— 《聊聊架构》
但是千万不要扣细节,以及拿现在的代码实例和接下来前端开发的代码进行对比!!!否则你就是自讨苦吃。
模块设计
扩展性保证
研发提效
运维保障
评论没有加载,检查你的局域网
Cannot load comments. Check you network.