要知道一个普通的系统研发的代码量就至少是十几万行起步,有的是百万行起步。并不是说一个系统代码里越大越好,而是越精越小而美越好;耦合低,功能强,逻辑清晰,算法优越;
我亲眼见过一个同行的朋友,不知道为什么凑什么业绩还是为了完成什么指标的,一个简单的方法调研,硬是在一个页面里面嵌套递归了十来层if\eles语句…你说他能力不行吧,他写10多层的嵌套还能泰然自若,一点不乱,照常运行,你说他能力可以把,他不知道加一个return AnyMethod();直接调个public方法就可以完事的…
所以解释就一个,就是为了摸鱼吧…
抛开个别偷懒的程序员不谈,我们讲一个项目的项目中,现实是有接近7成的工作是重复性的,轻意义的;如数据层编写、业务层的基础逻辑,包含增删改查一系列基础性的模块开发,这些工作,是一定要有的,但重复性巨大,工程师们不得不把相当一部分的时间耗费在这里,这也就是为什么总有人说IT民工,搬砖之类的话,因为有些工作就是在搬砖无疑;
你看着高大上,屏幕上全是英文符合,其实真正涉及到业务逻辑处理的语句占比并不是最高的;
一个事实是:一个性化的业务系统开发中,实际上能有一小半创新化的工作量就不错了;
程序思维的一个重要特征就是理应尽可能的避免掉这些重复性工作,而为什么至今大部分的软件公司还是无法绕靠这个工作,这很值得深思;
那么问题就来了,既然一个项目中一大半的实际工作量是不要求高技术水平的,只要求搬砖,那么何必要让高薪的程序员去浪费时间在这上面呢?
让程序员多干动脑子的工作才是正解。程序员也乐意这样,搞程序的人如果会喜欢这些重复性的工作的话,那么只能说这些程序员算不上合格吧,因为程序存在的目的就是为了帮助人工提高效率,减少工作量而存在的;
让水平高的程序员去做核心的逻辑,用最顶尖的技术水平去实现那一小撮真正个性化的核心逻辑;其他轻意义的周边工作交给水平一般的员工,才是正解。
那么有没有一种解决办法是,可以提供给高水平程序员和普通业务人员同时协作开发的一种平台或工具呢?
相关内容
最新内容