程序员是劳动密集型工种

技术很重要,但在实际工作中,可能劳动强度更重要。

我分析我一天的工作内容,可以发现。其实80%的工作内容都是日常的开发或者修改bug。只有20%或更少的时候是有创造性的工作。

为什么会这样?因为一个软件组成的代码太多了,而一个符号用错或者少用一个判断都将带来bug。一是开发逻辑本就需要很多的代码,二是代码一多出bug的机会就多。这许多的问题(逻辑或bug),就会产生大量的工作。时间再多也不够用。所以说是劳动密集型。

另外,一个常用的词语"工匠精神",乔帮主的极简主义、执着、严谨之类的特点,被用以判断一个程序员的优劣。这些精神对细节的要求极高,如果我们推崇它,那么就会极大增加脑力与体力的工作量。而如果不推崇,我们的软件产品质量就会下降。被客户抱怨,这点用得不爽,那点用得不好。所以,我们需要一个平衡。

往往程序员并不能独立处理好这个平衡,因为产品经理或客户对软件的要求是要尽善尽美,但他们不会关心内部细节。好比他们需要的是一位美女,但他们不管化妆,营养,精神状态。而程序员做到这些就需要大量时间,不光把自己搞得很累,还会影响到老板的工期预算。所以最后形成一个共识,优秀的软件是优秀的程序员做出来的,优秀的程序员是短时间内能做出逻辑完善,外观优美,交互流畅的软件的人。换句话说就是多快好省。这里有创造性么?没有。

但有的需求就是要难度较大的技术才能完成,这些是不是有创造性呢?是,也不是。首先,“难“是共认的。大小公司都知道的,有一些大企业有富余程序员、极客程序员,一般都是他们先搞定了这些“难“的技术。程序员都知道BAT公布的开源框架、SAAS服务有多厉害,一般小公司搞不了。

既然是这么累,那是不是干的再多也只是量上的增加,没有质的变化呢?其实并不是,关键在于是否有客观的分析总结。

今天可能我们用的是jsp,明天用struts,后天用的spring mvc。但对于项目来讲解决的问题都是一样的,就是前端与后端的数据交互问题。那么为什么要换工具,除了单位要求的,还有没有客观带来的好处。当然有。新框架配置更少,api更简单,源码也更清晰。如果只从工具使用的角度,那么3年工作经验与10年工作经验差不多。因为工具常用功能就那么多,熟悉程度上差不多。

上面谈了这么多技术问题,再谈谈项目问题,项目的盈利能力。这个问题比技术问题更复杂,一般的技术问题都可通过大量的时间和人来解决。项目的成功却不行。但项目的成功也有一个特点,经过大量的试错才会成功。老板不是傻子,他们希望自己投资的每个项目都能快速成功。但事实是很困难,从技术细节来看,本文开始就说了。另外还有非技术的问题,用户的习惯、心理,国家政策的影响等等。这个话题就聊不完了。所以我们把话题收缩到怎么一个需求基本固定的项目快速完成。

首先是人员的配合,项目经理的跟进协调。其实这里的协调工作是非常多的,基本套路固定后,协调的细节相当的多。协调也与具体的人有关系,经验丰富的对套路规律熟悉,需协调的少点。经验不足的就需技术指导,项目接口的协商。所以对于我们程序员个人来讲,快速完美解决自己的问题,就能把自己的这块东西搞定。光这就够一个人忙活很多天的了。比如,如何快速做好本需求的增删改查。

增加,不是简单的一个添加页面哦,首先怎么到这个增加页面的,一定是与现有数据有关系的。怎么关联,一般是查询现有数据,现有数据是个什么结构?单表,树,网?总能找到一个路径吧,那就来个导航吧。增加的方式也不是一个增加页面,用户更习惯用excel上传。那么excel的模板是怎样?excel对应的数据库的表又是怎样。如果一个excel里有树状结构,怎么验证父结构的那些重复的字段。字段之间有没有约束关系?字段有没有字典范围?null的情况也有多种,没有Cell的,cell里为空的,java里String.valueOf(null)就成了"null"字符串的。

删除,也是有很多的“坑”,逻辑删除字段如何设计,是否要逻辑删?删除后相关联的表的数据是更新还是删除。关联的表咱就只考虑直接关联的吧,间接关联的就太多了。一个表的N个字段,都考虑一遍工作量也不小了。

更新,比删除考虑的更多了。一个商品把图变了,是不是就不是原来的商品了,那原来商品上的规则怎么办?一个题的序号能不能改?

查询,用户/产品说我要的就是这个,怎么来的我不知道。知道它有多麻烦了吧。


文/中中 浏览次数:0次   2020-03-12 13:37:39

相关阅读


评论: