我在编程20年中学到的5件事 - DaedTech


在过去的4-5年中,对程序员的需求增长如此之快,以至于程序员的数量总是每五年翻一番。结果,拥有5年经验的程序员所拥有的行业任职时间比整个行业的一半还多。
我现在在这个行业中已经推进了20年。我花了大约10个角色担任我的主要职能是编写代码。其他10个项目涉及管理程序员,指导他们,就如何管理它们向组织提供咨询,运行代码库评估实践以及如今的内容营销。但是在所有这些角色中,我都不同程度地编写了代码。以下是我认为是20年编程生涯中最重要的教训和收获。

1. 重复是最糟糕的
“避免复制粘贴编程!”,这是可怕而草率的做法。
想象一下,您有一个可以完美使用的CalculateBill()方法,但是产品经理徘徊并说:“我们在墨西哥招募了新客户,您在那儿计算的帐单有所不同。”因此,您复制当前方法,将其粘贴,将其重命名为CalculateBillMexico()并根据需要进行调整。
下面是这种方法的问题:

  1. 如果将来的更改需要调整核心逻辑,那么您现在必须做更多的工作并修改2种方法。
  2. 现在,您有2次机会在此类更改期间引入错误。
  3. 现在,您已经建立了一个“设计模式”,并且随着全球扩张的继续,您的代码正在乞求一种新的冗余方法。
  4. 随着工作的进行,您的劳动量将急剧增加。
  5. 通过忘记在任何需要的地方进行更改来引入错误只是时间问题。
  6. 最终,所有这些方法都将有足够的不同,以致您无法再将它们合理地合并回去并解决问题,但相差无几,您可以避免每次有人更新计费规则时进行20次更改。

系统中的知识重复可以多种方式发生,而简单的复制粘贴只是最明显和最晦涩的。还有重复知识的其他示例:
  • 一个for循环和一个代码注释就在其上方,解释了开始,结束和增量。
  • 全局变量向内联分配了一个值,然后(也许)从配置文件中重新分配了一个值。
  • 具有“ PretaxTotal”,“ Tax”和“ Total”列的数据库表
  • 范围广泛的ERP系统,将客户存储在CRM模块中,然后再存储在计费模块中。

最好的情况就是您已经有了适当的流程和系统来认真地跟踪重复并确保同时更新。
当您开始构建复杂的逻辑(然后必须进行维护-请参阅下一节)以确保同步时,会发生更糟的情况。

2.代码是责任
少即是多,实际上,我已经担任了多年非常专业的管理顾问。我进行数据驱动的代码库评估,并帮助IT领导者制定有关代码库的战略决策。因此,我可以查看,分析和收集大量代码库的统计信息。
关于代码库的几乎所有不良之处都与代码库的大小有着显着的关系,以逻辑代码行来衡量。
我喜欢编写,研究,分析和使用它来构建事物。但是请不要误会-这是一个巨大的责任。始终努力使用尽可能少的代码来完成所有工作。

3. 高级开发人员:信任但要验证
我的意思是警告您,有多少高级开发人员表面上看起来很牛,但实际上并非如此。
因此,当您是新手时,请给前辈带来疑问的好处并顺应他们,但不要仅仅假设他们告诉您的是对还是对。自行验证(最好不要在它们前面)。

4.  TDD是有效的,但是带来维护成本
大约10年前,我对TDD持怀疑态度。我决定写一篇关于TDD为什么不是那么出色的博客文章。

5.证据为王
代码审查或团队或组织内的任何其他形式的协作过程中,如果您想就任何事情向管理层或领导层提出任何理由,证据就是您的朋友。
证据将赢得您的论点,尊重,领导角色和职业发展。
我的意思是在代码库中查找有无全局状态的模块,并对照JIRA故障单或其他事件的发生率交叉引用这些模块。

我觉得这篇你翻译的很不好,作者在原文TDD那里的表述是非常的支持,建议学习,而你这文章中简短的一句说明了你没看就翻然后就放出来。
这种行为挺不负责的。
感谢你提供这样的平台并且每天更新。但是也希望能保持一个底线。

写了测试以后,如果需求变化,测试代码也要和原有代码一起变,这就是带来维护成本,这与少则多的宗旨一样的,需要理解其中逻辑一致性,原文作者在这点上是含糊的,看看原文下面的评论吧,主要现在鲍勃大爷主导的测试优先舆论实在太强大了,所有这些都是假定需求变化不大情况下,可惜需求变化很大,DDD专门应对需求变化的,应对需求变化的方法肯定不是写几个测试就能解决,也不是说将需求首先表现为测试,这是完全否定人的设计和建模方法。