认识达内从这里开始

认真做教育专心促就业

毁灭程序员的15个障碍（上）

发布：互联网
来源：互联网
时间：2017-05-26 15:51

会议,什么都不懂的经理,生产效率指标--这就是你和下一个伟大软件之间的天堑.

潍坊达内培训

    昨天必须得发布产品.用户争闹和咆哮某个缺失的功能.老板的老板说,我们最好迅速行动起来否则就炒我们的鱿鱼.感觉一切都有心无力.

    没有人满意开发人员这种已经"竭尽全力"改变世界的速度,每个人都希望代码像消防水管里的水一样能够源源不断地流出来,但没有人愿意提供给开发人员更好地完成工作的条件.正如那个想要我们昨天就完成工作的老板,他不愿意雇佣更多的人,不愿意购买速度更快的机器,也不愿意做任何其他可以让程序员专注于编程的事情,又想马儿跑,又不给马儿吃草.

    潍坊达内培训就来说说现实世界中的15个编程障碍.

编程效率障碍No.1:会议

最常见的抱怨是打断开发人员编码思绪的会议.如果老板信任该程序员,就会要求他们时不时地去那间数周甚至数年昏昏暗暗的会议室闲聊有关细节.尽管程序员通常归咎于是管理人员毁了会议,但他们偶尔也会指责其他的程序员老是跑过来询问有关或bug或功能或架构策略的问题.

虽然有些抱怨是愚蠢的--但程序员依然会埋怨,如果老板让他们自己在黑暗中摸索,没有一点沟通--任他们自己在软件的抽象世界里埋头苦干,自己去面对各种困境.快餐厨师和咖啡调配师或许还能够兼顾不同的需求,但如果是切换大脑到正确的模式来操作抽象算法则通常需要时间.从会议模式中切换回编码模式,可能会浪费一个小时左右的工作时间.

编程效率障碍No.2:答复所有的电子邮件

如果说会议很糟糕,那么这一种可能更糟糕:需要查看发来的无穷无尽的邮件.回复邮件需要时间,而且没人会对回复结果表示满意.然后那些最不耐烦的开发人员或许会选择简单的回复--"tl;dr"(即too long,didn't read.篇幅过长,没有阅读).

有的团队试图开设每周一天的禁邮日.还有的团队就完全不用邮件.虽然解决了邮件过载的问题,但却是以沟通为代价的.要是突然不在一起工作.这还能算是好办法吗?

编程效率障碍No.3:试图衡量生产力

    总会有管理团队受那些所谓"你不能管理你无法衡量的东西"的书籍启发,于是开始衡量提交的或代码库或软件代码行或bug修复.他们认为,计数就是衡量,而且衡量一定是好事.

    但是程序员并不是砌砖工,不能数数砌了多少砖就知道其效率.相反,为了写出更好的代码,程序员需要或专注于编写的代码行,或解决bug,或提交到代码仓库,或做一些无法计数的事情.如果bug修复可以加分,那么一些微小bug的报告就会激增,bug修复也会如此.有人因为报告bug得到了奖励,然后另一个人因为修复它也能得到奖励.或者,如果是计数代码行数,那么那些可以用10行代码解决问题的程序员,可能就会转而表示5000行的代码将更灵活或功能更兼容--任何可以添加到5000行中的都加进去.潍坊达内培训采用TTS教学辅助系统提供全面的教学保障.

    衡量效率实际上会因为鼓励功能丰富,代码过度设计的长文件,而让代码库变得更糟.

    对于此问题还没有真正的解决方法.我们需要跟踪bug.我们需要组织工作流程,协调软件的创建.这种优雅是无法衡量的.

编程效率障碍No.4:妄自尊大的开发人员

    对于程序员而言,有这样一个同事比Boss更难以忍受:创建了代码的最后一次迭代,却不再工作于这个项目.正如每个房屋装修承包商会贬低上一个木匠的技能,每个程序员也会快速指出可怕的,不可原谅的,完全是死脑筋的上一代的行为.

    当然,这可能是事实,但它很少像程序员说得那么糟糕.如果有什么区别的话,问题通常也不是由于技能匮乏而引起的.主要还是风格的不同,并且风格还会随着时间而改变.上一代和我们今天访问的库不同.他们也不曾阅读过有关最佳做法的最新着作.

    妄自尊大的编程态度往往会减缓项目.骄傲和利己主义的混合发酵会导致程序员抛弃完全能够胜任的代码,只为了按照他们认为的"正确方式"重建.

编程效率障碍No.5:"以后修复"的思维定式,又名"技术债"

我们总感觉不够时间在项目中按计划构建我们想要构建的东西.于是,我们偷工减料,给代码打补丁,缠满了虚拟胶带.曾有明智的经理将此称为是"技术债",因为"债"是以后必须要还的.即使他们不理解代码,也知道"债"的含义.

每个项目都有一定的技术债务.有时它会快速见效,但通常直到下一代才会发现这已经成为了一个坑.他们需要构建上一代没有做到的东西.就像滚雪球一样,越滚越大.

编程效率障碍No.6:非程序员经理

总会有那些面带微笑,西装笔挺,却不是主修计算机科学,也不懂编程项目的家伙成为了经理.也许他们娶了老板的女儿;也许他们正好在"正确"的时间出现在了"正确"的地方.但是,老板让他们担任了经理,即使他们一窍不通.更糟的是,他们会用外行人的眼光来看待问题,哪怕不伦不类,文不对题.

有一些程序员表示很欢迎这样的经理,因为愚弄他们很容易.而且他们还承担了来自于更高管理层的炮火.但也有人承认,这些人只会不断地开会,只会妨碍编程.他们几乎给不了任何有用的指导,他们可以提供的只是那么一点质量检测.

编程效率障碍No.7:程序员经理

虽然程序员可能会因为不得不与非程序员经理打交道而抱怨,但他们经常悄悄地表示,编程人员去做管理人员更糟糕--有时甚至更糟糕得多.

他们是前任的天才,可能会决定微观管理项目,然后果决地撕裂大片的代码,因为他们有了一个新的展望.或者,也许他们会闲谈,对于同样的事情,他们是如何用8080汇编或C或Java编程写了一半的代码.在任何情况下,他们更痴迷于技术细节而不是大局,虽然他们被雇来的目的是盯牢后者.

更多潍坊达内培训相关资讯,请扫描下方二维码

潍坊达内培训