java每天写业务代码 java每天写业务代码多少次( 四 )


我觉得首先大家要理解什么是“业务代码”,业务代码是一个相对的概念 。
1.对于一个一般的物联网应用型公司来说,业务代码就是根据客户需求基于一个MCU或者MPU的应用控制逻辑的实现 。
2.对于一个做纯上层应用的公司来说,业务代码就是基于一个操作系统为客户量身定制对应的app,并实现对应的应用逻辑 。
3.对于一个微型控制器设计厂商,业务代码就是底层架构裸机的具体实现和各个外设驱动的框架设计 。
4.对于一个设计操作系统的开发人员来说,业务代码就是架构设计、内存管理、调度机制优化、优先级管理、进程间通信机制优化、线程管理和内核完善等等 。
所谓”业务代码”都是相对的,没有参考系怎么谈 。像操作系统,站在操作系统内核提供方的角度看,上层所有的应用框架 , 进程服务,都是业务代码 , 我是为他们服务的 。技术只是工具,业务实现才是目的 , 站在不同供应商的角度,只要涉及代码的地方都可以称之为业务代码 。所以站在这个维度,如果要说业务代码“LOW”,那就没有代码是不"LOW"的了 。
不过,真正接触底层或者实现RTOS底层业务框架的工程师其实是很少的 。大部分工程师基本上都是对于客户需求做一些非驱动底层非操作系统框架的应用型的开发,所以大多时候“业务代码“又单一的被指向了那些只是对客户的上层应用的需求做开发、调整或者迭代的代码 。
而这部分代码究竟"LOW"还是不"LOW"呢,我的答案是:不"LOW" 。但是现实却是很“LOW”,之所以会被想成LOW,是因为:
1.判断一个程序员的优秀程度已经不单单看你写了多少应用型的代码 , 设计了多少应用框架,而是你懂不懂底层驱动逻辑,懂不懂操作系统内核,懂不懂内核裁减等等 。所以这种情况会经常出现在面试过程中,面试官会因为你不懂底层驱动、不懂内核而给你比较低的薪水 。
2.懂得写业务代码的人,他的程序员基础并不一定就牢固 。因为上层应用可能对业务比较看重,但是对于一些特定的语言的编程并没有那么严谨 。能用就可以 , 所以会自然而然的认为这样的程序员“LOW” 。而一个会写底层驱动的人,他考虑更多的是基础代码的安全、严谨性和容量问题等等,他们的语言基础相对来说要牢固很多 。
3.技术负责人一般都是全能型的人 。会写底层驱动或者更懂操作系统内核的人更容易成为技术的领头人 。而那些只会“业务代码”的人 , 放在大部分公司,一般都不会有太多的上升空间 。
根据以上分析过后呢,做“业务代码”的程序员基本上会被想的很“LOW”,但是结合我的亲身经历,不同的人对于这个事情却会有不同的看法 。
比如对于领导来说,那就不一样了 。你将“业务代码”的需求迭代了,完善了 , 提前任务完成了,客户很满意 。那领导不会认为你是一个很“LOW”的程序员 。你很高级,领导很欣赏 , “后果”很舒服 。但是对于一个面试官来说,你就会点上层应用的调用和设计 。我为什么要给你这么多薪水?虽然会被想成很"LOW" , 但是也是现实 。
业务代码不一定low,能完成用户需求的代码就是好代码 。
另外,对于我们搞嵌入式软件、EDA工具软件的来说,业务软件反而是更有技术含量的,更具科学意义的代码 , 而软件可能只是载体,你啥时候透过代码理解了它们背后的物理概念、数学公式,你就超越了程序员,能向科学家又迈进一步 。
互联网软件其实也一样,软件实现的是一个业务流程的自动化,你完全可以透过你写的程序还原甲方用户的业务流程,而这种流程是老板制订的 , 认识会上一个层次,将来可以向老板迈进

推荐阅读