当前位置:首页 > 工程师
  • 工程师的姓氏很尴尬

    “高工,你设计图通过了么?” “王工,你真是越来越漂亮了!” “周公,Schedule 该更新了” “杨工,你这个数据分析还没提交啊” 很正常对不对。 你的内心一定是崩溃的。 #来来来,晒姓了# 来源:智慧汽车供应链(ID:IASC-CN) 编辑:Red K 转载:如需转载,注明出处 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2021-03-31 关键词: 工程师

  • 嵌入式怎么入行:工程师的自我修养

    前言 这篇文章总结了我做嵌入式工程师这几年的一些经验,分享给刚入行或准备入行的新手们! 首先我想说的是不问出身,做嵌入式的同学,基本都是计算机科学、电子信息、通信类专业。刚毕业的本科生,就学到的知识,名校与非名校在起点上相差不多,大家在校园里学的都是那几科,看的书也都差不多,如果不是很小就接触计算机写代码,那毕业时的代码量也都差不多。 而对于工程作业来说,对学术能力的要求没那么高,只要有一定的学习能力,技术是很容易掌握的,大可不必对自己的学历不够自信。 对于嵌入式软件工程师,一般是分成两类,嵌入式Linux、嵌入式单片机,我这里只讲单片机的部分,Linux的部分有机会再聊。 一. 认知的四个阶段 1. 不知不知 在刚工作的第一年,基本是一个学习的过程,很难有有效的产出,这个阶段是完成从一个生涩毕业生到企业员工的身份转换,如果校园里接触过比较多的代码,看过类似Linux源码那种级别的代码,对你快速学习还是很有用的。 这时你写的代码,也能正确的点亮一个led灯,能实现老板的需求,可日后来看,肯定是惨不忍睹的,说难听点,就是“像屎一样”。但这时你还不知道这些,你甚至“不知道自己不知道”,你觉得自己表现的还不错,可能偶尔会冒出“这个代码这样写会不会更好”之类的念头。 每个人都可能冒出这样的念头,不同的是,有的人念头一过就去干别的了,刷刷剧玩玩手机也是一天;有些人,没有让念头溜走,顺着念头走了下去,去找“这个代码换一种写法会不会更好”的答案。 2. 知道不知 找答案无非3个方式:问其他人(包括搜索引擎)、看书、看源码。 你当然可以问其他人,但你不能总问其他人,而且其他人不一定什么都能解决。 你开始看源码,你会发现,源码看不懂,随便打开个开源项目,一行都看不懂。 你一定会吓到,你想找本书来压压惊,随便翻一翻,竟然发现自己“这个也不知道”,“那个也不知道”。 这也是好事,至少你已经“知道自己不知道”了。 问人是最快最具体的;看源码不能一蹴而就,大师的代码我等凡人刚开始都是看不懂的,没关系慢慢来,多看几遍;看书是最系统的,如果你能带着问题去看书中的具体章节当然就更好啦。 现在,你有了学习的动力,你要做的,是开始填补知识空白,还等什么,快开始吧! 3. 知道己知 上面列举的三种方式,最系统也最有效的,当属看书了,我这里推荐几本书。 对于语言层面,当然最多用的是C语言,学校学的教材比如谭本《C程序设计》只介绍语法不说,还有很多误导,坚决不要看了。我推荐你读K&R版本的《C程序设计语言》,Bryant,R.E.的《深入理解计算机系统》,接着就是Andrew Koenig的《C陷阱与缺陷》、KennethA.Reek的《c和指针》、LinDen,P.V.D的《C专家编程》,对于C语言基础,这些已经够了。 看完这些,你最起码了解了计算机程序到底是怎么一步步生成的,对语言、对系统又有了进一步更详细的认识。 与此同时,可以看些实用性强的书,W. Richard Stevens的《UNIX环境高级编程》、《UNIX网络编程》,把语言上的所学的进行实践,了解编译器编译流程、Linux的基础命令,固件的交叉编译。注意,这2本书都很厚,不用强迫自己全看。 下一步,开始看你的专业相关,你所在公司总有一个具体的方向,音视频、图像处理、家电等等,我从事物联网安全行业,当然最关注的是嵌入式软硬件、网络、安全技术,那就要针对这3个方面找书了。 3.1 软硬件 做软件工程师也应该知道些硬件知识,模电、数电的基础还是要了解的。 硬件架构,用arm比较多,推荐看Joseph Yiu的《ARM Cortex-M3与Cortex-M4权威指南》,然后就是各个芯片的芯片手册了,我还记得第一次看芯片手册的感受,“天书!” 写的都是啥,全然看不懂——后来我发现所有的芯片手册竟然都是一个套路,只要看完一个手册,再看其他的就很快了。 我还推荐你学习些FPGA的知识,用Verilog尝试做些简单的硬件设计,会让你更深入的了解硬件的工作原理。 操作系统是一切软件的地基,对于嵌入式操作系统的学习,推荐左忠凯的《FreeRTOS源码详解与应用开发》和FreeRTOS、RT-Thread的源码。 3.2 网络 先扫一遍《TCP/IP详解卷1》,这些本科课程学过就扫一遍,没学过就仔细看看了。 接着可以看实现,我用lwip比较多,推荐看朱升林的《嵌入式网络那些事》,配合lwip源码一起看。这本书看完,可以看看《TCP/IP详解卷2》和《TCP/IP详解卷3》,这2本也都是神级科学家W. Richard Stevens的著作,超级厚,还是那样不要强迫自己全读完,有选择的看。 3.3 安全技术(换成你自己的领域) 我这里只推荐一本密码学入门,结城浩的《图解密码技术》,写的通俗易懂,又不是特别深入,适合初学者,其他就要去找更加具体的资料了,读者们从事各个领域,自然知道要找什么书来看。 对于这些书,我希望你能带着问题看,解决问题就合上,只看你感兴趣的部分,其他的章节偶尔翻翻混个眼熟就好; 很多书都是翻译过来的,有些表述并不准确,读起来不是那么容易,我也没有什么好办法,只能劝你静下心来慢慢看,反复看,多看几遍; 希望你能边看边实践,确认书中说的是对的,实践了才能内化成自己的。 为什么要“混个眼熟”?就是你要知道这本书还讲了什么,以后有类似的问题,就可以来有目的的翻阅了。 我认为,真正学的学会一样东西,有以下3个阶段,这3个阶段可能不是线性的,尤其第三个,可能是你很久以后恍然大悟才能达到。 3.4 真正知道的三个阶段 3.4.1 会用 比如那些网络接口函数,硬件驱动接口,你可以利用它们写出没有bug的代码,完成了项目任务,那就是会用了。 3.4.2 了解怎么实现 会用之后就是学习它背后是怎么实现的,这时你就要去查深入些的资料,看深入些的代码了,幸运的是,我们目前所能接触到的问题,大部分在互联网上都有答案,很容易就能找到,那些热爱求知的前辈们早已经为我们准备好了答案。 了解了实现,你就可以对之前写的代码进行优化了,你之前只能保证写出的代码没有bug,现在你知道它为什么没有bug了,遇到难搞的问题,你的思路会很开阔,马上找到问题点。 3.4.3 明白为什么这么实现 第三个阶段,就是你不单单要知道它怎么实现,你还要探求它为什么这么实现。 比如TCP/IP,为什么要分那么多层,还有没有其他的网络协议栈,几种协议栈不同之处在哪里,为什么其他协议栈就没这么普及呢? 比如各类嵌入式操作系统,为什么都宣称自己又快又小,他们的性能怎么评估,技术上实现的不同点在哪里,各个系统的作者为什么要那么实现? 当你能「评估」一类方案/技术的几种实现形式,说出各个形式的好坏差别,你就能做到融会贯通,在项目层面,你就知道如何取舍选择了。 以上是认知的第三个阶段,即不断的学习,真正的学会。这个阶段应当是贯穿整个职业生涯的始末,别人问一个问题,你第一时间的反应是”知道自己知道“,然后脑子里搜索答案。 4. 不知已知 买过很多书,看过很多书,你就形成了买书的习惯,看到一本新书,发现一本你没看过的书,你就想买来看。 买来新书,抱着学习的激情翻看目录,扫一遍,找到你感兴趣的章节开始读,边读边发现,咦,这说的不就是xxx原理吗,在xxx那本书中介绍过啊,这作者怎么换了个说法又讲一遍,这书真是买的多余。这时你其实不用怪作者,而是应该恭喜自己,恭喜你来到认知的第四个境界“不知道自己知道”。 你已经不需要再过多的看基础技术图书了,遇到一个问题,你自然有自己的解法,你不知不觉将之前从很多书中吸收的知识融汇贯通,任意组合,付与实践,而这些都是自然而然的事,你在解决问题时,不知道自己已经在用那些曾经学习到的知识了! 对于嵌入式领域的认知,我引入一个简单的问题,这是我认为的嵌入式技术里的终极问题,这一个问题能知道你处于上面哪个状态,这一个问题也足够让你“学海无涯苦作舟”了,如果能把这个问题详详细细说的明明白白,你的嵌入式能力已经炉火纯青,至少不会遇到技术层面无法解决的问题了。 “有2个嵌入式设备A、B,通过网络连通可交互数据,其中A有外接按键,B有小显示屏,2个设备实现这样的程序:A键盘上按下某个按键,B显示屏将按键值显示出来。 请问:从A按下按键那一刻起,到B显示屏看到按键值,”按键值“这个数据是怎么从A的按键传输到B的显示屏的? 二. 升级打怪 写了这么多,是不是学完这些就可以独步天下了? 当然不是!这只是万里长征的小小一步,这小小的一步在我看来,一般需要5-10年左右的时间,有些人只是有着一个念头但从没有抬起脚。 这一步什么时候迈都不晚,最难的是你有勇气抬起脚。 迈过来后什么什么样的世界呢?我引用吴军博士的五级工程师划分来说明你的职业规划。 如图,吴军博士在他的很多书里提到这个五级工程师的划分,我们刚刚说的,完成那些学习与解决问题后,基本可以说,你已经站在这个金字塔的最底层了。五级工程师,你好,你看这塔,一点也不高。 这个时候你该做的,不单单只是一心沉浸在技术的海洋知识的海洋里了,因为我们毕竟是工程师,而非科学家,要开始运用知识,解决实际问题,再解决更大的实际问题了。 解决更大的实际问题就要向着四级工程师迈进,这时你不单单要自己懂技术,还要想办法尽快把你的”鱼“和”渔“授给其他人。 你还要学习管理知识,掌握与上、下级沟通的技巧,如何推动自身和团队快速进步是你的挑战。 对于三级工程师,除了具备4级工程师的能力,还需要能够紧跟时代,预判市场,懂得营销,不单单做得出产品,还能卖得出产品。 二级工程师是指能做出先前没有的东西,世界会因为这多少有点不同,吴军博士举了这两人作为例子:北极光风投的创始人邓锋、Google云计算的发明人迪恩(Jeff Dean)。我见识有限,所知甚少,嵌入式领域我能想到的人包括大疆的汪滔,柔宇的刘自鸿,这里大胆激进的把他们放在第二级。 第一级是开创一个产业的人,包括爱迪生、福特、贝尔等人。 各位应该好奇我处于第几级呢,我给自己定在4.5级,目前可以独立完成老板交代的任务,也在努力学习提高自己团队的整体效率,产出更具创造性的成果。 三. 一点点建议 由于实际经验有限,我也在探索如何爬这个塔,不敢妄加定义,引人入歧途,下面只说一些个人看法,权当抛砖。 3.1 博览群书 计算机专业的同学不要只专研技术,也要看看经济、政治、生物、天文、地理、艺术、医学、历史等等,要知道,计算机这门学问,诞生不过几十年,放在人类历史长河中,比前面那些学科简直就是沧海一粟。 看杂书多的人理解力要比看的少的人强,看的多了,就会有一种「类比」的能力。 比如对于“面向对象”,如果在学习面向对象之前,你了解过亚里士多德的唯实论和他对「共相」的阐述,你就会理解的很快,根本不用老师教思想,只用学学语法就行了,而且你免不了会在心里嘀咕,面向对象的设计者是否正是受亚里士多德「共相」启发而设计出了这样的软件开发方法? 3.2 慢慢的爬,聪明的爬 爬金字塔呢,就是攒的过程,很多人浮躁,学知识只学一半;有些人自以为聪明,总想找捷径;有些人勤奋刻苦,但不得其法。 文章一开始我说过,工程作业不比科学家,是不是名校,成绩好不好都不是大问题,想想你本科接受的教育也才4年,况且4年只是有那么一丁点基础知识,而工作是一场人生马拉松,可不单单要跑4年的。 只要一个人有学习能力,就可以解决大部分遇到的问题,区别无非学的快慢、攒的快与慢。 有些攒的快些,N年后,他们被称为「神」,这个比例是1%; 有些人攒的慢些,N年后,他们被称为「牛」,这个比例是9%; 有些人基本没攒什么,N年后,他们仍是「农」,这个比例有90%。 N ≥ 20 不好意思,上面这个比例是我杜撰的,我故意把「农」的比例增大,目的是警惕自身,也希望读者能警惕不要成为那90%。 进入那9%的「捷径」就是慢慢积累,我们普通人只要坚持学习积累,就一定能达到。 进入那1%可能就比较有挑战了,据我所知,好的工程师年薪会到百万美金以上(股票+奖金),注意这仅仅是工程师,这个层次能达到最好,达不到也不要强求。 3.3 多重构 总结是使人加速进步、聪明进步的很好的手段,对程序员来说,对代码最好的总结就是重构。 重构代码能带来至少两个好处,一个是对公司的,优化代码,易于维护,日后有其他人接手会更快上手;另一个就是对个人了,谁重构谁获益,这是学习的最佳手段,如果你写了10个项目,没有重构过一次,那你第11个项目用的数据结构、模块划分方式可能和第1个项目是还是一样的。 而如果你但凡重构过哪怕一次,当你写下一个项目时会更加得心应手高屋建瓴。 重构,不单单是为了优化过去,更大的好处是指引未来。 这就是爬金字塔的方法,不断的重复:学习-->实践-->总结,这个闭环。 全文完,希望你能从文中得到或多或少的启发。

    时间:2021-03-28 关键词: 嵌入式 工程师

  • 3.8女神节丨闪闪发光的“她科技”!

    当你们走在,时代的前沿, 一路乘风破浪,不卑不亢。 那些女性的标签与偏见, 从不曾被贴上。 这股逆流而上的力量, 慢慢渗透进各个领域, “她科技”正闪闪发光! 致会“发光”的你(们): 敏捷的思维靓丽的身影坚决的行动力你始终是那个“披荆斩棘”的职场女神你的专业性、洞察力与领导力诠释了属于女性的优雅与知性 你也一直在寻找 那个工作中简单又平实的“小确幸” 其实它就在你身边 一次完美的仿真 一首从自己设计的芯片流淌出的音乐 ...... 据说这位女神会“发光”哦~ 致爱“探索”的你(们): 你说这个世界 比起香水和珠宝 一份来自火星的未知样本更让人着迷 那里有水吗? 在什么地方? 以什么形式存在? ...... 我们总想探索未知 这是人类的天性 美貌与智慧并存 也是你们的气质与优雅 据说这位女神不爱红妆爱太空~ 致所有的女性 愿你二十自立 披荆斩棘,高歌猛进 愿你三十随意 以己作舟,不寻彼岸 愿你四十美丽 顾盼生辉,一呼百诺 愿你五十小欢喜 余生皆可期! 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2021-03-09 关键词: 程序员 工程师

  • 工程师姓什么很重要!别再叫我“X工”!!!

    工程师之间都是这么互相打招呼的—— “高工,你设计图通过了么?” “李工,工程画完了吗?” “王工,你真是越来越漂亮了!” "张工,你的DFM整完了吗" “周公,Schedule 该更新了” “刘工,DOE做到哪里了” “杨工,你这个数据分析还没提交啊” “胡工,测试报告什么时候发邮件出来啊” 很正常对不对。 不过要是你姓下面这些姓, 你的内心一定是崩溃的。 十大不想被叫“X工”的工程师排行榜 #来来来,晒姓了# 请问您贵姓? END 直接来源:芯片之家 来源:智慧汽车供应链(ID:IASC-CN) 编辑:Red K 转载:如需转载,注明出处 版权归原作者所有,如有侵权,请联系删除。 ▍ 推荐阅读 呵,你会51单片机的精确延时吗? 关于画电路图的10大分歧,你站哪边? 早期MCU芯片是怎么加密的? →点关注,不迷路← 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2021-03-08 关键词: 嵌入式 工程师

  • 电巢直播谈硬件工程师新手主管的逆袭之路

    电巢直播谈硬件工程师新手主管的逆袭之路

    生活总是当你以为一切都是好事之时,不经意下个转角就会出现意外“惊喜”,当你以为一切皆是磨难之时,到达顶峰才惊觉这是无独有偶的风景! 3月2日晚8点,电巢直播带来了EDA365版主严春美老师的直播,作为职场规划师的她这次为直播间的朋友们讲述的是从骨干到带队伍该避哪些坑?为什么这次直播我要重点观看呢?或许这次内容是最能体现我最近心情的一句话! 最近,我刚刚提升部门主管,说主管其实也不是什么大主管,最多算个小班长,手上管着5、6个小兵。知道我升职后身边的亲朋好友纷纷发来贺电,闹着让我这个小主管请客吃饭,就连媳妇也说我这现在是小经理,未来很有可能继续晋升步入高管行列,这样她跟孩子就不用再紧巴巴的过日子了。实则不然,我的难处又有何人知晓呢! 我是从技术岗位提拔上来的,原来的部门主管高升了,领导看我平时工作兢兢业业,为人也和善便提拔我来做部门新任主管。可是,我从来没有带过团队,更别说管理团队了。最近我总是意识不到身份的转变,工作中也不知怎么分配工作最稳妥,又不想让共事的同事觉得我在耍官威,所以干脆我能做的就自己都做了,凡事亲力亲为,结果月底业绩平平,这让刚刚新官上任的我着实头疼。 对于这样的情况我也在网上发帖求助,结果发现现下90%的企业都会面临主管不知道怎么带团队的问题,由此可见,主管培训计划是何其重要! 当晚看严老师的直播,她指出来从骨干到带团队是需要一个“转身”。所谓转身是需要有一个践行期和胜任期。因为角色的转变带来的工作以及心理的转变也会存在,所以刚上任身份的转变就是一个试错期。之后的践行期适当的给下属机会,突出团队的力量,最后的胜任期便能看到业绩的增长。 看完电巢此次直播后深有感触,目前的我就是处在第一阶段的试错期,三个痛点也正戳我要害。基于此,我已经清晰地知道接下来工作计划及部门的工作安排,希望严老师的此次直播能够点醒我,使我的新手主管之路越走越顺畅! 严老师作为电巢特邀主讲嘉宾此次带给我们的是职场晋升之路的收获,据了解,电巢汇聚了50+华为、中兴等行业资深主管、技术专家及一流企业,以其精深的研发经验,帮助企业建设研发平台并进行流程优化。 目前,电巢平台也在积极邀请硬件产业大咖进行电巢体系课程及直播授课,帮助更多硬件工程师们实现自我能力的提升,工程师们可根据需求通过电巢APP报名预约,随时随地皆可观看。

    时间:2021-03-05 关键词: 电巢直播 工程师

  • 别再叫我“X工”了,“黄工”怎么变成“皇宫”了

    编辑 | Red K 来源 | 智慧汽车供应链 通常工程师之间都是这么互相打招呼的: “高工,你设计图通过了么?” “李工,工程画完了吗?” “王工,你真是越来越漂亮了!” "张工,你的DFM整完了吗" “周公,Schedule 该更新了” “刘工,DOE做到哪里了” “杨工,你这个数据分析还没提交啊” “胡工,测试报告什么时候发邮件出来啊” 很正常对不对。 不过要是你姓下面这些姓, 你的内心一定是崩溃的。 十大不想被叫“X工”的工程师排行榜 #来来来,晒姓了# 请问您贵姓? 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2021-03-04 关键词: 数据分析 工程师

  • 工程师的痛

    刚刚看了这个视频“工程师的痛”,比起春晚上小品有趣多了。堪称英语版本的“扒马褂”。可能只有工程师才能够理解工程师的痛。 客户经理:我们公司有一个新的战略设想,目的是增加公司产品的市场渗透性、最大化品牌忠诚度,提升形象辨识度。为了实现这个目标,开启一个项目,要求是绘制七根红线,希望你们公司可以帮助我们设计。 公司经理:当然了。这里Walter是项目经理。Walter,我们可以按照客户要求设计吧? 项目经理:(Walter)当然可以了。Anderson是我们画红线领域的专家。他和我们一起到这里来解答一下画红线相关的专业问题。 客户经理:很高兴认识你。我会很快让你了解我们的详细想法。她是Justine,我们公司的设计专家。我希望你要么使用绿色墨水,或者要么透明墨水画出七根红色线条,它们之间相互垂直。你能实现吗? 工程师:(Aderson) 不行,我主要担心...... 项目经理:Aderson,先别着急说不行。这个任务已经确定下来,我们必须完成。毕竟,你是砖家。 工程师:红线的意思是红色的线,需要使用红墨水绘制出来。如果想使用绿墨水绘制,额......使用绿墨水,虽然说不现实,但基本上是不可能的。...... 但最后,工程师为什么答应承担这个项目设计,并且还额外承诺更多荒诞的要求,有趣的内容还是看下面他们之间神情兼备的表演吧。虽然年过完了,但快乐不能少。 公众号留言 提问:想请问一下,AI视觉组激光射击“采摘水果”有射击方式和射击时长的要求吗?如果在行驶过程中让激光一直照射着,相当于激光“扫射”过靶示牌,请问可以吗? 回复:组委会在设计这项赛题的时候,设计了下面的要求:“如果射击水果的激光束信号落在目标靶心直径5厘米范围外,则判断此次任务没有未完成。” 所以,如果激光器一直照射,就会触发目标靶心外,导致任务没有实现。 关于“关于对车载激光器发射相关参数(激光频率、发射光功率、调制频率,光斑形状)等将会连同目标靶参照制作方案另外发布。”将会在3月初进行公布。 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2021-02-24 关键词: 嵌入式 工程师

  • 对于“工业设计之美”评审与决策的一点认知

    一个公司的工业设计师与结构工程师在细节的设计点上很容易出现意见分歧,这种分歧大到一个产品的形状塑造,小到生产制造效率最高化。结构工程人员以工程生产的可靠性、一致性、效率作为第一准则,而工业设计师更多的则是考虑产品的美观程度。在小公司里面,出现类似分歧争执不下时,通常是CEO拍板说了算!然而对于工业设计之美,每个人的审美视觉不同,得出来的结论可能相差甚远。CEO最后拍板定下来的外观是否凭感觉去猜测市场消费者的接受度?而当美观度与工程可靠性产生冲突时是否值得一试? 我见过一种工业设计的评审和决策机制,如下: 从评测中可以看到,对于一个工业设计是否能落地,评审中让不同专业工程人员从市场销售、结构工艺、产品规划、工业设计、生产品控、电子技术六个专业角度进行评估,同时加入用户代表、专家团从整体感觉、创新性等多个角度进行评测打分。这样的一套决策机制将产品研发中不同角色的产品人员的意见量化进来,并加以不同的权重等级。比起“凭感觉”的评审,这套机制明显要更加科学。 我了解到的这个机制,来源于2016年观看的一场“工业设计之美”的演讲,演讲者叫邱丰顺。 如今工业设计已然成为商业竞争的一个重要手段,在信息技术门槛越来越低行业里,对手之间的产品可能拥有同样的技术、相近的价格、类似的功能,那么设计便成为了产品在激烈的市场上有别于竞争对手的战略手段,这一手段甚至可以塑造一个企业在消费者心中的品牌形象。 工业设计在产品塑造过程中,靠“凭感觉”来定义工业设之美不免显得冒险、主观,一套好的评审、决策机制,可以定义出“真正的美”,这种美不仅仅是外观漂亮,还有靠产品本身传达出的商业理念、工程制造、电子创新等等! 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2021-02-03 关键词: 工业设计 工程师

  • 一个老工程师的工作经历和思考

    在这里不敢以”资深”工程师自居,因为学历和技术水平确实一般。为什么说“老”呢?因为工作时间确实够长,已经接近20年。 下面把自身工作和学习经历和大家分享一下,使初学者能够得到一些有用的东西。 2000年毕业,机械电子专业。但是毕业后基本上机械不会制图(更不要提设计)、电子不认识元件(模拟电路两眼一抹黑、数字电路勉强知道一点点)。 由于家庭条件不好,考虑后期买房结婚等诸多问题。因此,在亲戚的介绍下去了天津武清开发区,操作和维修机插设备(使用机器给电路板插直插元件)。一共干了2个多月。每天12小时,全月无休班。真的顶不住了。于是辞职。在这个单位,认识了直插的电阻、电容、电感等元件;其他收获不大。 9月份,回到了天津,从家里一共带出400元钱和几个同学合伙租房子,回到天津,第一次去招聘会。天津比较大的招聘会一个是“国展”一个是“体育中心”。在那个时代,社会很疯狂,只认学历,夸张的说,清洁工都想要招聘“本科”,而且,很多单位只要市内六区的,这2个条件就已经限制了我。因为9月份,大批的毕业生已经找到工作。所以招聘应届的单位也少。 我大概2个月没有工作。后来,在一个小的招聘会,应聘到了一个职位,是天津大学校内的一个企业。做的产品是食堂售饭机。我的工作是生产、维修、出去装机等。当时那个产品用的就是8031单片机,CPU是8031和程序是存放在2764的,是分开的。这个工作干了接近1年,学会了焊接、使用万用表和简单的维修、只会看特别简单的电路图,连维修工程师都算不上。 在那个单位因为待遇问题,一生气就辞职了,也算是裸辞。当时距离过年也就差2个月了。找工作又不好找了。在家待业的2个月,我就看看书准备考试(为了学历,专科接成人本科)。另外,也感觉技术太差,找个维修都不行,我有印象,当时手机已经开始火爆,有个天音科技,我想去那维修,人家没有录取我。 在2个月的时间,除了准备考试,我就开始看模拟电路这本书,粗略的看了一遍吧,稍微有一点一点收获。我原来在学校学单片机是8051,而且是汇编程序,也翻腾出来了,慢慢看。 2001年底,应该是农历年底,找到了第二份工作。在一家国企 (做仪表的),应聘的是检验员。当时也是机缘巧合吧,公司正好缺少维修人员。想让我去售后维修,我拒绝了,因为我业余时间还要上转接本的课。于是,我转到了维修,开始进行维修工作。 在2002年初到2003年初,这个阶段,业余时间就开始正式的学习了。主要是模拟电路、数字电路和51单片机。在那个时代,网络还稀缺,只有去网吧,而且,网上资源也很少。最好的获得知识的途径,就是看书,在我印象力,北京航空航天大学出的书是最好的。为了学习编程,我和我的同学,共同出资400元,购买了一个编程器(我当时一个月工资是800元)。 我做的第一个东西,是一个电子时钟,用数码管显示,带几个按键可以调整时间。能够显示年月日时分秒。电路板,就是实验板,然后飞线连接的。用的是伟福的软件,汇编程序编写的。大概有2000行汇编语句;每天下班就弄,周六日也不休息,整整用了2-3个月才完成。然后,就是烧写进去,乱码。也没法仿真,就是改了烧,不行再改,不断折腾;没人指导,只能自己慢慢找毛病。终于成功了。当时还用电池带动,使用了1个多月,走时还挺准的 。如果用C语言,熟练编程的话,可能有2-3天就搞定了,从这里能看出,第一水平很初级,第二汇编效率也是非常低的。 到这时,已经有一点点入门了,至少比操作STM32跑马灯水平要高一些。在随后的1年多时间里,由于表现的维修水平比较好(一共2个维修,就我是男的),调离到设备处管理设备。当时管理的设备是电表测试、水表测试台、气表测试台;只有电表测试台是电子设备,其他不是。由于当时,要在国外建厂,电表测试台厂家,特意派技术人员进厂培训。我学了有2个多星期,之后的时间,就是在工厂管管 设备,维修一下,倒也轻松。招聘会,偶尔也去。就看到招聘要求比较流行的单片机,430、AVR、PIC、51等等……当时,我的工资1200左右,搞编程的一般2000多一点,为了能赚的更多,其他几种单片机都简单的研究过。也和现在的年轻人一样,想尽量多学东西。 在2004年,对我来说是一个契机。在朋友的介绍下,去了一个单位搞兼职(编程)。这个朋友给我技术上帮助很大。从去那个单位,才正式做产品、编程、绘制PCB 。当时的绘制PCB的工具是PROTEL99SE,90%以上工程师都用那个。当时选择余地也很小。我做的第一个编程就是控制液晶 24064的(T6963C)。 在2005年,正式从国企离职,全职干编程和硬件,也正式走上了自学之路。在这里有些想法想和年轻人说一下。在这几年去招聘会的过程中,已经发现,有的招聘软件工程师,就要求35岁以下。所以有的人发现,中兴、华为,有工程师被离职,有的40来岁就被辞退,当成稀奇事物。实际上在20年前 ,就有苗头了。只不过,那个时代,编程才刚刚兴起,从业人员还比较少 ,所以大多数人没有认知。 现在,随着互联网的兴起,游戏、网络、计算机软件等等行业铺天盖地,在加上大资金的火上浇油,更是火爆。新闻、网络在不断说,每年有多少万的人员缺口,工资待遇也高,新毕业的学生更是舍生忘死了。实际上现在的人,有很多忘记了过去的一段历史。在95-2000年的一段时间,炒过一段概念,就是计算机软件。当时的工人市场工资大概6-7百元,搞计算机的大概拿到6000-1万。那批人,可以媲美现在的金领、高管;引领了 当时的高消费,贷款购房、购车,然而,短短3年间,待遇一落千丈,待遇回归到正常白领,甚至还不如。 现在,每年毕业的大学生上百万,但是新闻说,每年软件的缺口是50万。由于待遇好,大家疯狂涌入 ,各种培训班应运而生,培训费2-3万,培训期半年上岗,待遇1万以上。大家应该理性的想想,凭什么,这么短时间能入门,就应该拿高工资呢?就凭大学毕业吗?以后,人员继续涌入呢?如果扫地的大妈,工资也一万,入门门槛更低,会是个什么情况? 只能说,这波浪潮是时代的需要(全球互联网时代),是大资金(东风)的推动。但是,大家要考虑,真的我们只需要淘宝、微信、互联网、快递员就能生活了吗?他们只是起到了运输、推广等等作用,我们真正消费的东西,吃的东西,都是由广大的人民群众在默默的生产,没有底层建筑哪里会有上层的销售呢 。到一定时间,价格就会回归价格。尤其是现在的互联网,压榨年轻人,所谓的996等等,真的正常吗?真的值得吗?值得大家思考。 在这里,我也发表一下自己的思考,为什么大资金会注资互联网呢?为什么,东北的老工业基地,基本完蛋,没人投资呢?这里大家要关注一个问题,就是资金周期。就像,房地产火爆一样,就是资金周期短,银行支持。互联网也一样,他的资金主要用于房租和人员工资,设备投资基本忽略。做个游戏或者软件,短则半年-1年,长则2年,然后,就是广告宣传,销售。基本就结束 了 。但是搞仪器设备不同,开发周期长,门槛搞,使用环境恶劣,各种售后问题。一旦产品开发人员水平不行,做出来的东西有先天问题,要更新换代产品,老产品就报废了。这些产品,能卖出去就是钱,卖不出去,就是废铁一分钱都不值,人员工资和房租在这里面的占比小的多。还有就是销售和回款周期也要长的多。 在2005年到2013年左右,相对来说度过了比较平静的几年。当然,这几年当中也干过私活。包括民用的电动车控制器。后来我也总结经验,发现民用的东西,太难了。真正的难度不是技术,是价格。数量大,价格压的非常低,一旦有售后问题,非常麻烦。因此建议大家选择就业还是不要倾向于民用,太苦了。 在2013年至今,逐步从自己搞研发,脱产出来带研发队伍。这个过程中,发现51的资源已经落伍了,32从10年之前,开始兴起。所以,也逐步的研究起来。在后来,也顺应时代的需要,开始学习单片机系统。也研究了几个月的周立功的A7开发板(LINUX系统)。 在这期间,断续的带过几批 年轻人,从0基础到工作2-3年的都有。也总结了一些培训的经验。在这里想说一下自己的感想: 第一,由于互联网时代的兴起,各种书籍、资料、视频、大佬的言论,满天飞。初学者,一头雾水,两眼一抹黑的东西乱撞。这里讲讲单片机工程师的学习步骤: 首先去搞一个开发板,简单的就好,选择销量大使用人多的,你遇到问题,可以在论坛讨论。否则,没有多少人那么无私的,细致给你解答问题;然后,认真的把引脚配置、定时器和串口搞明白。当然,这里有个前提,就是会一点点C语言,如果真的是0基础,那只能先去看看单片机C语言的书或者视频了。把例程里面的实验,慢慢整明白。复杂一些的,比如,I2C、SPI,彩色液晶屏等等我认为都可以靠后一些再弄。 第二,可以看看教程视频,看看怎么驱动的蜂鸣器,怎么驱动继电器等等,提高一下学习兴趣。 再以后,就可以按照自己的学习或者工作需求,来进行了。比如,高物联网、搞液晶显示、搞电机控制等等。 好了,我的经验分享到这了。欢迎大家留言分享你的经验和思考。 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2021-02-02 关键词: 工作经历 工程师

  • e络盟社区上新多个基础课程学习模块,助力工程师拓展专业技能

    中国上海,2021年2月1日 – 安富利旗下全球电子元器件产品与解决方案分销商e络盟为其在线社区平台上的基础课程学习项目引入更多创新学习资源,涉及可实现高效功率转换的GaN FET、面向纯电动汽车/混合动力汽车(EV/HEV)应用的汽车传感器,以及飞行时间(ToF)传感器。e络盟社区“基础”课程项目由e络盟与其重要合作伙伴联手共同打造,旨在帮助社区成员提升专业技能,便于他们及时掌握行业发展趋势及创新技术。新增“基础”课程模块包括: · GaN FET,实现高效功率转换(由Nexperia提供):随着全球向低排放汽车、可再生能源使用及更高工业自动化的目标迈进,业界对电源模块的性能和效率提出了更多新的要求,以提高电能转换效率驱动动态负载。本课程阐述了功率转换应用对电子元器件的要求,并分析了现有解决方案的局限性以及GaN FET技术在可再生能源和电动汽车领域的巨大应用潜能。 · ToF传感器(由意法半导体提供):红外(IR)三角测量、激光、超声波和飞行时间(ToF)是数十年来各工程领域最常用的测距和检测方法,覆盖机器人、存在监测、光学导航、医疗科技和汽车应用等。该课程介绍了意法半导体ToF接近检测和距离传感器及FlightSense™专利技术,能够让社区成员了解到ToF传感器的基础知识、飞行时间测量方法、多种距离感测技术、ToF传感器设计与挑战,以及多种场景应用。 · EV/HEV应用汽车传感器(由安费诺提供):汽车产业是全球经济增长的重要推动力,然而,汽车电气化趋势给混合动力汽车(HEV)和纯电动汽车(EV)设计带来了更多新的挑战。本学习模块概述了混合动力汽车和纯电动汽车的架构,介绍了所使用核心部件,并探讨了影响乘客舒适性、发动机性能及车辆动态特性的多种重要汽车传感器。

    时间:2021-02-01 关键词: 传感器 e络盟 工程师

  • 如何用这一产品阵容设计您的下一个项目

    时间:2021-01-30 关键词: 物联网 工程设计 工程师

  • 现在做硬件工程师还有前途吗?

    这个问题是我在知乎看到的。 问这个问题的,要么是正在从事硬件工作,要么是准备入行的新人。 我工作年限不久,今年也才19岁(去年18),工作4年多。 我先发表自己的一些观点,可能不对,勿喷,然后我再截取部分知乎上网友的回答。 我大学的专业是电子信息工程。 毕业找工作,选择硬件,1是我软件不行,2是我对软件不感兴趣,3是我只能干硬件了,4是我想干技术。 我记得大四父母就没有给我钱了,为了能找一份养活自己的工作,所以我选择了面试硬件。 也就是对硬件稍微感兴趣,稍微熟悉一点,面试的时候稍微能吹嘘一点。 稍微能吹嘘一点指的是自己有一点项目经验,参加了一些电子类竞赛,如电赛、飞卡、物联网等。 一切看起来都是那么的将就、勉强,就这样,我还是找了2个月的工作,持久战让我收获了几个offer,综合考虑,选择了现在这家公司。 所以回到问题:硬件工程师有前途吗? 我们先假设硬件工程师没有前途,软件工程师有前途,搞Java的很有前途。 Java面试官sowhat1412隆哥向你抛出了三个问题: 1、HashMap为什么线程不安全,如何替换? 2、解释下死锁是什么? 3、为什么用线程池,线程池的作用? 你一听一脸懵逼,这都什么鬼? 所以就很简单的道理,前途和实力是匹配的,你如果是稚晖君那样的全栈,可以选择自己感兴趣且工资高的AI算法 ,而我只能选择混口饭吃的硬件。 有人说了,这和问题没什么关系,这个假设不成立。 那我们再假设硬件工程师有钱途,这里,我将前字改成了钱,让问题变的简单一点。 我去BOSS直聘上搜了一下,我现在从事的硬件-基带工程师的工资。 是不是也很可观,5年+工作经验的基带,我觉得在上海稍微努点力,拿一个20K应该不成问题。 霍,在搜一下IC设计,3~5年工作经验的直接30K起步了,本科毕业的一般都是20K起步了,好一点的学校,好一点的IC公司,本科强一点,毕业30K也是很正常的。 可能别人又说了,互联网的大厂,比如字节,PDD,微信团队,这些刚进去可能就30K起步了。 这样的人能有多少? 太少太少了。 大部分人还不是拿着温饱的工资,可能在北上广深这样的城市,也就只能吃住行了,每个月剩不了几个钱,甚至入不敷出。 搞Java,我认识的隆哥(硕士)在北京4年半也才20K出头,985电科大毕业的大帆在西安三星也就15K左右。 我们总是被互联网的风光所吸引,却看不到一串串代码背后的艰辛,那是多少个996,007构筑而成的。 向往互联网的灯红酒绿,熟不知那是通宵熬夜的灯光。 所谓的前途只不过是比别人更努力一点。 你向往并持续为之付出努力的,那才是前途。 又有人会骂了,你TM这是毒鸡汤,互联网这么发达,天花板比硬件高太多了,这一点我不否认,你可能干十年硬件,也就这个样子。 我们再看一下知乎网友的回答。 多多说:我也是女硬件工程师。入行第一天,前辈就给我打了预防针,做硬件工程师绝对饿不死,但也吃不饱。入行这些年,换了几家公司,平台都不大,能力上就是独立做公司的产品都没什么问题,应付日常工作也比较得心应手了。 现在也差不多到了自己在这行的天花顶吧(就是天花顶比较矮),但也没有再深入研究的本事了,本质上就是混口饭吃的。想真正学技术做大神的建议去大平台磨炼。 jason说:你好,我已经做硬件6年时间了,越来越感觉到只是做硬件的话,前途的确也比较有限。 硬件比较有优势的是容易转到领导岗位,因为对采购器件,和供应商接触,开发流程比较熟悉。软件通常不关心整个项目的流程,会比较关心如何按照规格书实现功能。所以在这方面做硬件是有优势。 锋兄说:直接一点,你有没有兴趣,如果对这行没有点兴趣和钻研的精神。果断劝退! 想要成为一名有点分量的硬件工程师是不容易的。你可以3个月上手一门编程语言,马上入手工作。但是想硬件入门至少两年,还要看有没有人带你,有没有机会去项目上实操。 唐老鸭说:答案很简单:没有任何前途。 因为绝大多数的职业就其本身都没什么前途而言。 我觉得网友们说的都很有道理,这本来就是一个主观题。 大部分人的工作都是养家糊口的。 你对一个在深圳工作10年、月薪15K的硬件工程师说,你这工作没有前途,工资低,他只会这个,你让他怎么办? 还是那句话,你向往并持续为之付出努力的,那才是前途。 你努力工作为家人创造良好生活条件的,那也是前途,成年人的世界没有容易二字。 共勉。 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2021-01-30 关键词: 硬件 硬件工程师 工程师

  • 工程师必知的哪些元器件失效机理

    元件的失效直接受湿度、温度、电压、机械等因素的影响。 温度导致失效 环境温度是导致元件失效的重要因素。 温度变化对半导体器件的影响:构成双极型半导体器件的基本单元P-N结对温度的变化很敏感,当P-N结反向偏置时,由少数载流子形成的反向漏电流受温度的变化影响,其关系为: 式中:ICQ―――温度T0C时的反向漏电流 ICQR――温度TR℃时的反向漏电流 T-TR――温度变化的绝对值 由上式可以看出,温度每升高10℃,ICQ将增加一倍。这将造成晶体管放大器的工作点发生漂移、晶体管电流放大系数发生变化、特性曲线发生变化,动态范围变小。 温度与允许功耗的关系如下: 式中:PCM―――最大允许功耗 TjM―――最高允许结温 T――――使用环境温度 RT―――热阻 由上式可以看出,温度的升高将使晶体管的最大允许功耗下降。 由于P-N结的正向压降受温度的影响较大,所以用P-N为基本单元构成的双极型半导体逻辑元件(TTL、HTL等集成电路)的电压传输特性和抗干扰度也与温度有密切的关系。当温度升高时,P-N结的正向压降减小,其开门和关门电平都将减小,这就使得元件的低电平抗干扰电压容限随温度的升高而变小;高电平抗干扰电压容限随温度的升高而增大,造成输出电平偏移、波形失真、稳态失调,甚至热击穿。 温度变化对电阻的影响 温度变化对电阻的影响主要是温度升高时,电阻的热噪声增加,阻值偏离标称值,允许耗散概率下降等。比如,RXT系列的碳膜电阻在温度升高到100℃时,允许的耗散概率仅为标称值的20%。 但我们也可以利用电阻的这一特性,比如,有经过特殊设计的一类电阻:PTC(正温度系数热敏电阻)和NTC(负温度系数热敏电阻),它们的阻值受温度的影响很大。 对于PTC,当其温度升高到某一阈值时,其电阻值会急剧增大。利用这一特性,可将其用在电路板的过流保护电路中,当由于某种故障造成通过它的电流增加到其阈值电流后,PTC的温度急剧升高,同时,其电阻值变大,限制通过它的电流,达到对电路的保护。而故障排除后,通过它的电流减小,PTC的温度恢复正常,同时,其电阻值也恢复到其正常值。 对于NTC,它的特点是其电阻值随温度的升高而减小。 温度变化对电容的影响 温度变化将引起电容的到介质损耗变化,从而影响其使用寿命。温度每升高10℃时,电容器的寿命就降低50%,同时还引起阻容时间常数变化,甚至发生因介质损耗过大而热击穿的情况。 此外,温度升高也将使电感线圈、变压器、扼流圈等的绝缘性能下降。 湿度导致失效 湿度过高,当含有酸碱性的灰尘落到电路板上时,将腐蚀元器件的焊点与接线处,造成焊点脱落,接头断裂。 湿度过高也是引起漏电耦合的主要原因。 而湿度过低又容易产生静电,所以环境的湿度应控制在合理的水平。 过高电压导致器件失效 施加在元器件上的电压稳定性是保证元器件正常工作的重要条件。过高的电压会增加元器件的热损耗,甚至造成电击穿。对于电容器而言,其失效率正比于电容电压的5次幂。对于集成电路而言,超过其最大允许电压值的电压将造成器件的直接损坏。 电压击穿是指电子器件都有能承受的最高耐压值,超过该允许值,器件存在失效风险。主动元件和被动元件失效的表现形式稍有差别,但也都有电压允许上限。晶体管元件都有耐压值,超过耐压值会对元件有损伤,比如超过二极管、电容等,电压超过元件的耐压值会导致它们击穿,如果能量很大会导致热击穿,元件会报废。 振动、冲击影响 机械振动与冲击会使一些内部有缺陷的元件加速失效,造成灾难性故障,机械振动还会使焊点、压线点发生松动,导致接触不良;若振动导致导线不应有的碰连,会产生一些意象不到的后果。 可能引起的故障模式,及失效分析。 电气过应力(Electrical Over Stress,EOS)是一种常见的损害电子器件的方式,是元器件常见的损坏原因,其表现方式是过压或者过流产生大量的热能,使元器件内部温度过高从而损坏元器件(大家常说的烧坏),是由电气系统中的脉冲导致的一种常见的损害电子器件的方式。

    时间:2021-01-30 关键词: 元器件 失效机理 工程师

  • 腾讯工程师:如何写好一手好代码

    导读:如何写一手好代码,本文值得大伙一读哦。 作为公司代码委员会 golang 分会的理事,我 Review 了很多代码,看了很多别人的 review 评论。发现不少同学 code review 与写出好代码的水平有待提高。在这里,想分享一下我的一些理念和思路。 谚语曰: 'Talk Is Cheap, Show Me The Code'。 代码,是设计理念落地的地方,是技术的呈现和根本。同学们可以在 review 过程中做到落地沟通,不再是空对空的讨论,可以在实际问题中产生思考的碰撞,互相学习,大家都掌握团队里积累出来最好的实践方式!当然,如果 leader 没时间写代码,仅仅是 review 代码,指出其他同学某些实践方式不好,要给出好的实践的意见,即使没亲手写代码,也是对最佳实践要有很多思考。 我这里先给一个我自己的总结:所谓架构师,就是掌握大量设计理念和原则、落地到各种语言及附带工具链(生态)下的实践方法、垂直行业模型理解,定制系统模型设计和工程实践规范细则。进而控制 30+万行代码项目的开发便利性、可维护性、可测试性、运营质量。 奇技淫巧 领域奠基 理论研究 产品成功 最佳实践 从上面的讨论中,可以看出,我们普通工程师的进化之路,就是不断打磨最佳实践方法论、落地细节。 在讨论什么代码是好代码之前,我们先讨论什么是不好的。计算机是人造的学科,我们自己制造了很多问题,进而去思考解法。 因为最开始协议设计得不好,第一个使用接口的人,没有类似上面这个函数的代码,自己实现了一个嵌入逻辑代码的填写请求结构结构体的代码,一开始,挺好的。但当有第二个人,第三个人干了类似的事情,我们将无法再重构这个协议,必须做到麻烦的向前兼容。而且每个同学,都要理解一遍上面这个协议怎么填,理解有问题,就触发 bug。或者,如果某个错误的理解,普遍存在,我们就得找到所有这些重复的片段,都修改一遍。 但是,A little copying is better than a little dependency。这里提一嘴,不展开。 早期有效的决策不再有效 现在看,这个代码挺好的,长度没超过 80 行,逻辑比价清晰。但是当 isMerge 这里判断逻辑,如果加入更多的逻辑,把局部行数撑到 50 行以上,这个函数,味道就坏了。出现两个问题: 2)代码有问题后,再新加代码的同学,是改还是不改前人写好的代码呢?出 bug 谁来背?这是一个灵魂拷问。 这个大家听了很多了,这里不赘述。 '两种写法都 ok,你随便挑一种吧','我这样也没什么吧',这是我经常听到的话。 // Get 获取IP func (i *IPGetter) Get(cardName string) string {  i.l.RLock()  ip, found := i.m[cardName]  i.l.RUnlock() if found { return ip  }  i.l.Lock() var err error  ip, err = getNetIP(cardName) if err == nil {   i.m[cardName] = ip  }   i.l.Unlock() return ip } 这样的修改,是极有可能发生的,它还是要变成 defer,那,为什么不一开始就是 defer,进入最合理的状态?不一开始就进入最合理的状态,在后续协作中,其他同学很可能犯错! 我是软件工程科班出身。学的第一门编程语言是 c++。教材是这本 。当时自己读完教材,初入程序设计之门,对于里面讲的'封装',惊为天人,多么美妙的设计啊,面向对象,多么智慧的设计啊。但是,这些年来,我看到了大牛'云风'对于'毕业生使用 mysql api 就喜欢搞个 class 封装再用'的嘲讽;看到了各种莫名其妙的 class 定义;体会到了经常要去看一个莫名其妙的继承树,必须要把整个继承树整体读明白才能确认一个细小的逻辑分支;多次体会到了我需要辛苦地压抑住自己的抵触情绪,去细度一个自作聪明的被封装的代码,确认我的 bug。除了 UI 类场景,我认为少用继承、多用组合。 template<class _PKG_TYPE> class CSuperAction : public CSuperActionBase { public: typedef _PKG_TYPE pkg_type; typedef CSuperActionthis_type;     ... } 好,你说是作者没有把 class name 取得好。那,问题是,你能取得好么?一个刚入职的 T1.2 的同学能把 class name、class 树设计得好么?即使是对简单的业务模型,也需要无数次'坏'的对象抽象实践,才能培养出一个具有合格的 class 抽象能力的同学,这对于大型却松散的团队协作,不是破坏性的?已经有了一套继承树,想要添加功能就只能在这个继承树里添加,以前的继承树不再适合新的需求,这个继承树上所有的 class,以及使用它们的地方,你都去改?不,是个正常人都会放弃,开始堆屎山。 根本没有设计 必须形而上的思考 那,技术点要怎么和需求连接起来呢?答案很简单,你需要在时间里总结,总结出一些明确的原则、思维过程。思考怎么去总结,特别像是在思考哲学问题。从一些琐碎的细节中,由具体情况上升到一些原则、公理。同时,大家在接受原则时,不应该是接受和记住原则本身,而应该是结构原则,让这个原则在自己这里重新推理一遍,自己完全掌握这个原则的适用范围。 把工程实践中遇到的问题,从问题类型和解法类型,两个角度去归类,总结出一些有限适用的原则,就从点到了面。把诸多总结出的原则,组合应用到自己的项目代码中,就是把多个面结合起来构建了一套立体的最佳实践的方案。当你这套方案能适应 30w+行代码的项目,超过 30 人的项目,你就架构师入门了!当你这个项目,是多端,多语言,代码量超过 300w 行,参与人数超过 300 人,代码质量依然很高,代码依然在高效地自我迭代,每天消除掉过时的代码,填充高质量的替换旧代码和新生的代码。恭喜你,你已经是一个很高级的架构师了!再进一步,你对某个业务模型有独到或者全面的理解,构建了一套行业第一的解决方案,结合刚才高质量实现的能力,实现了这么一个项目。没啥好说的,你已经是专家工程师了。级别再高,我就不了解了,不在这里讨论。 model 设计 2012 年我刚毕业,我和一个去了广州联通公司的华南理工毕业生聊天。当时他说他工作很不开心,因为工作里不经常写代码,而且认为自己有 ACM 竞赛金牌级的算法熟练度+对 CPP 代码的熟悉,写下一个个指针操作内存,什么程序写不出来,什么事情做不好。当时我觉得,挺有道理,编程工具在手,我什么事情做不了? 上来就是干,能实现上面提到的三个看似简单的需求?想一想,亚马逊、阿里云折腾了多少年,最后才找到了容器+Kubernetes 的大杀器。这里,需要谷歌多少年在 BORG 系统上的实践,提出了优秀的服务编排领域模型。权限领域,有 RBAC、DAC、MAC 等等模型,到了业务,又会有细节的不同。如 Domain Driven Design 说的,没有良好的领域思考和模型抽象,逻辑复杂度就是 n^2 指数级的,你得写多少 ifelse,得思考多少可能的 if 路径,来 cover 所有的不合符预期的情况。你必须要有 Domain 思考探索、model 拆解/抽象/构建的能力。有人问过我,要怎么有效地获得这个能力?这个问题我没能回答,就像是在问我,怎么才能获得 MIT 博士的学术能力?我无法回答。唯一回答就是,进入某个领域,就是首先去看前人的思考,站在前人的肩膀上,再用上自己的通识能力,去进一步思考。至于怎么建立好的通识思考能力,可能得去常青藤读个书吧:)或者,就在工程实践中思考和锻炼自己的这个能力! model 设计,是形而上思考中的一个方面,一个特别重要的方面。接下来,我们来抄袭抄袭 unix 操作系统构建的实践为我们提出的前人实践经验和'公理'总结。在自己的 coding/code review 中,站在巨人的肩膀上去思考。不重复地发现经典力学,而是往相对论挺进。 不懂 Unix 的人注定最终还要重复发明一个撇脚的 Unix。--Henry Spenncer, 1987.11 接下来,我用我的理解,讲解一下几个我们常常做不到的原则。 KISS 原则,大家应该是如雷贯耳了。但是,你真的在遵守?什么是 Simple?简单?golang 语言主要设计者之一的 Rob Pike 说'大道至简',这个'简'和简单是一个意思么? 两张经典的模型图,简单又全面,感受一下,没看懂,可以立即自行 google 学习一下:RBAC: logging: 原则 3 组合原则: 设计时考虑拼接组合 使用组合,其实就是要让你明确清楚自己现在所拥有的是哪个部件。如果部件过于多,其实完成组合最终成品这个步骤,就会有较高的心智负担,每个部件展开来,琳琅满目,眼花缭乱。比如 QT 这个通用 UI 框架,看它的Class 列表,有 1000 多个。如果不用继承树把它组织起来,平铺展开,组合出一个页面,将会变得心智负担高到无法承受。OOP 在'需要无数元素同时展现出来'这种复杂度极高的场景,有效的控制了复杂度 。'那么,古尔丹,代价是什么呢?'代价就是,一开始做出这个自上而下的设计,牵一发而动全身,每次调整都变得异常困难。 这是 golang 标准库里 http request 的定义,它就是 Http 请求所有特性集合出来的结果。其中通用/异变/多种实现的部分,通过 duck interface 抽象,比如 Body io.ReadCloser。你想知道哪些细节,就从组合成 request 的部件入手,要修改,只需要修改对应部件。[这段代码后,对比.NET 的 HTTP 基于 OOP 的抽象] // A Request represents an HTTP request received by a server // or to be sent by a client. // // The field semantics differ slightly between client and server // usage. In addition to the notes on the fields below, see the // documentation for Request.Write and RoundTripper. type Request struct { // Method specifies the HTTP method (GET, POST, PUT, etc.). // For client requests, an empty string means GET. // // Go's HTTP client does not support sending a request with // the CONNECT method. See the documentation on Transport for // details. Method string // URL specifies either the URI being requested (for server // requests) or the URL to access (for client requests). // // For server requests, the URL is parsed from the URI // supplied on the Request-Line as stored in RequestURI. For // most requests, fields other than Path and RawQuery will be // empty. (See RFC 7230, Section 5.3) // // For client requests, the URL's Host specifies the server to // connect to, while the Request's Host field optionally // specifies the Host header value to send in the HTTP // request. URL *url.URL // The protocol version for incoming server requests. // // For client requests, these fields are ignored. The HTTP // client code always uses either HTTP/1.1 or HTTP/2. // See the docs on Transport for details. Proto string // "HTTP/1.0" ProtoMajor int // 1 ProtoMinor int // 0 // Header contains the request header fields either received // by the server or to be sent by the client. // // If a server received a request with header lines, // //Host: example.com //accept-encoding: gzip, deflate //Accept-Language: en-us //fOO: Bar //foo: two // // then // //Header = map[string][]string{ //"Accept-Encoding": {"gzip, deflate"}, //"Accept-Language": {"en-us"}, //"Foo": {"Bar", "two"}, //} // // For incoming requests, the Host header is promoted to the // Request.Host field and removed from the Header map. // // HTTP defines that header names are case-insensitive. The // request parser implements this by using CanonicalHeaderKey, // making the first character and any characters following a // hyphen uppercase and the rest lowercase. // // For client requests, certain headers such as Content-Length // and Connection are automatically written when needed and // values in Header may be ignored. See the documentation // for the Request.Write method. Header Header // Body is the request's body. // // For client requests, a nil body means the request has no // body, such as a GET request. The HTTP Client's Transport // is responsible for calling the Close method. // // For server requests, the Request Body is always non-nil // but will return EOF immediately when no body is present. // The Server will close the request body. The ServeHTTP // Handler does not need to. Body io.ReadCloser // GetBody defines an optional func to return a new copy of // Body. It is used for client requests when a redirect requires // reading the body more than once. Use of GetBody still // requires setting Body. // // For server requests, it is unused. GetBody func() (io.ReadCloser, error) // ContentLength records the length of the associated content. // The value -1 indicates that the length is unknown. // Values >= 0 indicate that the given number of bytes may // be read from Body. // // For client requests, a value of 0 with a non-nil Body is // also treated as unknown. ContentLength int64 // TransferEncoding lists the transfer encodings from outermost to // innermost. An empty list denotes the "identity" encoding. // TransferEncoding can usually be ignored; chunked encoding is // automatically added and removed as necessary when sending and // receiving requests. TransferEncoding []string // Close indicates whether to close the connection after // replying to this request (for servers) or after sending this // request and reading its response (for clients). // // For server requests, the HTTP server handles this automatically // and this field is not needed by Handlers. // // For client requests, setting this field prevents re-use of // TCP connections between requests to the same hosts, as if // Transport.DisableKeepAlives were set. Close bool // For server requests, Host specifies the host on which the // URL is sought. For HTTP/1 (per RFC 7230, section 5.4), this // is either the value of the "Host" header or the host name // given in the URL itself. For HTTP/2, it is the value of the // ":authority" pseudo-header field. // It may be of the form "host:port". For international domain // names, Host may be in Punycode or Unicode form. Use // golang.org/x/net/idna to convert it to either format if // needed. // To prevent DNS rebinding attacks, server Handlers should // validate that the Host header has a value for which the // Handler considers itself authoritative. The included // ServeMux supports patterns registered to particular host // names and thus protects its registered Handlers. // // For client requests, Host optionally overrides the Host // header to send. If empty, the Request.Write method uses // the value of URL.Host. Host may contain an international // domain name. Host string // Form contains the parsed form data, including both the URL // field's query parameters and the PATCH, POST, or PUT form data. // This field is only available after ParseForm is called. // The HTTP client ignores Form and uses Body instead. Form url.Values // PostForm contains the parsed form data from PATCH, POST // or PUT body parameters. // // This field is only available after ParseForm is called. // The HTTP client ignores PostForm and uses Body instead. PostForm url.Values // MultipartForm is the parsed multipart form, including file uploads. // This field is only available after ParseMultipartForm is called. // The HTTP client ignores MultipartForm and uses Body instead. MultipartForm *multipart.Form // Trailer specifies additional headers that are sent after the request // body. // // For server requests, the Trailer map initially contains only the // trailer keys, with nil values. (The client declares which trailers it // will later send.) While the handler is reading from Body, it must // not reference Trailer. After reading from Body returns EOF, Trailer // can be read again and will contain non-nil values, if they were sent // by the client. // // For client requests, Trailer must be initialized to a map containing // the trailer keys to later send. The values may be nil or their final // values. The ContentLength must be 0 or -1, to send a chunked request. // After the HTTP request is sent the map values can be updated while // the request body is read. Once the body returns EOF, the caller must // not mutate Trailer. // // Few HTTP clients, servers, or proxies support HTTP trailers. Trailer Header // RemoteAddr allows HTTP servers and other software to record // the network address that sent the request, usually for // logging. This field is not filled in by ReadRequest and // has no defined format. The HTTP server in this package // sets RemoteAddr to an "IP:port" address before invoking a // handler. // This field is ignored by the HTTP client. RemoteAddr string // RequestURI is the unmodified request-target of the // Request-Line (RFC 7230, Section 3.1.1) as sent by the client // to a server. Usually the URL field should be used instead. // It is an error to set this field in an HTTP client request. RequestURI string // TLS allows HTTP servers and other software to record // information about the TLS connection on which the request // was received. This field is not filled in by ReadRequest. // The HTTP server in this package sets the field for // TLS-enabled connections before invoking a handler; // otherwise it leaves the field nil. // This field is ignored by the HTTP client. TLS *tls.ConnectionState // Cancel is an optional channel whose closure indicates that the client // request should be regarded as canceled. Not all implementations of // RoundTripper may support Cancel. // // For server requests, this field is not applicable. // // Deprecated: Set the Request's context with NewRequestWithContext // instead. If a Request's Cancel field and context are both // set, it is undefined whether Cancel is respected. Cancel <-chan struct{} // Response is the redirect response which caused this request // to be created. This field is only populated during client // redirects. Response *Response // ctx is either the client or server context. It should only // be modified via copying the whole Request using WithContext. // It is unexported to prevent people from using Context wrong // and mutating the contexts held by callers of the same request. ctx context.Context } 说到组合,还有一个关系很紧密的词,叫插件化。大家都用 vscode 用得很开心,它比 visual studio 成功在哪里?如果 vscode 通过添加一堆插件达到 visual studio 具备的能力,那么它将变成另一个和 visual studio 差不多的东西,叫做 vs studio 吧。大家应该发现问题了,我们很多时候其实并不需要 visual studio 的大多数功能,而且希望灵活定制化一些比较小众的能力,用一些小众的插件。甚至,我们希望选择不同实现的同类型插件。这就是组合的力量,各种不同的组合,它简单,却又满足了各种需求,灵活多变,要实现一个插件,不需要事先掌握一个庞大的体系。体现在代码上,也是一样的道理。至少后端开发领域,组合,比 OOP,'香'很多。 可能有些同学会觉得,把程序写得庞大一些才好拿得出手去评 T11、T12。leader 们一看评审方案就容易觉得:很大,很好,很全面。但是,我们真的需要写这么大的程序么? 落地到大家的代码,review 时,就应该最关注核心 struct 定义,构建起一个完备的模型,核心 interface,明确抽象 model 对外部的依赖,明确抽象 model 对外提供的能力。其他代码,就是要用最简单、平平无奇的代码实现模型内部细节。 首先,定义一下,什么是透明性和可显性。 透明性其实相对容易做到的,大家有意识地锻炼一两个月,就能做得很好。可显性就不容易了。有一个现象是,你写的每一个函数都不超过 80 行,每一行我都能看懂,但是你层层调用,很多函数调用,组合起来怎么就实现了某个功能,看两遍,还是看不懂。第三遍可能才能大概看懂。大概看懂了,但太复杂,很难在大脑里构建起你实现这个功能的整体流程。结果就是,阅读者根本做不到对你的代码有好的掌控力。 当然,复杂如 linux 操作系统,office 文档,问题本身就很复杂,拆解、分层、组合得再合理,都难建立心理模型。这个时候,就需要完备的文档了。完备的文档还需要出现在离代码最近的地方,让人'知道这里复杂的逻辑有文档',而不是其实文档,但是阅读者不知道。再看看上面 golang 标准库里的 http.Request,感受到它在可显性上的努力了么?对,就去学它。 设计程序过于标新立异的话,可能会提升别人理解的难度。 你就是要不同、精准: type Point struct {  VerticalOrdinate float64 HorizontalOrdinate float64 } 上面的例子常见,但还不是最小立异原则最想说明的问题。想想一下,一个程序里,你把用'+'这个符号表示数组添加元素,而不是数学'加','result := 1+2' --> 'result = []int{1, 2}'而不是'result=3',那么,你这个标新立异,对程序的破坏性,简直无法想象。"最小立异原则的另一面是避免表象想死而实际却略有不同。这会极端危险,因为表象相似往往导致人们产生错误的假定。所以最好让不同事物有明显区别,而不要看起来几乎一模一样。" -- Henry Spencer。 原则 11 缄默原则: 如果一个程序没什么好说的,就沉默 一个服务一跑起来,就疯狂打日志,请求处理正常也打一堆日志。滚滚而来的日志,把错误日志淹没在里面。错误日志失去了效果,简单地 tail 查看日志,眼花缭乱,看不出任何问题,这不就成了'为了捕获问题'而让自己'根本无法捕获问题'了么? "设计良好的程序将用户的注意力视为有限的宝贵资源,只有在必要时才要求使用。"程序员自己的主力,也是宝贵的资源!只有有必要的时候,日志才跑来提醒程序员'我有问题,来看看',而且,必须要给到足够的信息,让一把讲明白现在发生了什么。而不是程序员还需要很多辅助手段来搞明白到底发生了什么。 原则 12 补救原则: 出现异常时,马上退出并给出足够错误信息 '异常是互联网服务器的常态'。逻辑错误通过 metrics 统计,我们做好告警分析。对于程序错误 ,我们就必须要严格做到在问题最早出现的位置就把必要的信息搜集起来,高调地告知开发和维护者'我出现异常了,请立即修复我!'。可以是直接就没有被捕获的 panic 了。也可以在一个最上层的位置统一做好 recover 机制,但是在 recover 的时候一定要能获得准确异常位置的准确异常信息。不能有中间 catch 机制,catch 之后丢失很多信息再往上传递。 具体实践点 对于代码格式规范,100%严格执行,严重容不得一点沙。 文件绝不能超过 800 行,超过,一定要思考怎么拆文件。工程思维,就在于拆文件的时候积累。 函数对决不能超过 80 行,超过,一定要思考怎么拆函数,思考函数分组,层次。工程思维,就在于拆文件的时候积累。 代码嵌套层次不能超过 4 层,超过了就得改。多想想能不能 early return。工程思维,就在于拆文件的时候积累。 if !needContinue {  doA() return } else {  doB() return } if !needContinue {  doA() return } doB() return 从目录、package、文件、struct、function 一层层下来 ,信息一定不能出现冗余。比如 file.FileProperty 这种定义。只有每个'定语'只出现在一个位置,才为'做好逻辑、定义分组/分层'提供了可能性。 多用多级目录来组织代码所承载的信息,即使某一些中间目录只有一个子目录。 随着代码的扩展,老的代码违反了一些设计原则,应该立即原地局部重构,维持住代码质量不滑坡。比如:拆文件;拆函数;用 Session 来保存一个复杂的流程型函数的所有信息;重新调整目录结构。 基于上一点考虑,我们应该尽量让项目的代码有一定的组织、层次关系。我个人的当前实践是除了特别通用的代码,都放在一个 git 里。特别通用、修改少的代码,逐渐独立出 git,作为子 git 连接到当前项目 git,让 goland 的 Refactor 特性、各种 Refactor 工具能帮助我们快速、安全局部重构。 自己的项目代码,应该有一个内生的层级和逻辑关系。flat 平铺展开是非常不利于代码复用的。怎么复用、怎么组织复用,肯定会变成'人生难题'。T4-T7 的同学根本无力解决这种难题。 如果被 review 的代码虽然简短,但是你看了一眼却发现不咋懂,那就一定有问题。自己看不出来,就找高级别的同学交流。这是你和别 review 代码的同学成长的时刻。 日志要少打。要打日志就要把关键索引信息带上。必要的日志必须打。 有疑问就立即问,不要怕问错。让代码作者给出解释。不要怕问出极低问题。 不要说'建议',提问题,就是刚,你 pk 不过我,就得改! 请积极使用 trpc。总是要和老板站在一起!只有和老板达成的对于代码质量建设的共识,才能在团队里更好地做好代码质量建设。 消灭重复!消灭重复!消灭重复! 最后,我来为'主干开发'多说一句话。道理很简单,只有每次被 review 代码不到 500 行,reviewer 才能快速地看完,而且几乎不会看漏。超过 500 行,reviewer 就不能仔细看,只能大概浏览了。而且,让你调整 500 行代码内的逻辑比调整 3000 行甚至更多的代码,容易很多,降低不仅仅是 6 倍,而是一到两个数量级。有问题,在刚出现的时候就调整了,不会给被 revew 的人带来大的修改负担。 《unix 编程艺术》 佛教禅宗讲'不立文字'(不立文字,教外别传,直指人心,见性成佛),很多道理和感悟是不能用文字传达的,文字的表达能力,不能表达。大家常常因为"自己听说过、知道某个道理"而产生一种安心感,认为"我懂了这个道理",但是自己却不能在实践中做到。知易行难,知道却做不到,在工程实践里,就和'不懂这个道理'没有任何区别了。 所以,大家不仅仅是看看我这篇文章,而是在实践中去不断践行和积累自己的'教外别传'吧。 END 作者:cheaterlin,腾讯 PCG 后台开发工程师 来源:腾讯技术工程 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2021-01-29 关键词: 腾讯 代码 工程师

  • 要不要出去找一份实习?

    -END- | 整理文章为传播相关技术,版权归原作者所有 |

    时间:2021-01-26 关键词: 实习 电子电气工程 工程师

  • 通信人眼里的ABC……

    不管是阅读文档,还是调试设备,都会遇到很多的英文单词和缩写。 今天,作为资深通信老司机的小枣君,就和大家说说——从字母A到字母Z,对于一个通信人来说,到底意味着什么。 A 对小枣君来说,看到A,我第一个想到的,就是AAA,triple-A(triple,英文意思是“三个、三倍”)。 AAA是通信网络中的三个重要功能,分别代表认证(Authentication)、授权(Authorization)和计费(Accounting),重要性不言而喻。 除了AAA,A还经常代表Automatic(自动的),是一个很让人高兴的单词,比Manual(手动)好很多,往往意味着省事、方便。 不过,A有时候也不是一个好兆头,因为它还代表了Alarm(告警)。你在网管界面里会经常看到,看到了就头大。 B 备份是通信日常工作中的重要动作,如果你升级、割接什么的,一定要主要做好备份,不然的话。。。 接下来想到的,就是Base Station(基站),不用说了吧,通信网络的重要组成部分之一。以前2G有BTS(Base Transceiver Station,基站收发台)、BSC(Base Station Controller),3G有NodeB,现在4G LTE有eNodeB(Evolved Node B,演进型Node B),反正都带B。 其它以B为缩写的常用词,包括:Broadband(宽带)、Bearer(承载)、Basic(基本)、Broadcast(广播)、Block(闭塞)、Bit(比特)、Byte(字节)。 首先想到的当然是Cutover。啥意思?“割接”呀! 对于小枣君来说,C最大的含义,就是CDMA这个我为之付出了宝贵青春年华的技术,承载了太多的难忘回忆。以前我们常说C网,就是CDMA网络。 Customer(客户),也是C的一个常见含义。需要注意的是Client,虽然也有顾客的意思,但更多是代表“客户端”。 第一反应就是Data(数据)了吧? 除了Data,就是Digital(数字)。我们已经从模拟(Analog)时代,走入了数字时代,所以Digit也经常看到。 D还有一个重要含义,代表Dynamic(动态的),与之对应的,就是Static(静态的)。描述状态的时候,经常用到这两个词。 E 因为它代表了两个很酷炫的词,分别是Evolution(演进)和Enhancement(增强)。 除了上面两个词外,E开头的还有Extended(可扩展的)和Embedded(嵌入的),也算是比较“褒义”的词,往往代表功能强大。 当然,E也有“贬义”的词,例如Error(错误),要是碰到Emergency(紧急)的,那就更痛苦了,一个头两个大。 F 当然是Fiber,光纤。 和光纤有关的很多概念,都是以F开头。例如FTTH(光纤入户),FC(光纤通道)。 F还代表了Fault(错误)和Failure(失败),是一个运气不太好的字母。通信人不会喜欢看到它。 G 通信网络中,存在大量的网关,通常是起到一个接口和转换的作用。例如MGW(Media Gateway,媒体网关),GGSN(Gateway GPRS Support Node,网关GPRS支持节点)。 例如GSM,就是Global System For Mobile Communications,全球移动通信系统。还有GNSS,全球卫星导航系统。 除了Global之外,就是General了。在通信里,经常是指“总的、大致的、一般的”。例如GPRS(General Packet Radio Service,通用分组无线业务)。 H 除此之外,就是Home了,不是“家庭”啊,通常代表“归属地”。 其它常用词不算多,但都比较重要,包括:Host(主机)、Hardware(硬件)、Handover(切换)、Hybrid(混合的)、Hold(保持)。 又是一个超常用的字母。 以I开头的词,还包括Intelligent(智能),很多新系统都会以I开头,彰显自己的高逼格。还有Interface(接口),也是非常常见。 其它常见的词,包括Industry(工业)、Invitation(邀请)、Inventory(库存)。 J 通信里面很少有词以J开头,好像Juniper这个厂家名用到,然后就是Jumper(跳线器)用到,想不出别的了。JAVA勉强算是一个吧。 这个字母开头的词也不多见,Key也可以算一个,密钥。还有KPI(Key Performance Indicator),关键性能指标,大家比较敏感也比较蛋疼的一个词。 此外,Kilobyte/Kilobit(KB/Kb),也是K开头。 这个算是常见字母了。出现最多的,就是Link(链路)。还有就是Layer(层)。 L的常用词,还包括Low(低),和前面的High对应。还有Local,通常意思是本地,和Remote(远端)对应。 M 我们常说的OMM,就是Operation & Maintenance Module(操作维护模块)。对,Module(模块),也是常见的一个词。 另外就是“Multi-”,这是个前缀,几乎是天天见,意思是“多种的”。例如Multi-service(多业务)、Multi-protocol(多协议)。 N 不过好像除了network之外,N开头的词并不多。National(全国的),Negative(否定),Node(节点)。。。哦,差点忘了,现在很流行的那个NB-IoT,是Narrow Band IoT,窄带物联网。 “non-”作为一个前缀,经常会用到,代表“非”。例如“Non-Real”,非实时。 O 前面说的Fiber,更多是指光纤这个物体。Optical的话,主要是“光学的”。 然后就是ON/OFF了,经常会有衍生词出现,例如online/offline(线上/线下)。Open、Over也经常会出现,还有以它们作为前缀的词,例如overload(过载)。 其它O开头的词还有:Original(初始的)、Orthogonal(正交)、Offset(偏移)。 比较常见的词,尤其是名词比较多,例如Project(项目),Program(程序)、Process(流程)、Precedence(优先级)、Protocol(协议)、Performance(性能)、Product(产品)、Packet(包)、Power(电源)…… Public(公共的)和Private(私有的),也是通信里面常见的单词,例如PSTN,Public Switched Telephone Network,公共电话交换网。 Primary(主要的),也很常见,经常会和Secondary(次要的)一起使用。例如Primary Link(主链路)。 Q开头的词,很快就会想到Quantity(数量)和Quality(质量)。这两个词非常像,小枣君经常会弄错,哈哈。 其它好像不太多,我能想到的,就是Quarter(四分之一)和Queue(查询)。 R Reset,Restart,都是重启,哈哈。 前面说过,Remote代表“远端”的意思,通信里常见的L/R,不是Left/Right,而是Local/Remote,近端/远端。大家要记住了,不要闹笑话。 在通信业务流程里,有两个R很重要,分别是Request和Respone,请求和响应。信令流程里经常会看到,一个网元向另一个网元发送Req消息,然后对方回一个Res消息。有时候收发也会用Send/Receive这对词。 S 脑子里一下子冒出来一堆的词:Service(业务、服务)、System(系统)、Software(软件)、Signal(信号)、Solution(方案)、Source(源)、Standard(标准)、Security(安全)、Supplement(补充)、Silicon(硅)、Session(进程)、Synchronous(同步)、Stand-alone(独立)、Specification(规格)、Status(状态)、Subscriber(用户)、Single(单独的)、Shared(共享的)、Switch(交换机)。。。 T 此外,T还代表了时间(Time),例如Timeslot(时隙)。 其它以T开头的常用词,包括:Tunnel(隧道)、Temporary(临时)、Trunk(中继)、Topology(拓扑)、Terminal(终端)、Traffic(业务量)。 很快想到了User,嗯,用户。例如UA (User Agent,用户代理),User-Defined(用户定义)、User Equipment(用户设备)。 U还有一个“Up”前缀,例如Uplink(上行链路)、Upload(上传),相对应的,是Downlink(下行链路)和Download(下载)。哦,对了,还有一个Update,升级,经常遇到。 V 然后就是Voice(声音),也是常见词,例如VoLTE,VoIP,这里面的V,都是Voice。 其它以V开头的常见词,包括:Video(视频)、Visit(访问)、Vendor(供应商)、Voltage(电压)。 看到W就想到WCDMA了。 除了Wide之外,W开头的词出现频率并不算高,只有Wireless(无线)、Wavelength(波长)、WiMAX(全球微波接入互操作系统)等。 想了半天没想到哪个词是X开头的,Xmanager、Xshell(都是远程控制软件)倒是经常使用。 Y Z 以上就是小枣君眼里的ABC,我相信大家肯定有自己不同的理解,欢迎在留言区补充哟! 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2021-01-14 关键词: 通信 英语 工程师

  • 高速PCB设计中,影响信号质量的5个方面

    在高速PCB设计中,“信号”始终是工程师无法绕开的一个知识点。不管是在设计环节,还是在测试环节,信号质量都值得关注。在本文中,我们主要来了解下影响信号质量的5大问题。   01 过冲   过冲图 02 毛刺   毛刺图 03 边沿   边沿图 04 回冲   回冲图 05 电平   电平图 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2021-01-13 关键词: PCB 信号质量 工程师

  • 学习高速电路设计,工程师需要掌握哪些知识技能?

    高速电路设计,工程师需要掌握哪些知识技能呢?下面以具体的七个技术面,为大家详细叙述一一解答: 数字电路很多时候需要的电流是不连续的,所以对一些高速器件就会产生浪涌电流。如果电源走线很长,则由于浪涌电流的存在进而会导致高频噪声,而此高频噪声会引入到其他信号中去。而在高速电路中必然会存在寄生电感和寄生电阻以及寄生电容,因此该高频噪声最终会耦合到其他电路当中,而由于寄生电感的存在也会导致走线可以承受的最大浪涌电流的能力下降,进而导致有部分压降,有可能会使电路失能。所以在数字器件前面加上旁路电容就显得尤为重要。电容越大,其在传输能量上是受限于传输速率的,所以一般会结合一个大电容和一个小电容一起,来满足全频率范围内。 避免热点产生:信号过孔会在电源层和底层产生voids。所以不合理的放置过孔很有可能会使电源或者地平面某些区域的电流密度增加。而这些电流密度增加的地方我们称之为热点。 所以,我们在设置过孔的时候要极力避免这种情况发生,以免平面被割裂,最终导致EMC的问题产生。通常最好的避免热点的办法就是网状式的放置过孔,如此电流密度均匀,同时平面不会隔离,回流路径就不会过长,也就不会产生EMC的问题。 在布高速信号线时,信号线应尽量避免弯曲。如果不得不弯曲走线,则不要锐角或者直角走线,而是应该用钝角走线。 在布高速信号线时,我们经常通过走蛇形线来实现等长,同样的蛇形线也其实一种走线的弯曲。线宽,间距,以及弯曲方式都应该做合理的选择,间距应满足4W/1.5W规则的。 高速信号线之间如果距离太近,很容易产生串扰。有些时候,因为布局、板框尺寸等原因,导致我们在布高速信号线之间的距离超过了我们的最低要求距离,那我们只能在靠近其瓶颈的地方尽量加大高速信号线之间的距离。其实如果空间足够容许,则尽量加大两高速信号线之间的距离。 长的stub线就相当于一个天线,处理不当会产生很严重的EMC的问题。同时stub线也会造成反射,降低信号的完整度。通常在高速信号线上面添加上拉或者下拉电阻的时候,会最容易产生stub线,而一般处理stub线的将走线可以菊花走线。根据经验可知,如果stub线的长度大于1/10波长就可以当做一个天线了,此时就会成为一个问题。 走线的阻抗值一般取决于其线宽以及该走线与参考平面之间的距离。走线越宽,其阻抗越小。而在一些接口端子也器件的焊盘,其原理同样适用。当一个接口端子的焊盘和一根高速信号线连接时,如果此时焊盘特别大,而高速信号线特别窄,大焊盘则阻抗小,而窄的走线必然是大阻抗,在这种情况下就会出现阻抗不连续,阻抗不连续就会产生信号反射。所以一般为了解决这个问题,都是在接口端子或者器件的大焊盘下面放置一个禁布铜皮,同时在另外一层放置该焊盘的参考平面,进而加大阻抗,使阻抗连续。 过孔是另外一种会产生阻抗不连续的源头。为了最小化这种效应,在内层和过孔连接的不需要的铜皮应该去除。而这样的操作其实可以在设计的时候通过CAD工具来消除或者联系沟通PCB加工产假来消除不需要的铜皮,保证阻抗的连续性。 高速差分信号线我们必须保证等宽、等间距来实现特定的差分阻抗值。所以在布差分信号线的时候尽量保证对称。 在差分线对内禁止布置过孔或者元器件,如果在差分线对内放置了过孔或者器件会产生EMC问题同时也会导致阻抗不连续。 有时候,一些高速差分信号线需要串接耦合电容。该耦合电容同样需要对称布置,同时该耦合电容的封装不能过大,推荐使用0402,0603也可以接受,0805以上的电容或者并排电容最好不要使用。 通常,过孔会产生巨大的阻抗不连续,所以对于高速差分信号线对则尽量减少过孔,如果要使用过孔则对称布置。 在一些高速信号接口,一般如总线等需要考虑其个信号线之间的到达时间以及时滞误差。例如,在一组高速平行总线中的所以数据信号线其到达时间,必须保证在一定的时滞误差以内,从来来保证其建立时间和保持时间的一致性。为了满足这一需求,我们必须要考虑等长。 而高速差分信号线对两信号线必须保证严格的时滞,否则很有可能通讯失败。故为了满足这一要求,可以通过蛇形线来实现等长,进而满足时滞要求。 蛇形线一般应该布置在失长的源头处,而不是远端。在源头处才能保证差分线的正负端的信号在大部分时间内都是同步传输的。 走线弯曲处是产生失长的源头之一。对于走线弯曲处,其实现等长的应靠近弯曲处(<=15mm) 如果有两个走线弯曲,且两者之间的距离<15mm,故此时两者的失长会互相补偿,故此时不用再做等长处理。 对于不同部分的高速差分信号线,应分别独立等长。过孔,串接耦合电容以及接口端子都会是高速差分信号线分成两部分,所以这个时候要特别注意。一定要分别等长。因为很多EDA软件在DRC的时候都只关注整个走线是否失长。

    时间:2021-01-08 关键词: 电路设计 高速电路设计 工程师

  • 30秒预告丨相约2021年第一个24小时

    24小时 24时区 和中兴人一起 共同相约2021年的第一天 相约元旦,一眼看遍全球 中兴通讯的工程师们活跃在世界各地 搭建信息桥梁 筑路数字经济 欧洲 东一区 · 西班牙 东三区 · 俄罗斯 非洲 东二区 · 埃及 东二区 · 南非 零时区 · 摩洛哥 美洲 西六区 · 墨西哥 亚洲 东六区 · 尼泊尔 东六区 · 孟加拉 东八区 · 中国 同样的连接 不同的风景 全球24小时 中兴人全程守护 让沟通与信任无处不在 2021年1月1日 我们的故事 新年上映 敬请期待 本文转载自中兴通讯公众号 我们是一群平均从业年限5+的通信专业工程师。 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-12-31 关键词: 中兴通讯 工程师

  • 在吗?通信小姐姐喊你跳无价之姐啦

    站在2020年的尾巴上 如果问你 这一年 最火爆的音乐是什么? 大部分人的反应一定是 《无价之姐》 听了整整一年 你脑海里是否早已充满了“摇咿摇咿摇”? 你是否已经学会了这无价的舞步? 如果 通信小姐姐喊你 一起跳《无价之姐》 你会来吗? :CF & XMX :KLY 导演&后期 翻唱:CC 关注我们,带你了解通信世界的精彩!

    时间:2020-12-30 关键词: 通信 工程师

首页  上一页  1 2 3 4 5 6 7 8 9 10 下一页 尾页
发布文章

技术子站