低代码真的会威胁程序员吗

ChatGPT是一个非常强大的语言模型，但它并不是万能的，在生成代码的场景下还需要人工编程和检查，所以一定程度上ChatGPT的使用是需要依赖程序员的护航，才能确保完成应用。说替代程序员的，着实是过度解读了。

ChatGPT的爆火，让我想起，同样会提高程序员开发效率的低代码平台，它的出现也同样被人类污名化，职业威胁程序员。

通过低代码平台，只需要通过拖拽的方式，或者是编辑几行基础代码，就能快速的开发出各类应用系统。最关键的是低代码改变了传统开发对专业技能的要求，现在只要掌握一些基础的代码知识，甚至不需要任何基础，就可以进行应用系统的开发！作为国内主流的JNPF低代码平台服务商，JNPF低代码平台负责人认为：低代码的本质是解放开发者的双手，让他们从重复的代码工作中解放出来，低代码在这个过程中扮演的是“辅助者”角色，而并非“替代者”。因为永远有一些容易被忽略的边缘性技术问题，需要程序员去解决，这是低代码不能替代的。

而且低代码并不意味着完全就抛弃代码，相反在平台无法满足一些复杂的业务场景时，就需要代码的辅助，当然这个过程的代码量要可控，否则就违背了低代码开发的本质。

而像市场上一些无代码平台，确实做到了看不见任何代码，但是当平台需要去应对复杂业务逻辑系统的开发时，便会显得力不从心，JNPF保留了这种灵活的开发机制，当需要更深层次的处理业务逻辑时，如果平台开发不能完全匹配，就需要程序员通过代码开发实现相关能力与服务。

而这种二次开发的需求已经超过了应用创建者的能力范围，这就需要专业的程序员基于平台去开发。

所以，与其无深究低代码是否会让程序员失业，不如去想如何通过低代码技术的加持，让程序员变得更有含金量，让低代码成为程序员工作的润滑剂。

最后，普通人如何不被OpenAI 取代。

在某些方面强于普通人的，特别是对于重复性智力劳动，如重复性写套话、写代码、画图，那么怎么不被取代？还是需要多学习、多主动思考、多实践、看更多书，做更多有挑战的事情，在认知上避免被取代的关键是不断学习和提高自己的能力，并努力适应新的环境和挑战。

对于一些贬义的说法，个人认为作为一个程序员应该保持“诚意开张圣听，不要妄自菲薄”的态度。

程序员一直以来看哪个是别名最多的一个职业，我姑且不分褒贬的称之为你才吧！就像小学的时候一样，相互之间往往喜欢区别名叫昵称之类的，而又往往外号叫的最响小名最多的就是最受关注的哪一个，程序员在当今网络上的处境大抵如此。

码农这个词米偶遇仔细研究过来源。参考其他人的回答知中文中的码农大体相当于英文中的code monkey。程序员码农说法的由来大概来自于程序员圈内自嘲的说法。这里程序员对码农的更多理解可能更接近coder这个词，就是说我是一个写代码的。可能会有人以此来明志，表面自己很热爱写代码，或我很精通以此，再或者言外之意我只是一个写代码的，别来找我给你装系统修电脑什么的，我最烦这个了(ノ｀Д)ノ。

程序员这个行业知名度虽然高，但是正在了解程序员是做什么的人并不多，大多数人直观臆想出来的感受可能是一个座在电脑前，后背前倾，颈脖前伸，面容憔悴，形容枯槁，两眼无关紧盯着电脑，两只鸡爪子似的双手快速的在键盘上敲击，屏幕快速出现一行行一块块英文字符的形象。这其实只是程序员的表面，完全米有展现出大多数程序员的内在。程序员真正的工作是解决问题，代码只是解决问题的途径，或曰实现方案。

程序员究竟解决什么问题呢，又是从哪里来的问题呢？首先要提到产品经理，产品经理给成员一个需求，程序员要思考如何实现这个需求。比如产品说这个登录过程应该这样这样，用户是否有通过手机或者邮箱验证。程序员要做的就是想方案来实现这个需求。在比如产品说我们这个网站要同时支持多少人访问不会出现卡，或者页面刷不出的情况。程序员接到这个需要就要思考如何设计这样一个高性能，高并发的服务端，最终通过代码来实现设计。好，现在代码写完啦，产品发布上线了。什么购物网站啊，大家可以随意挑选自己喜欢的产品，什么交友网站啊，大家可以写好自己的介绍发布出去让别人看到。但是还米有完，可能这个网站还要加点新功能，或者程序员自己也想，这个代码有没有什么地方实现的不好，换一个方法会不会更优雅。然后又是思考解决<=实现方案<=线下测试。自己测试发现可以，这个方法很好，发布到线上，就是用户最终使用的形态。不断提出新需求，完善新的功能我们称之为迭代。改善现有设计我们称之为重构。这些都是非常有艺术感的事！

事物发展就会演变出各种变体，有一些公司会把问题和解决问题的方法都做好，然后再交给其他公司或者个人去做实现（写代码）。由于在这里解决问题的过程被剥离出来（最有技术和艺术感的部分）剩下的就是实现，就是敲代码。好比建一栋房子，房子的设计和施工方案都已经做好了，就剩下施工了，这时候只要找个施工队就可以了。在这些做设计的公司，他们是有能力来实现这些方案（敲代码）。但由于欧美日等国家人力成本高，将这些技术含量低敲代码的苦活儿剥离出来交给相对落后地区的人去实现可以帮助他们节省人力成本。以上这个现象就称之为软件外包。另一方面，在美国主导的全球生产分工下，美帝也希望将中印这样的发展中国家固定在低端制造，劳动秘籍型的行业。

既然程序员是解决问题的，那么是否所有电脑相关的问题程序员都能解决呢？纵向来看，计算机系统可以简单的分为三层，应用程序<= *** 作系统<=计算机硬件。计算机硬件的设计研发基本和程序员无关。硬件往上就是程序员的职责范围了。这是可以简分为应用软件程序员和系统软件程序员。系统程序员的责任是实现高效的硬件管理，应用程序员则是为用户提供高效的服务。下面说说在这两方面和国外的差距，手机端应用软件（有服务端的包括服务端）差别不大，大家从自己手机中软件就能感觉到。PC端有差距，比如人家有PS这样的处理软件，而我们则没有。在这方面人家发展了几十年我们年数不够，有差距还是可以理解的。但我辈当发奋努力，以追他人之先。另外应用程序web化应该是趋势，这方面我们还是有优势的，对于普通用户来说最直观的体验就是不用装很多软件了，只要有一个浏览器就行。在 *** 作系统层面，PC如Windows，服务器如Linux。Windows微软独家拥有的闭源系统，不说。Linux内核开发来讲国内正在迎头追赶，内核的邮件中中文拼音的人名越来越常见，越来越多的国人加入到Linux内核的开发中。

对于程序员来说，软件编程开发代码质量能够直接反应出一个程序员能力的高低，下面北大青鸟就一起来了解一下，在代码质量优化方面，我们需要关注哪些问题。

1吹毛求疵般地执行编码规范

严格执行代码编写规范，可以使一个项目乃至一个公司的代码具有完全统一的风格，就像同一个人编写的一样，而且命名良好的变量，函数，类和注释，也无疑可以提高代码的可读性具体落实到执行层面，可以参照Google的编码规范或者java官方的编码规范，网上可以找到，关键是要严格遵守，并且在codereview时，严格要求，没有按照规范的一定要指出并且要求修改

实际情况往往是虽然大家都知道优秀的代码规范是怎样的，但在具体写代码的过程中，却执行的差强人意，很多情况是认识上不够重视，觉得一个变量或者函数的命名成哪样关系不大，所以不够推敲，注释很多也都不写，codereview的时候大家也都事不关己心态，或者觉得没必要太抠细节，导致慢慢的整个codebase变得越来越差所以这里还是要强调一下，细节决定成败，提高团队对代码规范的认同及其严格的执行是关键

2编写高质量的单元测试

单元测试是容易执行，且对提高代码质量见效快的方法之一还。但还是有很多公司对单元测试重视不够，包括一些大的互联网公司，不写或者随便写写。

有些工程师觉得有测试团队就够了，再写单元测试就是浪费时间。其实测试团队的测试和单元测试是在不同层面上的，测试团队的测试一般是黑盒测试，系统层面的集成测试，对于复杂系统来说，组合爆炸，测试团队无法穷举所有的测试用例。单元测试是代码层面的测试，一般是针对类的测试。既然无法从系统的整体上保证100%符合我们的预期，那单元测试起码能保证我们代码在细粒度上运行符合预期。

有些工程师认为开发任务重没时间写。这个还是没有足够重视单元测试，觉得是可有可无的部分，才会有这样的想法。写好单元测试，节省很多解决线上bug的时间，开发时间反而更充足了。

还有很多工程师虽然在写单元测试，但只对正常流程做测试。代码中的bug多数是写代码时异常情况没有考虑全面导致的，正常流程一般不会出问题。单元测试的作用就在于测试各种异常情况下代码的运行是否符合预期，所以只对正常流程测试无法发挥单元测试真正的作用。

微软发布Visual Studio Code 132，工作区域、编辑器以及语言功能等都有更新，另外还增加了一些预览功能，让想要尝鲜的开发者使用并反馈。

从这个版本开始，开发者可以预览并且安装颜色主题，而且在安装完主题之后，可以随即应用颜色以及图标，而不需要重载。在快捷键编辑器中，开发者现在可以编辑When属性，微软还移除了键盘快捷键编辑器开启keybindingsjson的链接，将该功能改至编辑器标题右侧的{}按纽。

微软接受了开发者的反馈，在Linux上决定将windowtitleBarStyle预设设定从自定义改为本机端，即便如此，微软仍然建议开发者使用定制化标题栏，以获得更好的可读写性支持。

在编辑器方面，新版本改进了鼠标悬停以及问题面板。现在问题面板加入了具有快速修复以及问题 探索 功能的命令行，开发者鼠标移动至快速修复选项上，就能启动快速修复功能，而问题 探索 功能则会在编辑器中开启 探索 视图。开发者可以从问题面板的 探索 视图，浏览错误或是警告。

Visual Studio Code的快速修复是由Code Action API支持，微软提到，虽然针对同一个错误，可能存在许多快速修复的方法，但是通常只有一个最合理的解法。现在系统会将其中一个修复建议，标记成为最佳选项，以表示其为问题最合理的修复方式，当存在最佳修复选项时，提示灯泡会出现一个蓝色小标示，开发者可以使用自动修复命令，自动应用最佳修复。

expandLineSelection预设绑定快捷键更改了，从Ctrl+I改为Ctrl+L，在macOS则从Cmd+I改为Cmd+L。而多行选择也改变了，现在开发者可以按住Alt并在编辑器中拖拉，在正常选择和以行为单位的选择进行切换。

Visual Studio Code 132包含了TypeScript 333，其中修正了部分BUG，在功能改进上，Visual Studio Code现在支持动态加载，在安装大多数扩充套件时，包括TypeScript以及Markdown扩充套件不需要重新。另外，新版还针对ARIA属性改进HTML IntelliSense，由于Visual Studio Code可以从W3C以及MDN取得ARIA可用数据，因此Visual Studio Code现在会显示ARIA属性和DOM事件的描述。

这个版本Visual Studio Code新加入的预览功能，能够在纠错服务器程序时，自动打开URL。微软提到，由于在开发web应用程序的时候，需要在网页浏览器中打开特定的URL，才能在纠错器中触发服务器代码，而现在Visual Studio Code能以灵活的方式自动实施这个过程。

以上就是关于低代码真的会威胁程序员吗全部的内容，包括:低代码真的会威胁程序员吗、为什么中国的程序员总被称为「码农」、程序员需要关注哪些代码优化质量问题等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！