作为一名程序员绝对是要更聪明地工作，而不是更努力地工作。

我经常向与我一起工作的程序员一遍又一遍地提供相同的建议。大多数时候，我会建议一些与编码有关的事情，而且效果很好，但“不该做”与该做的一样重要。

让我们看看程序员应该注意的 15 件事。其中大多数都是针对面向对象的语言，但有些也适用于过程式、函数式语言。

1. 不要忘记面向对象编程、继承、封装和多态性的原则。

2.不要过度使用继承。继承应该有意义。问问自己关于这种关系的情况。如果“是”，那么您应该继承，如果“有”，那么它应该是与所有者的关系。

3. 注意方法/函数/子例程的长度。如果方法或函数的长度超过 5-10 行，您可能会错过抽象或提取功能的机会。方法越长，它就会呈指数级地变得越复杂。

4. 在开始“自己动手”之前，花一些时间寻找之前有人解决过此问题的开源解决方案或博客文章。利用别人的辛勤劳动并没有什么错。其他人很可能会在某个时候接管您的工作，如果他们可以通过 Google 搜索或 chatgpt 找到支持的解决方案，那么对他们来说会更容易。另外，请考虑与滚动您自己的解决方案有关的测试和维护时间。除此之外，无论你认为自己有多优秀，一个人提出比社区项目更好的解决方案的可能性都不大。

5.不要黑客攻击。对于在时间紧迫的情况下编写的代码有很多话要说，但程序员通常会利用这个借口来简化解决方案，而不是花时间按照他们知道应该完成的方式来完成它。你希望下一个程序员看到你的代码并拍拍你的背寻求解决方案，而不是厌恶地咒骂你。

6. 不要忘记可重用性。想想你写的每一行代码。问问自己，你正在做的事情是否会被你或其他人重复。如果是，则将其抽象为实用程序类并重用它。当您可以将代码提取到实用程序或利用多态性来满足需求时，切勿将代码从一个地方复制到另一个地方。

7.不要使用晦涩难懂的变量名。当其他人查看您的代码时，变量包含哪些数据应该非常清楚。

8. 不要忘记要求进行代码审查或设计审查。没有人是完美的。您应该始终与同伴并肩坐在一起浏览代码。解释你的理由，以及你使用的技术，并向审稿人寻求建议。三个臭皮匠顶个诸葛亮。另外，您应该尽早并经常这样做。不要等到项目完成才要求审查，因为到那时，修复可能就太晚了。

9. 当局部变量就足够时，不要使用全局变量或成员变量。我以前见过几次这个。初级程序员会尽可能扩大变量的范围。这不仅会在其他人查看代码时造成混乱，而且可能会在您的应用程序中造成意想不到的后果。

10. 不要忘记线程和线程安全。对于缺乏经验的程序员来说，线程是一个很难理解的概念。如果你不考虑的话，它很快就会咬你一口。复杂的应用程序可能有许多线程访问相同的资源，如果您不集中精力管理它，那么您可能会得到垃圾数据、崩溃和意外结果。不要将所有内容同步作为线程安全的解决方案，否则性能会受到影响。

11. 不要先编码，然后再提问。在编写一行代码之前，您应该了解问题领域和想要实现的目标。理想情况下，您将设计应用程序并在实际将代码放到屏幕上之前在头脑中进行精神健全检查。

12. 不要忘记单元测试。除非您只是喜欢花费大量时间测试应用程序或坐在 QA 资源旁，否则您应该在最低级别对代码进行单元测试，并将这些测试作为回归测试与构建一起运行。请记住，单元测试适用于非常小的代码。单元测试不会取代应用程序的实际功能测试，但它确实会使测试变得更容易。

13.不要忘记评论，也不要过度评论。如果您想为自己提供提示、提醒或将该提示提供给其他程序员，请使用注释来阐明要点。也不要过度注释您的代码，因为太多注释表明复杂性，您需要重新访问代码以进行简化或重构。

14. 不要忘记重构你的代码。如果您发现代码中有需要修改的地方，请尽早进行修改。如果您等待，使用它的其他代码可能会使问题变得更加复杂。永远不要等到项目结束才重构，你永远没有机会，到那时，这是一项艰巨的任务。

15. 不要忘记分层和松散耦合。不要忘记使代码尽可能松散耦合。一个好的策略是将代码分层，例如 DAO 层、服务层、集成层、控制器、UI 层等。例如，UI 层不应该直接从 DAO 层访问类，而应该利用控制器来访问数据，进而访问服务层等等。

虽然这不是一个包含所有内容的列表，但它确实给程序员带来了很大的优势。作为一名程序员绝对是要更聪明地工作，而不是更努力地工作。

本文内容仅供个人学习/研究/参考使用，不构成任何决策建议或专业指导。分享/转载时请标明原文来源，同时请勿将内容用于商业售卖、虚假宣传等非学习用途哦～感谢您的理解与支持！

链接: https://fly63.com/article/detial/12600