32 条关于软件开发的建议和教训
近几年来,我一直为大大小小的客户开发专业软件。这些软件中有一些是在非常严格的环境下使用的,安全性和可靠性是最重要的。基于多年的工作经验,我提出了一系列有用的建议和教训。以下是我整理的清单,包括建议、经验教训和最佳实践。
-
有时候编写一些垃圾代码也没问题。应用程序的各个部分并不是生来平等的。
-
不必通过学习一门新语言来学习新事物。很多相同的事情可以用多种语言来完成,宁可深而不广。
-
编写抛弃型代码以测试不同的方法。别把这些抛弃型代码变成产品代码。
-
防御式编程。你是否记得你认为永远不会变空的那个方法参数?是啊,结果它还是变成了空值,你的应用程序“爆炸”了。只需写下这些卫语句(guard clauses)就可以了。
-
从来没有,永远也不会有应用程序的硬编码设置。写出可配置组件并向其传递环境变量。重启应用程序比重新编译和部署都要简单。
-
编写容易测试的代码。这就是说,停止在命令处理程序、服务等中“新建”数据库对象。取而代之的是,使其成为依赖项。
-
异常只会在特殊情况发生时抛出。
-
了解 If-Else 的合适替代方法。If-Else 经常被滥用,成为糟糕设计的早期标志。If-Else 语句在许多设计模式中是不必要的。
-
并非每一个 IF 都需要 Else If 或 Else。If 本身是可以的,并且经常受到鼓励。
-
重构意味着重构。进行重构时,不要尝试添加任何新功能。这样做没有什么好处。
-
如果发现了垃圾代码,请花时间清理它,使之更好——无论“更好”在特定环境中是什么意思。
-
假如不学习设计模式,将会遇到一些困难。它们无处不在,了解它们会使你的生活更轻松。
-
应用设计模式可以改善代码。
-
攻击别人的代码并不会让你成为一个更好的程序员,也不会展示你的资历。大多数新手都会攻击其他开发者的代码,因为他们甚至难以理解简单的概念。
-
在需要接口之前不要创建接口。由具体的类开始完全没有问题。
-
你是否确定该字段 / 属性 / 方法需要公开?没有,我也这么认为,将其设为私有或者内部。
-
一个超简单的类,就像一个简单的方法,它是可行的。
-
针对简单问题编写简单代码。
-
请确保测试了重构的每一部分。不然你就不知道你在破坏什么。
-
不 —— 你刚刚草草记下的代码并不比下载量为 1100 万的 npm/nuget/pip 包好。下载那个该死的软件包,并继续前进。
-
对于复杂的问题,不要害怕提出复杂的解决办法。别走另外一条路。
-
掌握几种语言就可以了。尝试学习一种后台、前端和数据库语言。通过这种方式,你可以更好地理解团队中其他人所处理的问题。
-
别再看这些该死的教程了。独立思考一下。当你陷入困境,或者需要快速学习一些东西的时候,偶尔有一些教程是很好的。只是要退出教程的“灵薄狱”。
-
其他大部分的开发者也会编写垃圾代码。别为此而丧失信心。他们这么做一定有原因。
-
观看开发者会议的讲座,并关注思想领袖。有很多很好的经验可以借鉴,而且很容易得到启发。
-
在成为更好的开发者的过程中,我们都会遇到瓶颈。向有成就的开发者寻求建议。不要害怕给一个随机的开发者发送消息。
-
以 GUID/UUID 作为实体 ID,这使得处理起来更加简单。但是,请注意你的取舍。
-
遵守 SOLID 原则。它们易于理解,并且可以改进代码质量。诸如“开发 / 封闭原则无关紧要”之类的声明会反过来咬住你。
-
当选项数目有限时,使用枚举代替字符串作为参数。
-
在模块中安排代码(项目以 .NET 术语表示)。别把所有的东西都放在一个模块里。很快就会失去控制。
-
你将要解决的业务问题,或者将要开发的业务应用,都是必须牢记的。对于企业来说,代码只是实现目标的一种手段。
-
将软件开发视为一种手艺。编写出有目的、漂亮的代码。主动去提高自己的技能。
肯定会有开发者对我的一些建议提出质疑,你总能找到不同的观点、方法和想法。
多思考是有益的。对你认为对你有意义的事情要保持批判的态度。
作者介绍:
Nicklas Millard,是一家发展最快的银行的软件开发工程师,负责为关键任务构建金融服务基础设施。曾担任 Big4 的高级技术顾问,为商业客户和政府部门开发软件。
原文链接:
本文文字及图片出自 InfoQ
共有 1 条讨论