作者 | Allen Helton
责编 | 唐小引
以下为译文：
今天是我 30 岁生日。
虽然对我 20 多年来的生活已经感到很满意，但是我更期待未来十年可能发生的变化。
为了庆祝这个重要的里程碑，我想和大家分享我的职业生涯中总结的软件开发相关的 30 条有价值的经验。
1. 抓住每一个学习新东西的机会
我不确定是否还有一个行业的发展速度能够比软件行业更快。新的方法和模式不断涌现，管理服务每天也都在改进。你要抓住每一个学习新东西的机会，不断丰富自己的技能栈。
2. 意见分歧成就创新
要和那些与你意见不同的人呆在一起。如果你的团队都赞同你的意见，你的思想会变得越发狭隘。别人对你的质疑不仅可以帮助你完善自己的方案，还可以激发你想出创新性的观点。
3. 30岁以下编程经验分享 不要带有个人色彩
如果你的代码反复修改最终测试五次都没通过或者在最终的 sprint 评审中你的方案不被认可，你会怎样？我们都是团队的一员，有着相同的目标: 我们要尽自己所能开发出最棒的软件。
4. 自动化
每次你让一个人完成一项任务，都有可能出错。但是机器不会忘记清单上的事项。机器会以同样的方式一遍又一遍地执行同样的任务。自动化从身份验证 测试到 部署策略的所有工作。
5. 拥抱失败
你永远不会比现在知道的更少。如果你尝试构建一个新的软件，但是失败得很惨，那也没关系！下一次你尝试的时候，你就会知道什么是不该做的了。我们可以从失败中积累经验，提高技能。
6. 用户体验就是一切
客户不会因为后端编写的好而购买你的软件，用户体验才是你产品的卖点。他们之所以会买它，认可它，是因为它以一种直观和有效的方式解决了他们的问题。
7. 小步快跑
在构建软件时，你的目标应该是让某些东西能够正常工作并尽可能快的展现给用户。一般来说，人们很难凭空给出所有的想法。但是他们可以告诉你如何把你所拥有的变成他们所需要的解决方案。
8. 不要循规蹈矩
不要认为 “我们这样做是因为我们总是这样做”是理所当然的。做某事是因为就该这么做，而不是因为这么做自己最熟。如果你从不尝试去做不同的事情，你就很难改变。
9. 使用单一责任原则
汽车开起来真的很好。但是如果你让一辆车飞起来，你就会牺牲它的一些驾驶能力。它也许可以同时做到这两点，但它永远不可能将任何一点做的很棒。你的代码也是这样的，保持专注，做好一件事。
10. 代码调试被高估了
如果你遵循单一责任原则，那么你的代码应该只关注某一个功能。如果它的功能非常聚焦，出现问题也会非常容易定位。没有比控制台日志和一些单元测试更快定位问题的了。
前面已经给出了 10 条建议，下面的建议可能会有些争议。
11. 编程语言的选择很重要
当开始一个新项目时，想想你要解决的问题。Python 适合大数据处理。JavaScript 适合普通的网页开发。世界上有这么多种语言都有其存在的原因，你要选择最能解决问题的语言。
12. 实践出真知
如果你想学习一些新的东西，无论是编程语言，新的架构模式，还是技术栈，动手实践将极大地提高你的理解能力。在你实践之前，理论只是理论。此外，你还可以与他人分享你学到的东西。
13. 你永远不会知道一切
直到进入开发阶段，你可能才发现更好的方法。你可以在开发阶段再对其进行改进。技术变化飞快，昨天能够解决问题的最佳方法可能今天已经不再是最佳选项。
14. 暂时用不到就不要写
这听起来可能显而易见，但是并非所有人都可以做得到。谁要求你要加那个配置的？没有人啊？那就硬编码。如果你暂时不需要就先不要去写。先完成最基本功能然后再去迭代。
15. 评审和回顾很重要
在敏捷开发中，你在 sprint 结束时要进行 sprint 评审和回顾。如果你的回顾工作做得好, 你和你的团队的效率就会提高。你将会和他们保持一致，能够更快地行动，并且拥有无与伦比的团队友谊。
16. 80 / 20
当你发布你的最终产品时，你可能会失望地发现你的消费者并没有用到你开发的所有功能。事实上，他们会找到一小部分功能(大约 20%) 使用(80%的时间)。只有 20% 的时间，使用其他 80% 的功能。因此，请把你的注意力放在优化解决业务问题的功能上。
17. 优秀的架构师能为复杂问题提供复杂的解决方案
有些问题比其他问题更难解决。如果你有一个好的软件架构师，他们会设计一个复杂的解决方案来解决这个复杂的问题。
18. 但是伟大的架构师可以为复杂的问题给出简单的解决方案
一个有才华的人才能降低复杂解决方案的复杂性，并将其转化为每个人都可以使用的东西。他们把问题的主要部分放在自己身上，并提出了一个简单的解决方案，这个方案掩盖了困难任务。例如，一位伟大的架构师设计了亚马逊的“一键购买”按钮。他们完全可以将所有复杂性隐藏到一个按钮的背后。
19. 1x，10x，100x
如果你发现正在编写的代码存在问题，请立即修复它，此时花费的代价最小。但是如果你让 QA 去查找 bug 并上报，这将需要 10 倍的代价。你需要分析师的努力，再加上你再次熟悉它并解决它的努力， 如果 bug 进入这个阶段，需要 100 倍的努力才能修复。你可以让用户进行上报问题，然后使用任何必须的流程来修复问题，然后进行测试和部署。
20. 故事和隐喻是关键
如果你想以最简单的方式解释你的软件是如何工作的，那就讲一个故事。人们通过将自己熟悉的事物联系起来，与故事和隐喻产生联系。他们会理解你想要传达的信息，并且能够将这些信息传达给其他人。
21. 一个健壮的、文档详尽的 API 物超所值
现在，软件是持续集成的。我怎样才能把这项服务与那项服务联系起来？答案就是通过 APIs。如果你构建的 API 具有丰富的功能集并且有详细的文档说明，那就太棒了。开放 APIs 是当今的标准，你应该尝试构建它们。
22. 面试官更关心你的问题解决能力，而不是你的编程理论知识
当我面试某人的时候，我会回答一些理论上的问题，但是我大部分时间都在试图了解你的大脑是如何工作的。如果编程是你的日常工作，你会花一整天的时间想出问题的解决方案ーー而不是写什么多态性。
23. 80 / 20（再次出现）
大约花费 20% 的时间完成 80% 的工作，剩下的 80% 的时间完成最后的 20% 的工作。想象一下正在建造的房子。在第一个月，你会看到一块从草地到地基、脚手架和房间的土地。从那时起，事情就像蜗牛一样慢了下来。软件也是一样。大部分的时间将花费在不那么重要的阶段。
24. 之前做过
开发人员开玩笑说，他们从来没有写过一行原创代码。老实说，这可能是真的。模式的存在是有原因的。你软件独一无二的原因是解决业务问题的方式。不要因为标新立异而提出一个新的模式。可以尝试使用一些行之有效的方法，把更多精力放在提高用户体验上来。
25. 良师益友至关重要
无论你是刚刚开始自己的职业生涯，还是已经工作了 4、5 年的老手。肯定有人做过你要做的事情，你可以寻求他们的帮助。通常情况下，他们很乐意帮忙。
26. 一切都在代码中
计算机会完全按照你说的去做。他们没有自己的思想。你的代码不能工作，是因为你写的就那样。出现问题代码中总会有答案，需要你自己去寻找。
27. 软件是一个环
当时我并不在场，但显然云开发几乎和大型机开发一模一样。现在的工具更好了。方法论也是循环的。我们曾经热衷于瀑布式开发，然后进入了敏捷开发，但是 瀑布式开发似乎又卷土重来了。也许今后 10 年将带给我们一个改进的工具包和过程，就像我们 20 年前所做的那样。
28. 存储空间被淘汰，计算机开始流行
过去，所有的成本优化策略都围绕着节省磁盘空间而展开。使用所有的计算机，你可以占用尽可能少的存储空间。但是今天，情况发生了翻天覆地的变化。存储成本几乎为零，计算价格也在上涨。花时间优化代码的处理 ，尽可能地存储所有东西。
29. 数据之美
大数据是非常重要的。它为机器学习提供动力，为我们的工作过程提供参考，并阐明趋势。现在数据存储如此廉价，没有理由不将我们想要存的都存储起来。人们喜欢图表、图形和趋势。用数据为决策者提供参考。
30. 最好的工具是你的团队
如果你想要进行创新，建立一个强大的团队。一个相互信任的团队可以完成工作，相互挑战，在个人层面上建立联系。建立一种致力于相互了解的文化将是你是否成功的最终决定因素。作为一个领导者，把你的努力投入到你的团队中。
总结
大概就是以上这些内容。
到目前为止，我在软件行业经历了职业生涯的很多巨变，我很高兴看到自己的观点在未来 10 年内会发生怎样的变化。
你还有其他的经验教训想要分享吗? 欢迎留言评论。
英文：Software Solutions and Technologies to Counter the Coronavirus Pandemic30 Things I Learned About Software Before I Turned 30
链接：https://medium.com/better-programming/30-things-i-learned-about-software-before-i-turned-30-f7c90c3068d5
作者：Allen Helton
译者：明明如月，知名互联网公司 Java 高级开发工程师，CSDN 博客专家。
有道无术，术可成；有术无道，止于术
版权声明：
本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。
本文网址：https://www.mushiming.com/mjyfx/206.html