#极客观点 聚焦于技术方向、程序员职业发展、个人成长等主题，致力于发起有价值的讨论，输出有价值的观点。
在本栏目中，我们将为大家推荐在 #极客观点 版块被热烈讨论的话题，甄选出有趣的观点为你呈现。期待我们一起成长和进步呀 🥰🥰
今日关键词：#低代码 # Docker # 成长
话题发起人：程序员海军
每个人都有迷茫的阶段，你是怎么突破走出来的？
有趣的观点：
有计划，有目的的学习
确定自己当前所属的阶段
学习处于当前阶段的一些方法论，指导思想
理论结合实际给自己梳理文档
example
主要工作为开发阶段
尽可能了解当前项目对应技术栈
保持了解技术动态，
了解新技术出现原因，解决的核心问题
学习代码架构的各种方法论，学习一些优秀项目的设计
带来团队阶段
学习技术管理的协议方法论
提升技术判断能力
了解业界态势，技术形式
了解当前产品的商业逻辑
能对自己做的事情自上而下的思考，思考公司为什么需要你的团队
——社区用户：百五
有趣的观点：
遇到问题 - 解决问题的时候，问题越大，成长越快。
——社区用户：ShirleyYD
话题发起人：莉香
有趣的观点：
低代码的概念最近 3 年很火，很大大小厂都在发力。但它到底是好是坏，业界至今没有一致的结论。
这也正常，这就像“哪种编程语言最好？”这种问题一样，永远不可只有一个答案，因为脱离场景讨论技术，是不科学的。
低代码平台有个大众化的定义：无需编码（ 0 代码）或通过少量代码就可以快速生成应用程序的开发平台。
对于不懂代码（或只懂少许代码）的人，低代码的开发效率极高，因为他们可以用 2 个小时就可以做出一个表单、一个 OA 请假系统...
总的来讲，它的开发效率到底怎么样，是和使用场景强绑定的。如果低代码这种通用功能能够满足你，那么他的效率就是满级，但倘若你有更多的耿兴华开发，那么它可能就不适合了。
——社区用户：YourBatman
有趣的观点：
其实就对于开发来说其实很多指标都是无法直接量化的，因为都和实际业务需求相挂钩。
就我所接触的低代码平台/框架，确实对于简单的一些管理后台可以说是原本需要 3 人的开发小组，现在只需要2个开发就可以搞定。
数据大屏甚至是 1 个实习生搭配一个后端就可以完成，而且实习生越熟练开发效率也就越高。具体参考宜搭或者帆软。
而低代码的局限性就在这里，如果命中了他的业务场景那么就会很快捷便利的就可以使项目落地。
但只要有一部分超出了当初设计的业务场景那么就还是需要去人工维护业务代码。
从高定制性的复杂业务平台开发角度来说，有35%的场景通用、高重复的场景可以依靠低代码来完成，其余的功能还是和原来一样开发流程开发。能加快一定的开发进度，但十分有限。
原本计划 10 个月左右的开发计划，大概累计可以加快 2~3 个月的样子。
——社区用户：陟上晴明
话题发起人：taskctl
如题，有一篇相关论文提到了 docker 。我随便看了看感觉这东西缺点很多，尽管安装后使用可以省掉很多安装第三方库的时间，但是docker自己的运行存在很大问题，而且后期修改，各种端口映射、虚拟机和容器的定义，也实在难为我这种不是科班出身的人
想问一下各位对docker有什么理解，是我理解的不对吗？还是有些优点我没发现？
有趣的观点：
后期修改，各种端口映射、虚拟机和容器的定义？
后期修改：非常方便，改一下 Dockerfile，重新打一下镜像就好
各种端口映射：同理，非常方便（或者说是世界上最方便的），只要改一下 docker-compose 就好
虚拟机和容器的定义：Docker 和虚拟机没有任何关系。纠结定义也是毫无意义的
用 Docker 记住一件事情，镜像是可变的，容器是不可变的，永远不要想着修改已经存在的容器。
例如： 少加了一个端口映射，改改容器，加一个。这是错误的，容器是不可变的，要加端口，就重新跑一个容器
——社区用户：ponponon
有趣的观点：
使用场景很多。目前我正在用它计划满足单位内部各种编译环境冲突，看中了他的隔离性（很多软件的依赖互相冲突），如果用虚拟机又太笨重，用容器刚好。目前是就安全性（文件隔离,权限隔离,困扰我）
