芯学苑专注java培训十年

当前位置  |首页常见问题 帮助中心 一个有着多年编程生涯的程序员总结的经验

一个有着多年编程生涯的程序员总结的经验

来源:西安芯学苑2017-09-20关键词: 程序员 编程经验

  编程的流行趋势是短暂的,但前人们总结出的编程经验值得我们终生学习,在本文中,芯学苑小编给大家分享个有着多年编程生涯的程序员,总结的出来的一些编程经验,希望可以对你的编程有所帮助。

  


  1.可商榷的决定往往是一种权衡。

  伟大的辩论总是发生在开发社区中。无论它是最近关于TDD作为web开发的一种可行方法的辩论,还是什么水平的开发人员应该使用ORM(或micro-ORMs)。无论是.NET MVC应该优于WebForms还是以JavaScript为中心的app应该比基于页面的app更受青睐,其实答案都一样:看你权衡之后的取舍?

  在任何比较两种流行方法的辩论中,我们总是会从自己的立场出发,两利相权取其重,两害相权取其轻。在我的职业生涯早期,我曾执着于追求所谓的正确答案。感觉过程是线性的:摆脱做事的老办法,转而投向新的并且更好的方法的怀抱。曾经有一段时间我深信,编写自己的SQL查询是一种过时的练习,并且ORMs是最后赢家。

  但是,我了解到,更好的办法应该由内容决定的。例如,今天完全成熟的ORMs在隔离映射相关数据网格到对象的冗长管道提供了伟大服务,但隔离也使得某种非标准查询变得困难并且有潜在的效率低下问题。n+1 select problem就是经典的在少写代码和写更多高效代码之间做权衡。我使用ORM的程度完全受我期待应用程序使用的数据量,我所受到的潜在的时间限制,app长期可扩展性需求这三者的影响。。

  2.清晰并不总和简洁相关。

  和大多数工程师一样,我对持续重构一直到代码尽可能地少和简洁的机会垂涎三尺。如果可以选择更少又更简洁的代码来完成同样的任务,那么我为什么要选择要个更多代码的方案呢?通常情况下,更简洁的语言会导致更好的交流。画蛇添足只会阻碍核心信息的提取。但是,最终的目标不应该是简洁——而应该是可交流。于我而言,下面这段直截了当的代码,在它更长的时候……

  if (HasFarm() && HasBoat())

  {

  Broadcast("You are wealthy!");

  }

  else if (HasFarm() && !HasBoat())

  {

  Broadcast("You are OK!");

  }

  else if (!HasFarm() && HasBoat())

  {

  Broadcast("You are OK!");

  }

  else if (!HasFarm() && !HasBoat())

  {

  Broadcast("You are poor!");

  }

  ……反而比这个简洁版本更明确。

  (HasFarm() && HasBoat()) ? Broadcast("You are wealthy!") :

  (HasFarm() "| HasBoat()) ? Broadcast("You are OK!") :

  Broadcast("You are poor!");

  虽然这是一个品味问题(有些人可能会觉得后者看上去更加一目了然),但是我在这里要表述的观点是,有时候解释的最伟大方法并不是简化。这个经验也适用于日常生活,我花了大量时间来思考怎么样才能更好地传达消息以便于对方接收——有时更详细的讲解并非没有价值,而是更明确传达信息的必须。

  3.累计良性债务,并且要持续偿还。

  债务也可以是有益的,如果你能够合理地承担债务,那么之后你也能获得成功。如果借助现在更好的上升空间可以加速你之后的成长,那么债务可以成为一笔巨大的财富。

  代码也是如此。有时它值得你现在承担一点债务——错过抽象或者有一些未优化的SQL代码——如果这样做可以让你更快地发布内容给不断增长的观众的话。关键是要了解你必须偿还它,以及你可以在适当的时间段之后偿还。

  这就是债务在生活和编程中的窍门。偿还债务需要持续进行。将一周10%的时间用于重构,相当于你是在按时支付编码的信用卡账单。如果你保持一种持续、可支撑的还债状态,那么累积债务实际上对你是有好处的。