一个现代化的前端小组应该具备什么？

• 資深大佬 : orzzyd

  分享就算了。
  这边需求 deadline 在催着，那边领导突然大群 at 你说你下周分享。
  说实在的，别提让我做分享，我连去听都不想去。
  大家都是成年人，想学啥不会自己学嘛。
  如果是为了领导 OKR 能加一条那当我没说。

• 資深大佬 : rabbbit

  明确的福利待遇,按劳分配,多劳多得
  明确的锅盔管理机制,不相互扣锅

• 資深大佬 : laminux29

  屏幕墙 + 虚拟机阵列。

  原因是主流 OS 有很多，每款主流 OS 上面又有几种主流浏览器，每款主流浏览器又有很多主流版本。

  在不使用专门测试的快速开发情况下，每次改动，这些网页的渲染后结果是否一致，就需要屏幕墙 + 虚拟机阵列了。

• 資深大佬 : peterjose

  大厂可以搞搞 小破司谁管这些

• 主 資深大佬 : wxsm

  @peterjose 就是想学习大厂的经验

• 主 資深大佬 : wxsm

  @orzzyd 不能一概而论

• 資深大佬 : murmur

  @wxsm 大厂你学不来啊，大厂很多是为了职位难度故意提高技术门槛的，除非是做 web app，比如说是墨刀这种

• 資深大佬 : murmur

  @laminux29 现在大家都叫嚣不兼容 ie，前几年还象征性的兼容下 ie8-ie11，现在直接要全线放弃 ie，连老版本 chrome 都放弃，移动端 wap 直接不做导流 app，兼容性测试有何用

• 資深大佬 : murmur

  如果你入职闲鱼的前端，你大概学到的就是，移动端 wap 没有，pc 端直接阉割，app 改 flutter 被用户骂，闲鱼的转场连 loading 都没有，点半天没反应，突然哗哗哗所有路由全加载出来了，恶心的 1b

  这样的东西宁可不学

• 資深大佬 : laminux29

  @murmur 如果只是技术从业者，仅考虑技术问题，我也同意你的看法。

  但当你拥有自己的公司后，做决策、考虑问题、做竞争对手与竞品分析、甚至参加竞标时，你就会发现，考虑问题，不能只是简单地仅仅考虑技术这一个方面的因素了。举个例子，你完全不知道，很多 2b 甲方，仅仅会因为你的产品，比别人多了一个鸡肋功能，从而选中你的方案。

• 資深大佬 : kop1989

  我觉得这需要根据人力情况来酌情选择。
  比如 2 、4 、7 这些，如果人力不到一定的阈值，基本上是弊大于利，甚至是有弊无利。
  1 、3 、5 、6 我觉得是不管团队大小都必要的。因为会直接影响到开发进度以及开发质量。

  但凡事无绝对，关键就要看人力情况来灵活分配。
  在我的经验里，如果一个项目组或者团队，没有 10 个以上的主力开发人员（ 965 ）基本上上文的 247 都不能有效开展（既要么是对付事走流程，要么是副作用大，耽搁 deadline ）。

  人数越多，编程工程化、工业化效果就越好。

• 資深大佬 : RickyC

  mvvm?

• 資深大佬 : thetbw

  @laminux29 同一浏览器不同 os 表现不一致，不就是浏览器 bug 了吗。

• 資深大佬 : jones2000

  996

• 資深大佬 : pythonee

  能做到就是很牛的团队呀

• 資深大佬 : charlie21

  不需要 Testing 吗？

• 資深大佬 : asvencoop

  内部统一，一致对外

• 主 資深大佬 : wxsm

  @charlie21 业务的 test 我觉得必要性不大，基础的可以

• 資深大佬 : murmur

  我觉得
  0.一个优秀的项目经理和需求设计

  赶工起来，临时改功能，三天两头改需求，你 2-7 直接 gg

• 主 資深大佬 : wxsm

  @murmur 这种一般美名曰“试错”

• 資深大佬 : zqx

  阿里系的 Web APP 一般都很垃圾，尽管他们的前端团队建设完全符合你的例子。

• 資深大佬 : Valid

  需要一个明确的产品，避免重构代码

• 資深大佬 : az1996

  一个对外的技术 blog

• 資深大佬 : gouflv

  活下去比什么技术都强

• 資深大佬 : hitaoguo

  @laminux29 这个我只敢想想

• 資深大佬 : rodrick

  好的产品经理，一般没有，或者开发认为没有

• 資深大佬 : KuroNekoFan

  @kop1989 而且由于鄙视链的存在，’10 个主力开发’指的是’10 个前端开发’

• 資深大佬 : TomVista

  经理顶到产品前面,产品顶到开发前面,开发负责加班 :dog