虽说物联网是兴起的行业，但实际上其所用的技术绝大部分都是现有的成熟技术。
我在问题「物联网技术到底是什么技术？物联网工程到底是学什么的啊？」的答案下详细介绍了一些相关物联网技术，这里就重新简单复述一下。
物联网技术，我认为最基础的技术就是单片机/嵌入式开发。但是呢，并不是只有物联网专业才学这种技术。电子系、电气系、通信系都会学这类课程。单片机也可以称为微控制器，只需要把代码烧写进去，就可以让单片机获取检测数据和控制设备了，比如获取房间的温度，打开房间的灯。
设备终端可以靠单片机/嵌入式技术开发了，那么怎么联网呢？这个时候就要学习网络通信的基础知识了，完成学业后最少也会知道什么是TCP/IP协议。这一块的内容，我瞎猜和计算机系的网络课程半斤八两。即是说，如果你在物联网专业学着学着，发觉对计算机网络协议这一块更感兴趣，可能你更应该去网络工程之类的专业。
设备靠单片机技术，联网靠TCP/IP。那么联网后的服务器端程序该怎么写呢？这一块，你可以到计算机系的相关课程找到答案。
服务器端也搞定了，还有个问题，设备与设备之间需要联网吗？可以怎样组网？这就涉及到了电子通信系的自组网（比如ZigBee）相关知识。如果你想通过蜂窝移动网络（2G、3G、4G）控制设备而不是局域网。那这更应该找通信系要一套方案了。
综上所述，物联网专业=电子+计算机+网络通信。
如果各位高中毕业生看懂了上面的描述，很不错，算是对物联网所用的技术有一定感性的认识了。但这也间接证明了物联网专业所学内容可能没有其他专业那么有深度。比电子硬件比不过电子系，比软件编程也比不过计算机系，通信技术学得又没有通信系强。
物联网本身就是属于一种应用学科。支撑起现有的物联网的技术都是成熟的电子类、计算机类和通信类技术。自然，物联网专业所开设的课程不外乎可以从电子系、计算机系和通信系的课程挑选出来，拼凑一下即可称为物联网专业。
不好吗？电子系出身的人看物联网专业感觉就是自家的知识，计算机系和通信系的人也是这么想的。所以这类正统人士可能都感觉物联网专业徒有其表、浪得虚名，是一个炒作起来的专业。还不如去计算机系（电子系/通信系）专业。
不置可否。如果选择去了电子系，可能就接触不到相关的计算机知识和编程思想（比如 *** 作系统原理和类的思想）；如果去了计算机系，拿不起电烙铁，不会摸万用表，除了写代码就是写代码。但是物联网专业是一个折衷的选择，至少比计算机系懂一点硬件，比电子系懂一些服务端开发。
题外话，有些学校是入学一段时间后才开始分专业，私以为这是非常人性化的做法。因为这是一个重新选择的机会，虽然可能只能是在学院拥有的专业里选择，但是这已经足够了。且不说电子系和计算机系差别很大却也有人分辨不出差别，计算机系和网络工程之间、电子系和通信工程之间都有细微的差别。在大学里学习，就好像调整导d的角度，偏差了一厘米发射出去的导d可能就轰炸不到你当初的目标了，别的专业课程会教的内容，为什么到了这专业就需要自学呢？物联网连接网络代码是写到bit板。根据查询相关资料信息显示，Bit板是一种基于ARM处理器的开发板，可以用于物联网应用，具有低功耗，可扩展性和低成本等优势，适用于无线物联网和低成本物联网应用。
在我眼里，也经常会把程序员分成两类：一种是我等这种写业务代码的程序员，另外一种是研究高深算法、造“轮子”的“科学家”
将他们称之为科学家是有些夸张，第一次冒出这样的想法是参加一个技术大会，当别的嘉宾都在分享开发、设计、架构、管理方面的经验时，一名在腾讯工作的算法工程师（应该已经是一个小领导了），他上台分享了一些诸如：滑动平均自回归模型、神经网络基因表达式编程、SVM回归机集成学习坐在台下的我第一次冒出这样的念头：“这是科学家研究的东西吧。”
当然，倒也不能说写业务代码就很 low，写业务代码也不是想象中那么简单的。
写业务相关的代码，必须了解业务流程，还需要了解业务人员心里是怎么想的，也就是业务出发点是什么样子的。
比如我最近遇到一个需求，过程大概是这样的：销售人员在卖一款产品，这款产品非常火，有些优秀的销售人员一周可能能卖出去几百上千单；结果我们接到一个需求，要限制每个代理人的销售数量，比如每人只能卖 10 个（之前已经卖掉的不算）；这就让我们非常奇怪，本来卖的好好的，为什么要做这个限制呢？这个需求看起来就非常的不合理。
后来业务人员和我们解释了一下原因：因为这款产品公司不挣钱，销售人员为了推这个产品，花在别的产品上的时间就少了，所以出这个功能，就是让销售人员“收收心”，把精力放在其他产品上。
这么一解释，我们就立刻明白了；所以如果你不明白业务的时候，看着需求敲代码也是非常容易出错的。
有些人会认为业务逻辑就是一堆 if-else，但是我认为在实际工作中，这些 if-else 也是非常难做到的。
业务逻辑是人设计的，业务逻辑难不可怕，可怕的是它不严谨和变化快；业务逻辑和那些确定性的东西不一样，比如我们写好的代码 if-else 两个分支，那么再怎么也不会跳出这个范围，业务逻辑就不一样了，它是非常灵活的、不确定的，业务机会来的快消失的也快，我们很难开发出来一套全面的、完善的、灵活的的系统，去应对将来可能会发生的需求。
所以在开发过程中，如果可以将业务流程拆分成多个组件模型，组件和组件配合完成一个完成的业务流程；当业务发生变化或有新业务的时候，只需要重新编排这些组件，或对某一个组件做少量更改，就可以满足业务变化；如果能做到这个程度，也是非常不容易的。
在这个过程中，你需要做到高内聚低耦合，避免过度抽象，从业务流程和动机出发，已满足业务需要为主；既然做不了“科学家”，我们就努力把业务代码写好把。
首先，我认为写业务代码不“low”，但是大部分不假思索拷贝粘贴的业务代码比较“low”，换句话说就是所谓的五年工作经验就是把第一年的工作重复了五遍。
技术人员成长一般有两条线，一条是成为技术专家，一条是成为领域专家。所谓的转管理我理解也就是领域专家，毕竟不懂得领域知识是无法做好管理的，比如说你是互联网金融某个业务部门的leader，那么你肯定要懂金融。领域知识就是在不断的写业务代码和思考中积累起来。
还有一个问题就是如何定义业务，比如说“实现一个修改订单功能”，这是一个业务需求，看起来很low，但是如果业务需求改成“实现一个修改订单功能，要求在有限资源的情况下并发10k，响应时间不高于10ms”，那这个需求就有挑战。说这个问题想说明白一件事情，如果做业务不要停留的在业务表面，仅仅满足于实现功能，要主动思考。
最后总结一下，没有最好的技术，只有最适合业务的技术。技术是内功，业务是招式，内功不足，后续成长乏力，没有招式，内功也不能发挥威力。这是也很多互联网创业公司做大了之后要技术转型的原因。
作为一个程序员，我也是写代码的，我不觉得写业务代码很low。
1首先大家所认为的业务代码就是一些和业务相关的增删改查，涉及到的技术点相对来说是固定的，写熟了之后，就是复制，粘贴，不存在什么技术阻碍，很多人就觉得非常的简单，没有技术含量，做这些工作的人也显得非常的low，如果你也是这样认为的，那你就错了，因为写业务代码的基本都是初级，中级的程序员，工作经验有限，不具备写一些公共方法和接口的能力，但是并不代表以后能力不会提升，如果持续努力，也会成长为高级程序员或是架构师，谁天生就是高级程序员呢，不都是一点点积累起来的吗？而且就算是写业务代码也不能就是low呀，有些业务场景是非常复杂的，逻辑必须十分严谨，稍有差错可能就会出现bug，对公司造成巨大的损失，不是写业务代码就是很容易的。
2除了业务代码就是非业务代码了，比如开发数据库，开发框架，或是写一些公共的方法或是接口，供初级开发者调用。写非业务代码的人技术也不一定就非常的厉害，因为就算是开发框架或是数据库之类的项目，也不一定都是高级开发，也会有一些水平较低的开发，因为写业务代码还是非业务代码和项目也有关系，如果你们团队开发的是开发框架或是数据库这种的项目，那么你们团队没有人写业务代码，也不能说明你们团队每个人技术都很厉害，只是项目性质不一样罢了。
3业务代码这个词看你的理解吧，我认为其实所有的代码都可以成为是业务代码，无论开发什么产品，都是有业务需求的，有了需求才有开发的动力，对于开发数据库来说，数据库的需求就是业务，对于开发框架来说，框架的功能就是业务，所以我认为广义上来讲都是业务代码，没有非业务代码这一说，所以具体看你认为业务的定义是什么了。不过无论如何也不应该去嘲笑或是去贬低别人吧，嘲笑或是贬低一类人就更不应该了。
业务程序开发相对于底层基础架构层的程序开发有所不同：
业务开发的时间比较紧，变化快。
这个特点导致程序员没有时间重构代码，或者不愿意重构代码，而是用最简单粗暴的复制黏贴的方式快速实现业务逻辑。其实所有的复制黏贴都意味着需要重构。
底层系统的开发，一般是架构师和高级程序员来设计和控制项目时间。相对来说，开发周期长，变化缓慢。会更加注重架构的合理性和稳定性，而且会不断重构和改进。
业务开发一旦完成，只要平稳运行就不会有人再回来补技术债务，不会把它写得更好。除非这个业务爆发了，不得不从新架构以支持更高的并发。如果上线之后表现不佳，很可能下线不再维护。所以公司也不太愿意花太多精力在一个还没有被市场认可的产品项目上。
而底层架构框架的项目会在不同的产品项目中不断应用。不断地进化。就像Spring之类的开源框架一样，不断的升级和完善。
相对来说，业务开发程序员会花大量的时间学习和理解业务知识；而底层框架程序员更多的时间在学习技术架构。如果业务知识在行业内通用，比如财务，金融行业知识。那么长期的积累对业务开发也是很有帮助的。如果业务是很小众的，甚至，这几个月做这个业务，下半年又做另一个业务，做的时候也一知半解，就像很多外包一样，那就没有什么业务沉淀了。
不要太在意所谓low与不low，需要在意的是做了这个项目或业务后，对自己的能力有没有长进，如果有，那说明不low。如果没有，那说明你只是在机械的劳动而已。
每个大佬都是从业务代码做起的，大佬们注重的是能否成长，学习实践的机会，以及平台的大小和未来是否和自己的目标相匹配。
总结来说，只要能提升自己能力的任何工作，都是值得的。
我觉得首先大家要理解什么是“业务代码”，业务代码是一个相对的概念。
1对于一个一般的物联网应用型公司来说，业务代码就是根据客户需求基于一个MCU或者MPU的应用控制逻辑的实现。
2对于一个做纯上层应用的公司来说，业务代码就是基于一个 *** 作系统为客户量身定制对应的app,并实现对应的应用逻辑。
3对于一个微型控制器设计厂商，业务代码就是底层架构裸机的具体实现和各个外设驱动的框架设计。
4对于一个设计 *** 作系统的开发人员来说，业务代码就是架构设计、内存管理、调度机制优化、优先级管理、进程间通信机制优化、线程管理和内核完善等等。
所谓”业务代码”都是相对的，没有参考系怎么谈。像 *** 作系统，站在 *** 作系统内核提供方的角度看，上层所有的应用框架，进程服务，都是业务代码，我是为他们服务的。技术只是工具，业务实现才是目的，站在不同供应商的角度，只要涉及代码的地方都可以称之为业务代码。所以站在这个维度，如果要说业务代码“LOW”,那就没有代码是不"LOW"的了。
不过，真正接触底层或者实现RTOS底层业务框架的工程师其实是很少的。大部分工程师基本上都是对于客户需求做一些非驱动底层非 *** 作系统框架的应用型的开发，所以大多时候“业务代码“又单一的被指向了那些只是对客户的上层应用的需求做开发、调整或者迭代的代码。
而这部分代码究竟"LOW"还是不"LOW"呢，我的答案是：不"LOW"。但是现实却是很“LOW”,之所以会被想成LOW，是因为：
1判断一个程序员的优秀程度已经不单单看你写了多少应用型的代码，设计了多少应用框架，而是你懂不懂底层驱动逻辑，懂不懂 *** 作系统内核，懂不懂内核裁减等等。所以这种情况会经常出现在面试过程中，面试官会因为你不懂底层驱动、不懂内核而给你比较低的薪水。
2懂得写业务代码的人，他的程序员基础并不一定就牢固。因为上层应用可能对业务比较看重，但是对于一些特定的语言的编程并没有那么严谨。能用就可以，所以会自然而然的认为这样的程序员“LOW”。而一个会写底层驱动的人，他考虑更多的是基础代码的安全、严谨性和容量问题等等，他们的语言基础相对来说要牢固很多。
3技术负责人一般都是全能型的人。会写底层驱动或者更懂 *** 作系统内核的人更容易成为技术的领头人。而那些只会“业务代码”的人，放在大部分公司,一般都不会有太多的上升空间。
根据以上分析过后呢，做“业务代码”的程序员基本上会被想的很“LOW”,但是结合我的亲身经历，不同的人对于这个事情却会有不同的看法。
比如对于领导来说，那就不一样了。你将“业务代码”的需求迭代了，完善了，提前任务完成了，客户很满意。那领导不会认为你是一个很“LOW”的程序员。你很高级，领导很欣赏，“后果”很舒服。但是对于一个面试官来说，你就会点上层应用的调用和设计。我为什么要给你这么多薪水？虽然会被想成很"LOW"，但是也是现实。
业务代码不一定low，能完成用户需求的代码就是好代码。
另外，对于我们搞嵌入式软件、EDA工具软件的来说，业务软件反而是更有技术含量的，更具科学意义的代码，而软件可能只是载体，你啥时候透过代码理解了它们背后的物理概念、数学公式，你就超越了程序员，能向科学家又迈进一步。
互联网软件其实也一样，软件实现的是一个业务流程的自动化，你完全可以透过你写的程序还原甲方用户的业务流程，而这种流程是老板制订的，认识会上一个层次，将来可以向老板迈进
我发现很多程序员对于处理业务逻辑都是「嗤之以鼻」。感觉自己天天写业务逻辑代码，改 Bug 都没有时间学习，没有时间实现个人成长？
但是，作为程序员来讲，如果不是做底层基础技术研发的话，大部分的工作不就是做这些拧螺丝的工作吗？其实拧螺丝有那么容易吗？可能拧螺丝很容易，但是拧好螺丝就不那么简单了。
别小瞧业务逻辑代码，如果真正写好，要把逻辑写得清晰简单易用，功能健壮稳定，性能同时达到要求的话，其实是挺难的。
其实很多程序员都跟他一样，都在痛苦的编程，一方面对自己有更高的要求，一方面又嫌弃现在写的代码没有技术含量。又有更高的要去和希望，又嫌弃现在的工作，就是不思考出现的原因，不去付诸行动。还不停的抱怨： 感觉自己天天写业务逻辑代码，改 Bug 都没有时间学习，没有时间实现个人成长？
到这里，我们不禁一问：那我们该如何摆脱这种现状呢？其实很简单，我们应该摆正自己的态度和观点，正确看待写业务逻辑这些代码就行了。
坚持不懈的写好业务逻辑代码
就像我在上面说的： 别小瞧业务逻辑代码，如果真正写好，要把逻辑写得清晰简单易用，功能健壮稳定，性能同时达到要求的话，其实是挺难的。
所以，我们要正确看待写业务逻辑的代码，应该摆正心态，坚持不懈的去写，所谓量变引起质变，就是这个道理。写业务代码，积累代码量，一力降十会，在积累了巨量的代码量之后，几乎任何所谓的有技术含量的东西都构不成挑战性。当然，要想真正的通过自己写业务代码，写好业务代码还应该有接下来的这个思考。
其实业务逻辑代码一样可以玩出很多花样，而这才是能够提升你能力的本质。比如：你写了一个处理单任务的业务逻辑，虽然满足了用户的需求，但是你这时能不能对自己有一个更高的要求呢？单任务虽然是功能实现了，但是效率可能不行，处理慢，那搞个多任务处理的逻辑怎么样？任务池、线程池、内存池、并发、同步等等这些技术点都来了。如果你对自己有这样的要求，而你自己有追求的话，就会进一步思考如何去做到这些，你做到了，你能力就提升了。
同样，很多人感觉处理业务逻辑，就是一些各种循环，条件判断，只要逻辑稍微严谨点，功能就都没问题，就都实现了，确实是这样的。这就是你对于业务逻辑没有兴趣的根点所在。
那你为什么不想想： 如何使用循环和条件判断可以提升效率呢？满足了功能的那些需求，是不是有些地方可以优化一下呢？是不是可以提升一下性能呢？
其实，这个技术的进步和积累，就在于自己内心对自己有没有更高的要求和追求。这是大实话，也是大白话。很多人就感觉只要实现了功能需求就够了，满足了用户就行了。然后，这个项目完事了，下个项目遇到差不多的逻辑，还是这么处理，又完事了，每个项目，每个功能都是这样重复的处理，从来不思考最优的实现方式，你感觉能够进步吗？你能不烦气吗？十年如一日的工作，10 年也就积累了一年的工作经验，在重复使用。
业务逻辑的最优方式，就是思考如何大道至简
通过一个业务逻辑实现一个功能，基本上只要是程序员，脑子不笨，都能做出来，做出来是一回事，但是做好是另外一回事。大道至简，我们要做就得想办法做到最好。这里的好有很多层意思。
比如： 你写的业务逻辑代码 是否能够做到准确，稳定，高效，易读，易扩展，易维护，兼容性强呢？ 问自己一句，如果你能做到这些，那确实是好。如果做不到，你还是处理初级水平，当然不行，这就是你在工作中提升能力的机会。别说没时间，都是借口。
精益求精是对代码大道至简的永恒的追求，也是我们在处理业务逻辑代码中不断提高自己能力的过程。
明明自己水平初级，就容易骄傲自满，感觉可以了，我想学更高的技术，那么更高的技术是自己在处理业务逻辑中一步一步积累出来的，不是干了初级的活，不用积累，直接学高级的技术，就能高级了。
我特别喜欢网上有个网友写的一段话：
其实很多技术大牛和技术专家，都是从业务逻辑做起，慢慢积累思考起来的。比如：在处理业务逻辑之前，会思考如何设计这个架构，可以让代码更好的扩展和维护。在处理业务逻辑的时候，思考如何的处理才能提高性能和效率？一步一步的实验和总结，积累，才成就了今天的成绩。
所以，不要对处理业务逻辑嗤之以鼻，不要以为能够满足需求就够了。你重复不思考的粘贴和复制肯定是不行的，必然会对编程失去兴趣，自然无法更好的成长和进步。应该在编程的过程中追求更高的要求，寻找更高的兴趣，这样才能让你持续进步，从而进阶。
林子大了什么鸟都有，不知道你说的有人是指多少比例的人。我的理解代码可以分为两类：1:工具栏或者框架类2:业务类。写工具类偏重于健壮可拓展可复用；写业务类偏重于逻辑严谨没有漏洞，化繁为简。毕竟有些时候需求或者业务都不甚清楚他们想要的逻辑。有时候复杂的业务流程你捋都不顺，更别说代码写的好了。当然，工具类到高深，工具好用，框架优秀确实需要的技术功底深厚，比业务类要考虑的东西也多，但不代表写业务类代码很low。当然，不管写什么代码，完全复制黏贴而不去考虑与实际场景结合，不去想为什么？有没有更好的处理方案是比较low的
天天给我讲技术栈，让你这个业务代码，半个月搞不定，然后又bug一大堆。业务代码培养人的逻辑思维和全局控制，这个是基础没有捷径。至于技术，外面一大堆，看你怎么选择。
零经验的人学编程是很难的，因为需要许多的专业知识。
第一门编程语言C语言，C语言目前是底层应用开发最为广阔的一门编程语言，是物联网必备的开发语言。
第二门编程编程java，java目前的优势比较多，在开发安卓方面目前非常成熟，市场上几乎所有安卓APP都是java开发，再者java在网站开发也有自己的优势，大型类网站选择java开发是最好不过了，支持多线程高并发，可以支持上百万人同时在线，或者更多。
第三门编程语言python，未来发展方向必定是物联网人工智能，python不仅在人工智能有优势，其实python可以说是万能编程语言，服务端，Web开发都是是可以开发的。
第四门编程语言JavaScript，特别是学习nodejs前端后台框架，如果你熟练nodejs，其实可以不用担心不会其他后台编程语言，毕竟nodejs完全搞定
如果自己学的话，你可以通过网络（网上教程），或者买书（C primer plus），但是别太依赖网上教程，因为不清楚+声音小+错误百出+地方方言你听不懂。
区别还是比较大的。\x0d\物联网技术中的编程主要是和物品传递过程中的信息流和机械设备控制有关，比如RFID的控制和信息交换、一维码二维码设备的控制和信息交换等等，重点在无线通信技术、工业控制技术、传感器技术等等。\x0d\软件开发专业的重点在于软件工程理论、数据结构算法理论、程序设计的有效性、信息安全、数据交换理论等等，所学的知识100%是给写程序的人准备的。\x0d\可以这么说，学物联网技术的肯定会编程，但是没有学软件开发的会的精。我们曾招聘了个物流专业的毕业生，他绝对会编程，写的程序也能运行，但是很多地方不符合软件开发的规范，代码杂乱且效率也比较低，因为他没学过编码规范，也不知道怎么优化代码。\x0d\另外，学物联网技术的和学软件开发技术的比起来，会的编程语言比较少。物联网技术主要跟硬件打交道，用到的编程语言也就是汇编、C、PLC等等，也许还会加上C#、VB或Java等用来写界面程序。但是职业程序员每个人都会好几种编程语言，用在不同的场景。比如桌面程序或开发CS模式的程序用C#、Java，服务器端开发用JSP、ASP、PHP，工程计算用Python，浏览器端开发用HTML/CSS\x0d\/Javascript，数据交换使用XML/XPATH/XSLT/JSON等，人工智能方面用逻辑编程语言Prolog，工程控制用PLC编程语言或TCL/TK脚本语言等等。\x0d\\x0d\因此，学物联网技术的人，不建议向软件开发方向发展，应向工业控制工程师方向发展。1、低代码开发：开发人员只要通过编写少量代码就可以快速生成应用程序的一种方法。把数据建模、视图构建、报表生成这些相对标准化的开发过程可视化，从而消除更多的代码开发需求。
但是，它服务的依然是开发者市场，哪怕一个应用程序总共只需要20行代码，它也需要程序员的参与。所以，低代码平台的确可以提升开发者效率，但是很难改变软件开发的基本流程和人员构成需要。简单说，低代码平台的使用中，需求提供方和实现方依然是分离的。
2、零代码开发：
是为那些不知道也不需要知道任何实际的编程语言来开发应用程序的普通开发者而构建的。
所以，它面向的是全民开发者，只要他们足够了解业务需求，能够列出所有的需求点，不必求助于软件开发者，自己就能够将EXCEL文件转换为在线需求，然后通过拖拉拽的形式就可以快速按需搭建应用程序。这种零代码的开发方式，不仅节省了人力成本，还充分缩短需求方和实现方之间的距离。
简而言之，低代码和零代码平台，唯一的区别就是是否要求开发者具备编程的能力。
对于专业的开发人员来说，不管是使用低代码平台，还是使用零代码平台做软件开发，都可以大幅度提高开发的效率。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）