有效软件开发的10条原则

有效软件开发的10条原则

原文:10 Principles for Effective Software Development

Image result for software development

几天前,我观看了由Harry Roberts在dotCSS 2014上发表的一段非常有趣的视频。他谈到了成为有效的前端开发人员的原则或最佳实践。但实际上,这些原则可以适用于所有类型的开发人员。下面我总结了这10条原则并提出了我对每条原则的看法。

1.最简单的选择通常是最好的

作为工程师,我们的工作就是解决问题。我们天生就很好奇,我们中的许多人都感受到不断学习新事物,框架和技术的奇怪愿望。通常,为了成为更好的开发人员,我们倾向于过度设计解决方案。大多数时候,我们觉得有必要抛弃我们所知道的所有有利于新范式的东西,但大多数时候它都带来了成本:过度复杂化的成本。

没人理解工程设计的东西。

关于这一点,我完全同意。无论何时选择执行解决方案的方法,请选择最简单的选项。它不太可能破坏,它不那么复杂,而且更容易理解。此外,实施起来总是更快,更便宜。相反,添加抽象级别引入了学习处理常见问题的新方法的需要。总是欢迎在大规模工作时减少认知开销。

我认为在这个原则中强调“通常”这个词很重要,因为我并不总是认为这是一个经验法则。在某些情况下,我们需要牺牲简单性而不是适应性,可扩展性和安全性。但通常情况下,这些都是罕见的例外情况。

2.减少运动部件的数量

简单明了的代码总是更容易维护。随着项目中依赖关系的增长,代码库的整体复杂性也会增加。这也增加了注入错误和问题的机会。添加一个可以更快地解决问题的闪亮新库似乎更容易,但实际上这会引入新的问题,在开始时您可能无法考虑。

我们在系统中注入的任何移动部件都会增加与其可维护性相关的成本。因此,每当您考虑在系统中添加新内容时,请三思而后行,并问自己添加新依赖项的好处是否能以更有效的方式解决问题,或者它是否只会暂时解决问题。

最好的代码根本就没有代码

我相信只要有可能摆脱某些东西,最好选择那条路径,而不是在系统中添加更多移动部件。 可以这样想:更多代码=花费更多时间来维护,修复和重构。所以下次当你看到安全摆脱某些东西的可能性时,就去做吧。系统的每个运动部分都是潜在的失败点。

重构以降低复杂性。尝试以一种可以简化解决方案的方式重构事物总是一个很好的练习。我发现尝试找到核心模式,杀掉代码甚至不会增加太多价值的功能通常都是个好主意。

3.了解业务

把自己放在雇主的脚下。始终考虑您的努力可以带来更大的利益。了解您工作的价值,为公司的利益服务。与其他人的问题联系起来,随时准备提供帮助。知道其他人可以通过提供有用的建议避免犯同样的错误。从长远来看,这种心态会让你处于一个更有价值的位置。

提高您的技术能力对您有好处,但不一定适合您的公司。在自我改进和团队发展之间找到一个很好的平衡点。请记住,即使你还没有意识到,你并不孤立,你的工作也会产生很大的影响。

了解您的优势以及您的弱点,以便您随时准备指导并在需要时寻求指导。了解所有让你有价值的事情。不要只是一个开发人员,尝试更广泛的视角,并了解您的工作如何转化为您公司的财富。不要只是构建功能,创建解决方案。

4.小心,小心,小心

没有人比你更关心你的工作。通常需要进行权衡以保持工作流程顺利运行。你总会找到关于一切的不同意见,虽然参与辩论有时很有用,但你可能不想浪费时间辩论肤浅的东西。

知道每次表达您的意见时,您的同事都会花时间,了解您并回复您。在表达意见的同时尊重他人和自己的时间。因此,下次您公开分享内容时,请考虑它将为您的团队的集体知识增加的价值。选择正确的战斗。只要你确定一些有谦卑的东西并且愿意听取意见,就要站起来。请记住,你并不总是正确的,并且考虑到不同的观点是有价值的。

平衡每个人的需求和需求

关心你的工作,不要关心你的团队。不那么自私,也愿意为别人的利益做出牺牲。更适合其他人的工作。请记住,您的工作,文字和意见对您的队友工作有影响,即使一开始并不明显。考虑一下如何通过消除压力而不是添加压力来改善队友的生活。

5.实用主义胜过完美

最好是及时而不是完美。事情在我们的行业中变化很快。我们不断努力创新并找到制作更好产品的新方法。有时为了确保产品的质量,我们做出了一定的权衡。我并不是说质量不重要; 每家公司都应至少拥有一套基本的质量标准,以便每种产品都能提供最佳体验。但在我看来,应该在足够好和完美之间取得适当的平衡。

今天足够好比明天更好

根据业务价值衡量功能。不要等待这么长时间才能释放。它是否符合贵公司设定的最低质量标准?如果是这样,现在就开始解决核心问题,并在以后为重构任务分配一些时间(确保你这样做,否则质量会随着时间的推移而恶化)。根据业务价值衡量构建的每个功能,并相应地确定优先级。什么都不是或将永远是完美的。你不应该推迟一个项目的肤浅决定。专注于定义什么是最小可行产品并尽快发货。稍后您可以花一些时间来改善体验。今天有用的东西比下周有效的东西更好。

6.在产品级别思考

您的工作不仅仅是生产功能,就像您是工厂一样。每当要求您构建一个功能时,总是考虑一下,并问自己您的工作添加到产品中的价值。不要害怕恭敬地质疑管理决策。如果您对某些事情不相信,请确保在沿着这条道路前与您的线索进行讨论。

我相信他们会发现你的意见很有价值,或者会照亮你的方式,以防你没有看到更广泛的情景。尊重并灵活应对。优秀的管理者是优秀的倾听者,他们会重视不同的观点,并会根据他们的知识做出正确的决定。

想想所有因素,无论是团队速度,复杂性还是生产力。考虑所有可能的因素做出决定。参与其他人的问题,不要只是做你的工作。了解项目的背景并做出增值的决策。

7.不要在Edge-Cases周围设计系统

不要让边缘情况决定您的产品决策,而是关注产生最大利益的因素。首先考虑为您的核心受众解决问题,然后为边缘案例改进体验。换句话说,不要让少数人占多数,也不要基于统计异常值来建立整个产品。这些极少数情况下某些特定部分不起作用不应阻碍产品的发​​布。

想想你的主要用户群和设计,而不是罕见的异常。首先构建最常见的场景。在此过程中单独解决边缘情况。定义理想的核心用户群并根据硬统计数据(例如浏览器使用情况)解决问题。有时我们可能会花很多时间来修复只影响最少量用户的错误。如果它不重要,您不应该在追求完美的过程中危及产品的发布。

一切都容易出错,而且一切都会出错,但要知道按时发布产品可能比延迟发布非常罕见的情况带来更大的好处。有一个发布策略,并确保你分配时间来修复那些讨厌的错误,但不要等到修复它们才能开始收集数据甚至投资回报率。

8.不要根据轶事证据做出决定

每当有人告诉你某件事情很棒时,你会在做任何事情之前进行研究吗?如果某些事情不适合我们当前的思维模式,那么很容易就会迅速进入判断和结论。做你的功课,尽量做出公正的决定,并总是在这个问题上寻找不同的意见。

一般而言,罕见的异常或不符合共同标准的强烈观点是基于缺乏理解或深刻反省。如果是后者,你应该考虑它。确保这些意见基于第一手经验和仔细分析。

不要相信每个人都说的一切,而是根据事实数据得出自己的结论。轶事并不总是具有代表性,可能会导致您做出错误的决定。永远不要相信八卦,总是信任数据。

9.在你被问到它之前不要建立它

提出一个闪亮的新解决方案真的很诱人,让每个人都感受到它的智慧和创新。但是,大多数时候在没有得到所有人的同意的情况下建立一些东西是不尊重的,不仅因为你的雇主花费了很多时间,而且因为你建造的所有东西都有维护成本。

过度交付真的很酷,但在实施之前要三思而后行。这是现在的要求吗?您是否100%确定它会产生积极影响?最重要的是,它是否得到了管理层的批准?保持没人要求的东西是不负责任的。无论何时遇到问题,都要解决每一个问题。不要提前做好工作。

解决现在没人的问题并不聪明。要明智地使用你的时间,下次你想要创建一些很棒的东西,然后再与你的潜在客户进行讨论。我相信如果它真的很好,你将有一个批准标志和利益相关者的支持来执行。请记住,沟通是证明自己有价值的关键。它表明您了解事物的运作方式,并了解您的工作如何影响组织。

10.期待并适应变化

担心现在解决问题的事情。明天的技术很可能会改变,所以无论如何你都需要适应。专注于解决问题的方法,但要足够灵活,让下一个开发人员轻松适应您的代码。确保你可以撤消一些事情。

我之前因为没有遵循这些原则而被咬过,这就是为什么这些原则引起了很多共鸣,我真的希望在我开始与团队合作之前我会听到这个,因为它可以让我变得更有价值。现在是时候尽可能地应用它们了。你怎么看?您认为其他原则是否重要?我很想听听你的意见!

在dotCSS2014下面观看Harry Roberts的视频:

39 total views, 2 views today

Author: Albert

Leave a Reply