选择新部门还是核心老部门？
某大公司背景，都是开发业务，现在面临一个选择:一个是核心部门，开发的老系统有一定沉淀和较为成熟丰富但却不够前沿的技术栈，但是有不少不规范的代码和bug，有历史包袱不利于使用新技术，有不少开发的时间会花在理解老代码的业务和改造。另一个是新部门，技术栈是比较前沿但是不完善的，没有历史包袱和不规范的代码和bug,但是业务需求场景比较单一，没有复杂的组件的应用场景。上下游合作部门多，开发有不少时间可能会花在沟通上。
新部门与老部门的具体对比
优点
1.因为是个新项目，用到的技术比老部门新，用到了比较热门的一些东西，比老部门稍显陈旧的地方更有推技术动力。
2.因为是新项目，所以导致bug在项目相对较少，不用像老部门那样去给不规范有漏洞的老代码bug修修补补。
3.新团队的管理可能会扁平化一些，毕竟人少更容易获得关注。
4.都是写业务逻辑，新代码可以自己发挥，不用像老项目那样要总要理解老逻辑之后在老代码上修改，老代码的注释和文档不够健全。
缺点
1.自己没有已推广独立的流量入口,主要流量依附于老部门,因此用户使用频率和关注度肯定明显低于老部门的产品。
2.上线游合作部门过多(老部门本身就挺多,新部门估计更多)，跨部门合作往往低效和花费精力，资源肯定比老核心部门少。
3.对技术的要求不高,因为业务场景不复杂，他们技术选型的观点认为合适的才是最好的。
4.技术体系不够成熟,很多东西没用到就没建设，因为他们的业务场景小而多，导致技术体系略显单一。
对于个人的技术成长来说，两个部门应该选哪个？
#Java工程师##C++工程师##iOS工程师##安卓工程师##前端工程师#优点
1.因为是个新项目，用到的技术比老部门新，用到了比较热门的一些东西，比老部门稍显陈旧的地方更有推技术动力。
2.因为是新项目，所以导致bug在项目相对较少，不用像老部门那样去给不规范有漏洞的老代码bug修修补补。
3.新团队的管理可能会扁平化一些，毕竟人少更容易获得关注。
4.都是写业务逻辑，新代码可以自己发挥，不用像老项目那样要总要理解老逻辑之后在老代码上修改，老代码的注释和文档不够健全。
缺点
1.自己没有已推广独立的流量入口,主要流量依附于老部门,因此用户使用频率和关注度肯定明显低于老部门的产品。
2.上线游合作部门过多(老部门本身就挺多,新部门估计更多)，跨部门合作往往低效和花费精力，资源肯定比老核心部门少。
3.对技术的要求不高,因为业务场景不复杂，他们技术选型的观点认为合适的才是最好的。
4.技术体系不够成熟,很多东西没用到就没建设，因为他们的业务场景小而多，导致技术体系略显单一。
对于个人的技术成长来说，两个部门应该选哪个？
投递小红书等公司8个岗位 >