程序员和码农的区别(码农就是码农)

前两天其他问答平台推荐给我了一个问题: 一个Java学生的自述,很迷茫,这样的现在我该怎么办呢? 看完,想起这两天一直在想的问题,就想把原来一些想法综合起来写一篇文章。 先说我看到的...

前两天其他问答平台推荐给我了一个问题:

一个Java学生的自述,很迷茫,这样的现在我该怎么办呢?

码农就是码农,程序员就是程序员

看完,想起这两天一直在想的问题,就想把原来一些想法综合起来写一篇文章。

先说我看到的一些现状:

大量学校在教授计算机专业,从清华、北大、985、211到大专、函授、青鸟培训。市面上出现大量IT公司,每个城市都需要IT公司支持智慧小区、健康码到智慧城市、智能政务等本地化服务。新一线城市IT公司大量出现,原来是北上广深程序员支持全国IT建设,现在是新一线崛起,省会城市携综合本地公司支撑全省。

总的来说,写程序这个行业,你发现越来越普通化了,他变成了日常生活中经常看的见的普通职业,原来一个程序员可能是白领,现在可以明确的说,就是一个蓝领了(大厂除外)。

码农就是码农,程序员就是程序员

这很好,说明我们社会越来越现代化,需要更多的IT支撑,但从行业内部来看,我觉得却有些与时代发展脱节。

比如我问一个问题,你们的架构办或者CTO、架构师,向你们交付什么文档?

详细设计?ERD图?或者干脆就是一个脑图,一次项目讲解说明?或者干脆就让设计出图,开发自己评估?

大多数公司,我估计真正负责架构或者整体设计的大佬们,其实交付的应该都逃不出这些东西吧?

这说明一个什么问题,软件行业的管理,其实是指导形式的,中高层对下层工作人员所能起到的主体作用是指导你如何工作,而不是参与工作的过程。

换句话说,其实软件行业还是学徒制,传统作坊一贯的做法。

码农就是码农,程序员就是程序员

前几年的时候,作为一家创业小公司的CTO,也这么做,我觉得这样做很合理啊,我教授你做工作,你学习并做好就好了。

直到我发现这样做似乎完全不起作用。

因为招聘的程序员,基本只接受了学校的普通IT教育(Java程序、数据结构等让大学生学起来一头雾水的教程),然后去了一个培训机构学了几天Spring框架,对我所提到的概念完全不能理解。

讲个例子,有一次客户说管理员里要设置一个超级管理员,把我们的经理设置成权限高点,我就说小王(程序员),客户说一个管理员层级不够,需要设计多级管理员,包括管理员和超级管理员两类,然后把xxx的权限设置成超级管理员,然后我的程序员就在程序里写了如下代码:

if (admin.Id == 43) { admin.Role = "super"}

我说这个43是什么啊,他说就是他们老大的系统ID啊。

我很无语,我严厉地批评了他,他也很委屈,从项目的角度看,他确实达到了这样的现实目的,他认为没有什么不妥,但是我觉得,我清楚的表达了几个层面的事情:1)设计多级管理员,包括管理员和超级管理员两类;2)把xxx的权限设置成超级管理员,你怎么能简单的简化成这样,导致这个逻辑没有扩展性,无法重复部署呢。

这个示例有点极端,但是普遍这种情况在大多数研发,特别是外包项目研发的时候存在。

从第二年起,我就开始认识到,简单的教育不行,我必须要更加清楚地表达一些具有固定含义的要求,包括:

1)写大量的文档,任何指导工作都写成指南,写过的包括1)java设计要求,2)后台设计要求,3)数据库设计要求,举个例子:

不使用0,或者“”、false等默认值作为正常情况

例如一个数据有status字段,表明其可以使用或不可以,则比如使用非默认值作为正常情况,例如1,“true”,true等,以避免因默认值导致流程在没有指定该数值的情况下被认为是合理流程。

这个要求不仅公司要求,客户也经常性会要求

码农就是码农,程序员就是程序员

程序中使用0作为正常值是古老的c语言程序遗留下来的老毛病,当时,常常使用0作为正常,而使用负数作为系统异常,而正数通常拿来表示业务分支,这是因为c的语言模式造成的,任何我公司的正常代码不应该再应用这种逻辑。

2)我开始在程序中,明确的以注释形式要求哪些代码哪些人可以改,哪些人不能改,以及改了之后的后果:

// 这是底层区块链的调用函数,在任何情况都不得注释,发现一次,处罚一次recorder.AddRecord(GetOwner(info1.getSfz(), "2"), LocalService.getKabaoCallerid(), s.getDataid(), GetNowTime(), output.get("code").toString());

以此为起始,其实就引出了我今天的观点:

以后的程序员会明确的分成程序员和码农两类,程序员将类似工厂中的技术员,出图纸,码农就相当于工厂的工人,只负责按图纸填充具体逻辑代码。

现有的架构办体制不再适用,架构办扩编成技术部,产出物从设计说明扩展为某种智能文档,可扩展为代码,可进行复核,可进行协作。

其他研发人员归集为开发部,负责填充细节代码,人员要求进一步降低,很可能灵活用工平台会占据大部分人员供给,随派随用。

有人可能觉得我要不就是危言耸听,其实很多国企早就这么做了,自己只招核心员工,大量的都是外派公司派来驻场的人。只不过协作界面现在的智能化和自动化程序还做不到像工厂图纸那样标准化。

这既是行业发展的必然,也是行业发展的需要,我也不想把自己的行业说的跟落后产能似的,但是未来可能他还真就这样。

  • 发表于 2022-10-29 23:34:58
  • 阅读 ( 191 )
  • 分类:科技

0 条评论

请先 登录 后评论
小女同学
小女同学

462 篇文章

你可能感兴趣的文章

相关问题