专栏首页Java学习网17年编程生涯的三大经验总结

17年编程生涯的三大经验总结

17年编程生涯的三大经验总结

今年将迎来我编程的第十七个年头。我的编程之旅始于九十年代末,上大学的时候,主要涉足基于表格的网页设计,传统的ASP,和Microsoft Access数据库。原来只是当作业余爱好的编程现在已经成为了我的事业和激情。我一生一半的时间都在学习、蹒跚、成功、失败,并且经常情不自禁地为代码美丽和复杂的天性而折腰。

我在代码上淫浸了足够长的时间,因此看到了很多语言和平台的兴盛和消亡,看到了很多模式被普及,被苛责,然后再次被推广。在某些时候,我常常分不清这是大势所趋还是明日黄花。

编程的流行趋势是短暂的,但我坚守的规则,往往在生活中的其他地方也能发挥作用。事实上,生活就像代码(我已经买了这个域名来证明这一点!)。以下是我总结的3个伟大的经验教训,历经一次又一次编程和生活的大浪淘沙。

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

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

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

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

我已经将这个经验应用到了我生活的其他方面。我是应该买一套公寓还是长租房子?我是应该启动自己的生意还是工作于已经成立的公司?没有绝对正确的选择。当你权衡利弊了之后,你便可以更好地应对生活中的各种难题。

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!");

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

举例来说,我想要更明确和更详细地告诉我爸爸应该如何关闭iPad(“按住右侧的按钮一段时间……”)。或者,我看似多此一举地键入了一些我已经提交到本地分支的内容给我的同事(“刚刚犯的错误已被修复”),然后当它涉及到部署更新到产品中时,我就能很明确地知道哪些具体的提交被合并和出现(“检查4812-4822行,其中包括在6/15发行版本中的DoneDone问题,将在今晚的产品发布中提出来。”)。

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

我在一个特别害怕欠债的家庭中长大。八十年代中期,我的父母倾其所有又东拼西凑,付了他们第一套房子75%的首付,然后在七年内付清了剩余款项。用现金支付是常态。信用支付在他们看来几乎是一种罪过。作为一个孩子,我的看法是,债务完全是坏的。我从不认为欠债是一种优势。

直到我看到其他人是如何对待债务的——在我20出头的时候——我终于知道了债务也可以是有益的。如果你能够合理地承担债务,那么之后你也能获得成功。如果借助现在更好的上升空间可以加速你之后的成长,那么债务可以成为一笔巨大的财富。

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

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

本文分享自微信公众号 - Java学习网(javalearns)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-05-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 模式分解是否为无损连接的判断方法

    方法一:无损连接定理 关系模式R(U,F)的一个分解,ρ={R1<U1,F1>,R2<U2,F2>}具有无损连接的充分必要条件是: U1∩U2→U1-U2 €F...

    用户1215536
  • 分解成3NF的保持函数依赖的分解算法:

    转换成3NF的保持函数依赖的分解算法: ρ={R1<U1,F1>,R2<U2,F2>,...,Rk<Uk,Fk>}是关系模式R<U,F>的一个分解,U={A1,...

    用户1215536
  • SQL中查询优化的主要策略

    为了能提高查询效率按优先级主要有一下策略: 1、尽可能早的执行选择操作(最基本的一条) 2、把笛卡尔积和随后的选择操作合并成F连接运算 3、同时计算一连串的选择...

    用户1215536
  • 奇怪的Hibernate——当?遇上%

    今天写了一个模糊查询的SQL语句,发现了点有趣的东东 情景: 平时写模糊查询的时候是”select * from user where username l...

    用户1174983
  • 数据库的规范化

    一、基础概念 实体:现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等。 属性:教科书上解释为:“实体所具有的某一特性”,由此可见...

    用户1215536
  • openfire中mysql的前期设置

    使用openfire的时候如果需要使用自己的mysql数据库,需要提前进行设置,下面将记录下,基本的设置过程。 一、前期准备工作: 1、先下载两个工具一个是my...

    用户1215536
  • 当子查询碰上NULLUNIONJOIN总结

    情景: 现在有如图两个表,boy和girl,对应着Boy和Girl两个bean,有共同字段id、name,另外boy还有个外键grilfriend(指向girl...

    用户1174983
  • 函数依赖集闭包、属性集闭包、超键、候选键和最小函数依赖集的求法。

    函数依赖集的闭包 F:FD的集合称为函数依赖集。 F闭包:由F中的所有FD可以推导出所有FD的集合,记为F+。 例1,对于关系模式R(ABC),F={A→B,B...

    用户1215536
  • ER模型到关系模型的转换规则

    E-R模型向关系模型的转换规则: 一、两元联系的转换规则 (1)实体类型的转换  将每个实体类型转换成一个关系模式,实体的属性即为关系的属性,实体标识符即为关系...

    用户1215536
  • SQL连接查询(最全面)

    连接查询是关系数据库中最主要的查询,主要包括内连接、外连接和交叉连接等。通过连接运算符可以实现多个表查询。 在关系数据库管理系统中,表建立时各数据之间...

    Steve Wang

扫码关注云+社区

领取腾讯云代金券