全栈工程师修炼指南
熊燚(四火)
Oracle首席软件工程师
立即订阅
2286 人已学习
课程目录
已更新 43 讲 / 共 40 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 从成长角度看,为什么你应该成为全栈工程师?
免费
学习路径 | 怎样成为一名优秀的全栈工程师?
导读 | 如何学习这个专栏?
第一章 网络协议和 Web 接口 (6讲)
01 | 网络互联的昨天、今天和明天:HTTP 协议的演化
02 | 为HTTP穿上盔甲:HTTPS
03 | 换个角度解决问题:服务端推送技术
04 | 工整与自由的风格之争:SOAP和REST
05 | 权衡的艺术:漫谈Web API的设计
06 | 特别放送:北美大厂如何招聘全栈工程师?
第二章 欢迎来到 MVC 的世界 (7讲)
07 | 解耦是永恒的主题:MVC框架的发展
08 | MVC架构解析:模型(Model)篇
09 | MVC架构解析:视图(View)篇
10 | MVC架构解析:控制器(Controller)篇
11 | 剑走偏锋:面向切面编程
12 | 唯有套路得人心:谈谈Java EE的那些模式
13 | 特别放送:选择比努力更重要
第三章 从后端到前端 (7讲)
14 | 别有洞天:从后端到前端
15 | 重剑无锋,大巧不工:JavaScript面向对象
16 | 百花齐放,百家争鸣:前端MVC框架
17 | 不一样的体验:交互设计和页面布局
18 | 千言万语不及一幅画:谈谈数据可视化
19 | 打开潘多拉盒子:JavaScript异步编程
20 | 特别放送:全栈团队的角色构成
第四章 数据持久化 (7讲)
21 | 赫赫有名的双刃剑:缓存(上)
22 | 赫赫有名的双刃剑:缓存(下)
23 | 知其然,知其所以然:数据的持久化和一致性
24 | 尺有所短,寸有所长:CAP和数据存储技术选择
25 | 设计数据持久层(上):理论分析
26 | 设计数据持久层(下):案例介绍
27 | 特别放送:聊一聊代码审查
第五章 寻找最佳实践 (6讲)
28 | Ops三部曲之一:配置管理
29 | Ops三部曲之二:集群部署
30 | Ops三部曲之三:测试和发布
31 | 防人之心不可无:网站安全问题窥视
32 | 和搜索引擎的对话:SEO的原理和基础
33 | 特别放送:聊一聊程序员学英语
第六章 专题 (7讲)
34 | 网站性能优化(上)
35 | 网站性能优化(下)
36 | 全栈开发中的算法(上)
37 | 全栈开发中的算法(下)
38 | 分页的那些事儿
39 | XML、JSON、YAML比较
40 | 全栈衍化:让全栈意味着更多
全栈工程师修炼指南
登录|注册

20 | 特别放送:全栈团队的角色构成

四火 2019-10-25
你好,我是四火。又到了一个章节的末尾,相对轻松的特别放送时间。
从技术的角度上看,和相对偏“硬”的常规内容不同,特别放送部分,我一般倾向于介绍一些较“软”的其他内容。第一章的 [特别放送] 我介绍了北美大厂工程师的面试流程,第二章的 [特别放送] 我们讨论了学习的方法。那第三章的特别放送,也就是你正在阅读的这一讲,我想结合我自己的经历,谈一谈全栈团队的角色构成。
这些团队的角色构成可以说各有春秋,但是和以往直接进行优劣比较的方式不同,今天我想换个形式,在这一讲的分享中,我将尽量保持中立和平和,而将有态度和有观点的思考留给你。
我们整个专栏都在讲基于 Web 的全栈工程师,相应的,这里我提到的角色构成是针对“全栈团队”的。但它并非指一群全栈工程师所组成的团队,而是说,一个团队具备较多方面、较多层次的技能,联合协作去解决某一个具体领域的问题。
就我的工作经历而言,我其实在不少团队中待过,团队有大有小,既有国内的公司,也有北美的公司。而其中的几个大的项目,呆过的几个大的团队都可以认为是全栈团队。

华为

在华为的时候,我曾经作为某大型门户网站产品的初创团队成员,在其基线团队中呆了几年。你可能听说过,像华为这样的公司做产品,具备的最大优势就是“全面”,一般的公司可能着重于从某一个用户痛点,聚焦于某一个较窄范围内的问题解决办法,而华为具备足够的人力和财力去打造一个全渠道的完整体系的解决方案。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《全栈工程师修炼指南》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(2)

  • koko_zhk
    一般大大小小的公司,团队都逃不出业务、产品、交互、ui、前端、后端、测试、运维这几个角色,也许会有一些公司一人身兼多职,比如交互和ui,测试和运维,前端和后端,但是总归是逃不出这个模式。工作了那么多家大大小小的公司,发现一个规律,凡是没有一个专职产品的公司,大概率是做不出好东西的,这都是血的教训,哈哈

    作者回复: 一般情况下这个我同意。不过少数时候也有例外,有的项目是纯工程的,像是设计一个框架,这样的“产品”设计基本就可以让工程师代劳

    2019-11-01
  • leslie
    不过现在的OPS有时其实是要自己写或者改造监控工具的:可能现在的OPS仅仅是以某项为主其它为辅。自己在目前的Team算是DBA&&OPS,不过相关的监控工具要自己写或者对开源产品做二次开发,网络自己常规的同样懂;只能说是以DB为主其它为辅而已。
    2019-10-25
收起评论
2
返回
顶部