市面上，公司里，团队里，大家对全线的概念都偏向于懂前端，懂后台，懂服务器，懂日志，懂构架技术面相对广泛的人称之为全栈
但也往往因为精力限制，在很多时候对于技术选型会造成一定限制，这是局限性，而造成这个局限性的原因恰恰是因为自身精力的不足，因为每个人的精力是有限的，很容易落的全而不精的尴尬局面，这是被广为流传的，而真的以全栈为目标的人，也恰恰会因为如此，而考虑技术的相关性和通用性……
在当前app为主体，各种流量为渠道的现在，想要同时掌握android ios web为前端的同时还要了解以前后台所要求的一切，似乎是太难了呢…这大概也是混合开发经久不衰的原因吧…随着现在react native的衰弱，android的api版本地狱，还有ios反复无常…让那个相关语言的从业人员都没啥精力向全栈进发…
在过去，全栈工程师只需要处理web，后台，设计，运维，html的简单易懂，让这一切变成了可能…时代有所不同了～当全栈们掌握那么多种语言，那么多环境不同的特性，那么多不同的track…却每一次只能从一个点到另外一个点…随着设备，构架，业务越来越复杂…这是时代进步的必然征兆…
不同利益关系，不断有组织出现，期望一个语言天下通，即能写后台也能写前端，在这个复杂的世界，如果限定局限性java算一种，swift算一种…
也无法摆脱一个点到达另外一个点的困境…在erp领域，odoo在不要求界面的前提下，构建自己的技术逻辑和结构，让遵循这一逻辑的人，可以快速的构建一个又一个表单…在flask，有flask-admin通过定义模块快速生成后台界面(有点业余了)～django甚至自带具备一个admin～而这一切，大家都将这种一体化前后端界面生成作为一个后台工具…
odoo的因为行业的特殊性，后台和前端是最为接近的框架，体系割裂的也较为严重…但作为一个后台也是最为灵活和省心…
在不考虑技术局限的情况下，依靠中间件，代码结构快速生成的工具…犹如c#一般，快速生成大部分结构…这时候极其需要一个全栈讲这一切完成最后一点差异化呢？节约大量的时间，讲所有的任务预先一次完成…从设计结构到产品成型，不断复用自身代码，确实是全栈的脱引而出的关键，但人最值钱总是时间呢……
人类的结构化代码真的极其容易被ai所代替，而结构化代码生成模版，也恰恰是必不可少的一部分呢……
