程序员工作技能集合思考录

  首先，为什么要找工作用到的技能集合。主要是找找自己的，大概会哪些技能，哪里可以提升。这样对别人来说或许没太多参考性，或许还有一些通用的部分。

  需求市场不好抽象出来，除了编程的部分，还有企业发展遇到的风雨阻隔。不管是环境给的还是人自己给的，这些阻隔比技能缺陷来的猛烈。首先找稳定的需求市场就不好找。

  纺织业，制造业。农业没有太多的电子化，或许也适合电子化一些，比如方田进入电子统计直接面向产出的购买者。哪里多少地，里边有多好蔬菜果实或粮食要熟了，想买一种蔬果粮最近哪些地有产出，哪些地主人愿意朝外售卖。这种不好起步，不好和人沟通。市场和农户的连接算是。连接之后可以捎带着一些过程辅助。

   一些传统制造业的话，造衣服鞋子等。都有很成熟的程序。小工厂的话加不加数字中台来总览生产似乎并不是很重要，大工厂需要怎样的数字中台不清楚。更多这些企业考虑的可能是销路，或者多少钱换台设备。数字中台不是很重要，很多账面都可以人工做而且有许多通用的软件。就像买一些机器一样引入这些软件，像不会改装机器一样不怎么改装成熟化的软件。也就是定制化的应用范围很小，大部分普通人不熟悉这个领域，那些工厂老板也是。

  科技技术色彩比较多的制造业，就更多偏向 模板化的软件需求。像引进先进设备一样，有一套固定的高审核的引进规则来引进数字中台软件。就像他们不会自己造设备一样，基本不会考虑自己做软件。软件的流程和设备的流程是相互协调的，成熟的设备带来成熟的流程需 更倾向于成熟的软件。于是需要在已有软件上，学习它们本来的规则做一些二次开发。二次开发能抵达的距离不会太远，基底的固定性在那里。基底的开发，涉及到的人就少了。

  物联网也会需要程序员。相比企业内部数字中台的话，人就少了。看招聘职位大多都是一些企业内部的业务运转，像是需要有相关业务知识。大部分岗位都在写需要哪些技能，没有说这个岗位在完成哪些业务。在说你来到会干什么就行，没有告诉你我们在做什么。上下级对待，无责工作。现在找工作一般找平等对待和共同承担。

  用Java做开发，要懂SpringBoot。和一些主流框架。我自从学了java就没用过，也没用过那些框架，不是很清楚那些框架怎么运作。最开始有份php工作就不需要太多知道框架的东西，语言本身算是一个简化很多操作的框架。后来接触到C#，除了一些基本框架结构，全部都是手写。显得比较原始和简单。中间有框架的部分，仓储层和service层自动调用接口，还有数据连接层接口自动调用注册的实现，依然都是黑盒子。可是没有太在意这些黑盒子，因为影响性能的都是自己的代码和业务逻辑。大概用框架的时候就不需要先考虑框架的开销了，因为抵达不到那个境地。站在工作的角度来讲， 会用就可以；站在学习的角度，整理项目运行逻辑的角度，又容易需要去学很多。

  编程语言之外还有数据库，还有前端。这两个都不想过多了解，只接触过vue知道怎么用。接触过对数据库的笼统介绍和多表查询的算法选择会走贪吃算法。数据库底层的存储优化，页优化，搜索逻辑优化，很少去涉及。接触的业务少，顶多优化查询语句，优化表结构和多表链接方式，对数据库底层优化基本不接触。就像使用vue只知道怎么用，至于vue本身的运行效率，不怎么好考究。

  编程语言有很多，c++给人的印象是覆盖了最多的功能集。每个语言都有自己的特色，像go主张程序间通讯而不是共享变量来避免并发访问。通讯就有发送消息和接受消息，用传递的方式共享数据。总感觉需要顺序和等待，如果不是涉及到避免共享变量的部分就不需要设计这些围绕。Java因为回收会有卡顿的原因，不适合快速反应的程序，比如游戏类。c++虽然会有碎片，可以自行设计内存池来装已知固定大小的开销，于是可以避免碎片。C#基于微软的iis还有vs等生态，可以很方便开发。

 语言本身之外，还有很多框架，这些框架都有一些通用逻辑。和框架交互的，就有一些别的工具。如redis，消息队列，分布式，容器管理。还有版本控制。

 框架本身有一些通用性。都是为了快速搭建通用项目，并且做成一定扩展，方便开发过程同时方便程序拓展。一般都是网页模式。ui模式的话我没太多接触，一些功能软件会更多偏向界面窗口的程序。至于客户端服务器端的软件，用网页还是自定义用户界面，面对的问题应该差不多。用户界面少了http，显得更安全和私有一些。

  开始都是web容器。IIS或者其他。它们做一些统一的基本作用。nginx也属于容器端的内容。这些知道大概配置和处理过程就可以了。就像是框架一样，很少会影响到程序性能。学的话却是很卡顿的，因为好像实际工作会很少用到里边的内容，他和动手操作之间的距离太远。知道原理的话会显得容易调整，知道原理的代价却比较大。还是需要知道和了解基础部分，不是为了能做调整，而是理解整个程序运行。

  服务端程序部分，大多都是注册的接口。最根本就是这样做来灵活分离实现。service和DAO都是这样做。框架提供了许多辅助实现。写程序的时候需要知道一些框架配置出现的问题，比如maven镜像等繁琐的问题。

  剩下的就是写代码，写数据库，写页面逻辑。没有太多可说的内容，都是根据具体业务自己做实现。这也是最核心的部分，工作的实际内容。都是在框架内生存。

  至于灵活选择框架或者灵活选择语言。没有这种事。大都是有一些成熟的方案，在临近的业务领域接触成熟的方案并且知道可行，然后拿来结合。没有灵活这一说，只有赶巧知道。如果没有实际经验做的判断支撑，迁移向新框架成本不可估量。我们的迁越只有经验通道里的迁越，没有“经过思考、理解然后做出选择迁入一个之前陌生的环境”。这也是 “迁越”本来的样子。

  除了写程序，还有网络，电脑组装，周边硬件如打印机等。好像程序员会被认为知道其实没有必要关联性的内容。当然还是需要去了解一些，只为了能安全写程序，出现一些相关故障能自己评估。

  当进入到框架里写程序，用自己的才智完成业务实现工作，里边有很多可以提升的部分。很少能找到这里边的探讨，能找到的都是一些语言功能的基础普及，进入工作的程序员需要的不是这些。里边有最多的内容，却没有什么好讲的。程序员的能力千差万别。