My guiding principles after 20 years of programming

@ Alex Ewerlof

阅读说明

Tips:

H3 - 观点

方格中 - 自身想法

斜体 - 译文或总结

斜体英文 - 暂时无法翻译

正文

作者用一段话说明了自己长达20年的开发生涯,以及担任了各种技术相关的职位。然后以20年开发经验来看分享了一些积累的指导方针。

Don't fight the tools: libraries, language, platform, etc

尽可能的使用原生的开发方式。

掌握使用的库,语言,平台的部分源码,方便我们更快速的使用原生的开发方式
使用了越多的第三方库,意味着代码依赖项和不确定性的增加。

不要只专注技术,也不要只关注问题。

技术的本身是为了解决问题。
只专注技术对开发者而言非常喜欢,但与此同时很有可能带入技术的负债,增加交接的成本,对于团队而言是不利的,
只专注于问题对于开发只用最熟悉的套路去解决所有问题,会发现自己进入了业务的圈子无法自拔。

选择合适的工具

如何快速选择技术、框架是一门艺术。前期选择了合适的框架,可以事半功倍;
选择了不合适的框架,就会面临重构或者重写等等问题,极大增加开发者的压力。
如何选择合适的工具,对于决定者有着很高的要求,既要掌握业务,又要评估可扩展范围,还有熟悉不同框架的利弊,这些都源于平时的积累。

Don't write the code for the machines

代码视为自己的同事未来的自己写的。

曾经我以为,谁写的代码谁擦屁股。
但随着业务复杂度的增加和人员流动,如果是给业务写的代码,对于后来者的上手有着极高的交接成本,曾经已经临时改动的业务需求,可能会成为以后隐藏的小彩蛋。
以及随着代码量的增加,自己以往的代码会逐渐消失的视野中,等发现锅在自己这里时,却想不起当时留下这一段代码的原因也是开发人员的一大心病。
在合适的地方留下合适的注释,利己利人。

让自己的代码成为后来者的参考!!!

这是慢慢牛逼的开始和体现~

Any significant and rewarding piece of software is the result of collaboration

有效沟通,开放协作

在合适的时间讨论,在合适的时间范围内开会,增加沟通的效率
让专业的人做专业的事。
产品经理决定产品业务,程序员决定开发方式和细节,设计师决定页面展示。

相信他人,同时获取他们的信任

要尊重人,不只是代码

程序员之间的较量最开始很容易关注在代码上,谁的代码牛逼,人的牛逼。
这种纯粹又直接的方式慢慢就不可取。
随着开发经验的增加,会发现好的开发人员在人际关系的处理上,并不输于写代码的能力。
但这又是开发的弱项。

以身作则

简单明了。

将你的跟随者转换成领导者

培养合适的人员,并让他扛起大梁,是团队走下去的关键之一

Divide and conquer

独立模块

如何划分模块的业务范围或者功能范围是一个问题,随着对DDD的了解,会发现领域驱动设计提供了很好的业务划分的方法论。

独立测试和集成测试

分开测试可以让测试本身更加关注自身业务本身,降低系统的复杂度。 - 单元测试的关注点
集成测试则关注在模块交互层面的调用正确性 - 集成测试关注点

让测试贴近真实情况的同时,也要测试边界情况

Deprecate yourself

不要成为代码的首选人

并不是降低自己的输出,而是

*Optimize it for people to find their way fixing bugs and adding features to the code. Free yourself to move on to the next project/company. *

Don’t own the code or you’ll never grow beyond that.

Security comes in layers

每一层都需要单独评估,也需要相对于整体评估安全性

安全性是容易被忽略的部分,但是对于公司项目的发展却是至关重要的。但现在对于这一块的关注比较少。

危机是一项业务决策,也直接关系到易遭攻击性和发生可能性

每个产品、组织都有不同的风险偏好。这个是他们为了更大的利益承担的风险。

风险和机遇并存,有的激进,有的保守,取决于针对更大的利益是否能承担失败的风险

通常,这三点是相互冲突的:UX,安全,性能

与安全性相互博弈的主要有用户体验和性能,如同一个三角形的边界,相互影响了三角形的定点位置。

Realize that every code has a life cycle and will die

有时候,代码在看到上线的曙光前就跪了,那就平静地让它走吧

原因有很多,为了更好的设计,为了变更的需求等等,无需懊悔写了无用的代码。
代码本身就是为了业务,业务不需要的部分就是无用的代码。
我们只要做到设计好每一段代码,就算删了,也可以感谢曾经带我们的思考。

需要知道三类功能的不同点:

核心如同汽车的引擎。产品失去它就没有意义。

必需如同车的闲置能力。它很少用到,但是当需要它时,它的功能决定了系统的成功

附加值如同车的茶杯架。有它也很好,但是没有它产品也是完美可用的。

将不同的需求功能放到这三类中,让自己更加区分出哪些是产品的核心,让自己更快地理解需求的同时,也能抓住开发的重点。增加代码的性价比。

Don't attach your identity to your code

也不要附加任何人的特征到他们的代码上。意识到需要将人从他们创造的代码中分离出来。

不要将代码和人强绑定

不要提出仅代表个人观点的代码评论,当评论其他人代码时需要非常小心

批评别的开发人员的代码容易引起纷争,需要有事先的规范,以及秉持对事不对人的态度

Tech debt is like fast food

偶尔一次可以接受,但是如果习惯了,它将会以比你认为快的速度结束产品的声明,并以一种非常痛苦的方式。

发现负债,及时调整。千里之堤毁于蚁穴,一次次的负债如同一个个蚂蚁洞,在不经之间造成无法估量的毁灭。

When making decisions about the solution all things equal, go for this priority

安全性 > 可用性(可理解 & 用户体验) > 可维护性 > 简洁性(开发经验/开发体验) > 简短性(代码长度) > 性能

但是不要盲目地遵从上面的优先级。因为它依赖产品的性质。

如同任何职业,你获得更多的经验,你可以找到不同情况更好的平衡点。比如,当需要设计一个游戏引擎,性能是最高优先级。但是常见一个银行应用,安全性是最高因素。

需要根据情况判断优先级,有越多的设计经验,就可以应对越多的场景。

Bug's genitals are called copy & paste

这是bug繁殖的方式。永远阅读你拷贝的代码,永远审核你引入的内容。

需要掌控你引入的所有代码,不求看过每行,但是得理解引入的功能。

Bug通常藏身在复杂场景中。“魔法”在我的依赖中可以存在,但是不能出现在我的代码中。

需要对自己的代码有着强掌控,让代码完成自己应该做的那一块。

Don't only write code for the happy scenario

好的错误信息可以回答「异常为什么发生」,「怎么发现」,「如何解决它」。

日志信息对于排查问题至关重要。好的日志信息可以给出明确的问题点。要根据团队的开发规范,正确地输出日志。

验证所有系统输入(包括用户输入):快速错误,尽可能在任何时候都能从错误中回复

对于所有对外的方法,需要验证所有的入参是否符合要求,来确保可以正常的运行。
尽早的发现异常数据,保证系统的稳定性

Don't use dependencies

除非引入,维护,处理它们的边界情况或Bug和当它们不再满足时重构的花费是明显地少于你自己写代码的成本。

也许这也是重复造轮子的原因。自己写一个功能,要比引入一个库时去判断引入,维护,边界处理,是否会重构等问题要简单的多。

Stay clear from hype-driven development

需要尽可能的学习。总是有一个业余的项目可以做。

花里胡哨的炒作的项目没有太大的意义,只有发自内心或者源于需求的开发才有意义。

Get out of your comfort zone

每天学习。把你所学的东西教给别人。

在这开发的行业里,保持学习非常重要,持续学习新的内容,才能走更远
学习的其中一种检验方式,就是把学习的内容教给别人,在教别人的同时,也是不断加深自己理解的时候
输入,咀嚼,输出,再输入,这是学习的一个闭环

If you're the master, you're not learning.

把自己暴露在其他语言,技术,文化中,并且保持好奇

将自己放在陌生的地方,让自己好奇心经常泛滥,是跳出舒适圈的两个秘诀

Good code doesn't need documentatin,Greate code is well documented

写好的文档可以让任何没有参与到开发过程中的人都能受益

一个未记录的的功能是一个不存在的功能。一个不存在的功能不应该有代码。

没有文档的说明,通过代码很难表述功能的演进,曾经的错误等等

Avoid overriding, inheritance and implicit smartness as much as possible

写纯方法。它们更容易来测试和思考。任何非纯函数都应该是一个类。任何代码有不同方法的代码结构都应该有不同的名字。

保持业务逻辑的纯净,不要加入太多依赖项。但是当避免了继承等Java的特性,会让面向对象失去一定的特色。合理利用设计模式,但又不能让代码结构过于复杂。

Never start coding (maing a solution) unless you fully understand the problem

花费在沟通和阅读文档上的时间比敲代码更多是非常正常的。在开始敲代码前理解业务领域。问题如同一个迷宫。你需要逐步完成 编码-测试-改进的圆环,然后斟酌问题的涉及范围直到你到达了边界。

随着开发时间的增加,发现花费更多的时间在思考上的价值,比花费时间在敲代码上会更好。
技术的牛逼之处不是用了种种看起来很厉害的方式,而是在开始开发前找到了能一击毙命的解决思路,并在开发后胸有成竹地把设计写出来。将思考和敲代码分离,会发现,思考的快乐和敲代码的快乐,都是愉悦的。

Don't solve a problem that doesn't exist

不要预测式编程。只有证实了它需要扩展的设定,再让代码变得可扩展的。

当有需要扩展的机会时,发现问题的定义已经和最开始写代码时不一样了。

可以考虑代码的可扩展性,但是杜绝过度编程,将不存在的用例过分考虑进去,从而增加了现在代码的复杂程度。
然而在出现需要扩展时,发现与自己曾经的预想不一致。

Software is more fun when it's made together

建立一个可持续的共享意识。倾听、激励、学习、分享。

团队氛围非常重要。相互学习,相互分享,相互激励,才能一起走得更远。

原文: https://medium.com/@alexewerlof/my-guiding-principles-after-20-years-of-programming-a087dc55596c