软件开发技巧与窍门

这些只是我想分享的职业生涯中的一些技巧和窍门。 此列表不包含银弹，也不假装是完整的或绝对的。 我只是希望对某人有帮助的清单。

1）将编码推到最后

这一点也可以理解为编码前的思考 。 收到新功能的规范后，我发现自己很多次，尤其是在我的职业生涯初期，就急于编写类，方法和接口。 这种冲动在90％的情况下变成了痛苦的情况。 规范不清楚，我的代码也不清楚。 规范太“面向代码”，因此盲目地进行编码会产生错误的设计/实现，需要将其废弃并完全重新设计。 还有许多其他缺点，就是在收到规范后立即编写代码。 因此，吸取了教训，这是我收到要开发的规范/故事后正在做的事情：

1. 我远离键盘！
2. 我打印了规范（对不起的美洲虎 ），并花时间仔细阅读它们。 不要以为您将在此处阅读的所有内容都可以避免错误，或者无法用更好，更简单的方式来完成。 归根结底，撰写规范的人们对软件几乎一无所知，他们知道如何利用新功能赚钱。
3. 如果您不清楚某些事情，那么如果您开始编写代码，它本身就不会神奇地进行澄清。 向其他同事，对企业提出问题，并尽可能多地澄清，只有当您有信心，看到他们真正想要的东西时，然后才能打开监视器并单击Eclipse图标。 …

2）简单=完美

让KISS和YAGNI这两个著名原则成为您的血液，皮肤和骨骼的一部分。 力求简单，忘记趋势，专注于最基本的东西，它将为您提供所需的东西。 不要直接考虑XML配置，spring / seam框架，流口水，方面，多线程解决方案，ejb或任何您知道或听到的复杂/酷技术，没有人真正在乎您使用的技术。

每个人都在乎的是您的代码执行了应做的事情，它是可读取的，并且是可维护的。 纯Java足以满足您需要的所有内容的90％或更多。 始终进行编码，就像最终维护您的代码的人是知道您的住所的暴力心理变态者一样。 让他开心，编写简单，清晰明了的代码。 我记得我在某处读过，如果您在1或2年后阅读了您的代码，并且您立即了解了所有工作，并且无法对其进行简化，那么您的代码就是完美的。

3）纸和笔

我从未发现有什么工具比纸和笔对设计软件更有用。 在编写软件之前，我通常会花一些时间尝试将设计思想付诸实践。 然后，如果有疑问，我将与一位同事一起讨论。 因为纸上写着，所以我可以和我的同伴一起快速解决问题，他可以快速告诉我是否遗漏了一些东西。 知道您在纸上丢失了某些东西，那就比知道您在代码中丢失了一些东西要好得多！ 因此，不要浪费时间使用UML工具，除非您正在做的是令人惊叹的惊人新架构原型。

4）明天不要离开你今天可以做什么

如果您要修复错误或添加新功能，并且在现有代码，重复名称或错误名称或可能的错误中注意到，请立即进行修复。 不要等待下一个冲刺，也不要在技术积压中添加技术故事。 积压了很长一段时间的技术故事，何时/如果需要进行处理，那么重新理解问题的背景并加以解决将变得更加复杂。 例外是，修复/重构太复杂且需要很长时间，那么在技术积压中创建故事是适当的！

5）你有时间！

真的，您有时间！ 不要着急 没有竞争，您也没有参加编程奥运会。
您的工作是提供高质量的代码 。 而已。 这是你的工作！

如果您认为一项任务所花费的时间比您最初估计的时间更长，那么只需在下一个任务中让团队意识到，便可以了。

如果一个客户/经理因为您想要比您交付的速度更快而大声疾呼，那不是您的问题！！！ 当他们说“我想要这个功能做好准备尽快”翻译成Truthlish它的意思是“我想要这个功能是完美的，没有BUGS尽快”。 与拥有快速发布的问题相比，他们将更愿意等待更多的错误，并且错误更少。

因此，请花一些时间，对软件的质量水平保持不变，而不必担心外部压力！

6）首先实施离开

因此，您刚刚收到了一个全新的故事，需要发展，并且您想正确实施它。
例如，这个故事是关于计算商品价格的。 每个项目一个价格。 每个价格都是通过不同的计算得出的。

选择一项价格逻辑，并首先根据此逻辑编写单元测试 。 不要强调实现整个设计或编写接口，抽象类等。每次只专注于一小片叶子！
当第一片叶子完成时，从第二个测试开始，以测试要实现的第二个小逻辑。 该设计几乎会自行完成。 测试将告诉您最好的方向。
7）进行配对编程！

我只是在最近（不到一年之前）才完全应用了此技术，而且我必须说，它功能强大！ 它比单独工作具有两倍的生产率，代码质量优越，开发速度提高。
这种技术的优势在于有趣的事实。 有趣且更具刺激性意味着您更加专注，并且更加关注细节。

在进行结对编程时，您可以学到很多东西，因此请尽可能多地努力学习！

8）很少使用检查的异常

每次我使用一个API强迫我放置其称为try and catch块的方法时，都会使我感到紧张，就像暴力的精神变态者一样，但通常我不知道它们会离开哪里。 尤其是如果我无能为力，那就例外了。 我到底应该怎么处理这个错误？

如果要使用选中的异常，则只有在客户端可以在运行时从其合理恢复的情况下才使用它们！ 请记住，如果您需要扩展行为，则检查异常将遍及您的整个设计！

9）对Hacks说NO 编程就像性。 一个错误，您一生都必须予以支持。 （迈克尔·辛兹）。

和黑客都是错误！

根本就不要实施黑客。 过去，无论出于什么原因（没有时间，压力，渴望尽快发布功能，经理们尖叫，兽人，妖精等等），我过去都是这样做的，而现在几年后，我们需要对其进行维护。 骇客很难理解，它们破坏了代码的正常逻辑流程，而且很难死！ 您今天和明天（也许是1年后）实施了hack，其他人将需要修复此hack的错误，并祝您好运！

如果黑客是业务请求，请花更多时间在规范上，并说明为什么这会花费很多维护成本。 提出其他解决方案，与您的团队讨论，一个更好的解决方案正在路上！

10）忘记评论，只写专有名称！

在编写包，类，方法和变量时，请写上适当的名称。

写出有意义的名称，提交代码之前先进行评论，但不要口头解释您的所作所为，首先尝试让审阅者阅读代码，看看您在编写自我解释性代码方面有多好！

需要保留评论，否则会产生误导。 您多久修正一次代码中的错误并更改了类文档？我很少这样做！仅在确实有必要时才使用javadoc！如果这样做，则请记住在每次更改代码并执行相同代码时都要对其进行更新您团队中的行为！

11）重新发明轮子

尽可能多地阅读书籍，博客，教程等，但要始终保持批判和开放的态度 ！ 在聆听您的团队或领导者时也是如此。 不要被当局愚弄，要始终以自己的思想思考。
如果您决定采用某种方法，那一定是因为您相信它。 因为您看到这样做的充分理由。 如果您觉得可以做得更好，或者在使用的方法中发现问题，请与您的团队讨论，并尝试澄清您的疑问。 与团队交谈后，如果您仍然觉得事情应该有所不同，那就争取更好的方法并为您的想法而战！

有时，要取得进展，您需要重新发明轮子，或者这时我们都在FORTRAN中进行开发。

别忘了分享！

参考：来自我们的JCG合作伙伴 Marco Castigliego的一些开发技巧和窍门 ，位于“ 删除重复项和修复不良名称”博客上。

翻译自: https://www.javacodegeeks.com/2012/09/software-development-tips-and-tricks.html