解决不了bug先放着,这里有40条提升编程技能小妙招

原文链接:https://medium.com/swlh/40-tips-that-will-change-your-coding-skills-forever-bf9d6b936ccc

一、40条编程小技能

或许,通过以下 40 个小贴士,你可以提升自己的编程技能。

  1. 将大块代码拆分成函数。

  2. 下班的时候还有问题没解决,请关上电脑,明天再看。

  3. YAGNI 原则(你不会需要它):只写别人要求你写的功能。不要预测未来,只需要尽可能快地完成开发。只编码解决当前问题最必要的部分。

  4. 你不需要什么都懂,也不需要了解所有框架。最棒的事情莫过于打好基础。在开始使用一个框架前先深入了解这门语言,学习基础的事项(如 SOLID 原则),或者如何写出干净的代码。

  5. KISS 原则:KISS(保持简单和愚蠢)原则表明,大多数系统保持简洁而非复杂化,就可以运行得很好。尽管这很符合逻辑,但有时候却很难做到。

  6. 不要想太多。

  7. 如果你和一个问题或 bug 斗争了太长时间,先离开一会儿,等下再回来。通常,在离开办公室去往卫生间的路上,解决方案就会出现在脑海里。当你对客户或同事生气时,也建议你暂时离开去走走,如果你还想保住工作的话……

  8. 学习写有用的测试,学着用 TDD(测试驱动开发)。TDD 是一种软件开发流程,它是对如下简短开发周期的重复:写测试;运行所有测试,查看新的测试是否运行;写代码;运行测试;重构代码;重复。

  9. 先解决问题再写代码。不要在一筹莫展的时候开始编程。

  10. 不要记代码,而是理解逻辑。

  11. 如果你复制粘贴 Stack Overflow 中的解决方案,请确保自己首先理解它。学习用恰当的方式使用 Stack Overflow。

  12. 想学习,先实践。创建示例,并使其运行,因为只通过阅读来学习远远不够。

  13. 研究他人的代码,也时不时让别人研究你的代码。结对编程并进行代码 review 是不错的想法。

  14. 不要重复造轮子。

  15. 代码是最好的文档。

  16. 了解如何搜索。你需要有经验,大量阅读,了解需要找什么。

  17. 你写的代码以后会由自己或别人进行维护,因此写的时候想着读者,不要把自己当做最聪明的人。写代码要像写故事一样。

  18. 用谷歌解决错误的最佳方式是复制粘贴。

  19. 不要放弃,问题总能得到解决的。糟糕的时刻总会过去。

  20. 好好休息。解决问题的最佳方式是先让大脑得到充分休息。

  21. 学习使用软件设计模式。设计模式是软件设计常见问题的解决方案。每个模式就像一个蓝图,你可以依据它进行自定义,进而解决自己代码中的常见设计问题(记住,不要重复造轮子)。

  22. 尽可能地使用集成工具和自动化方式。

  23. 练习编码套路(code kata):编码套路是一种编程练习,可以帮助程序员通过重复实践来提升技能。示例参见:https://codingdojo.org/kata/

  24. 编程并达到接口水平,而不是实现水准。依赖注入是必要的,参见 SOLID 原则。

  25. 重构——测试 - 重构。重构即对现有代码进行重建、改动,在不改变其内部行为的前提下提升内部结构。

  26. 必要的时候寻求帮助,不要浪费时间。

  27. 多实践,熟能生巧。

  28. 尽管有时候注释可以帮到你,但不要在这上面花费太多注意力。注释可能是过时的。

  29. 了解自己的开发环境,并建设足够强大的开发环境,如 IntelliJ。

  30. 重用组件。

  31. 在开发 web 应用时,思考移动端及其相关的电量和带宽限制。

  32. 不要过早地优化或重构代码。尽快做出最小可行性产品比较重要。

  33. 不要为了节约几分钟,而选择低效的捷径。每次写代码,都要竭尽全力。

  34. 遵循文档标准。

  35. 用户不是技术人才。开发 UI 时时刻想着这一点。

  36. 经常使用 GitHub 或 bitbucket 等源代码控制系统,并频繁进行小的提交更新操作。

  37. 使用 log 要比代码 debug 更好。将所有关键部分记录下来。

  38. 写代码时要保持连贯性。如果你使用一种风格,请一以贯之。如果你和多人合作的话,请和整个团队使用同样的风格。

  39. 不要停止学习,不止是学新语言或新框架,还要关注软件开发基础知识。

  40. 最后,保持耐心,保持热爱。

二、SOLID原则

设计模式的六大原则有:

  • Single Responsibility Principle:单一职责原则
  • Open Closed Principle:开闭原则
  • Liskov Substitution Principle:里氏替换原则
  • Law of Demeter:迪米特法则
  • Interface Segregation Principle:接口隔离原则
  • Dependence Inversion Principle:依赖倒置原则

把这六个原则的首字母联合起来(两个 L 算做一个)就是 SOLID (solid,稳定的),其代表的含义就是这六个原则结合使用的好处:建立稳定、灵活、健壮的设计。下面我们来分别看一下这六大设计原则。

1. 单一职责原则(Single Responsibility Principle)

一个类应该只有一个发生变化的原因

There should never be more than one reason for a class to change.

2. 开闭原则(Open Closed Principle)

一个软件实体,如类、模块和函数应该对扩展开放,对修改关闭

Software entities like classes, modules and functions should be open for extension but closed for modification

3. 里氏替换原则(Liskov Substitution Principle)

所有引用基类的地方必须能透明地使用其子类的对象

Functions that use use pointers or references to base classes must be able to use objects of derived classes without knowing it.

4. 迪米特法则(Law of Demeter)

只与你的直接朋友交谈,不跟“陌生人”说话

Talk only to your immediate friends and not to strangers

其含义是:如果两个软件实体无须直接通信,那么就不应当发生直接的相互调用,可以通过第三方转发该调用。其目的是降低类之间的耦合度,提高模块的相对独立性。

5. 接口隔离原则(Interface Segregation Principle)

1、客户端不应该依赖它不需要的接口。
2、类间的依赖关系应该建立在最小的接口上。

Clients should not be forced to depend upon interfaces that they don`t use.
The dependency of one class to another one should depend on the smallest possible.

注:该原则中的接口,是一个泛泛而言的接口,不仅仅指Java中的接口,还包括其中的抽象类。

6. 依赖倒置原则(Dependence Inversion Principle)

1、上层模块不应该依赖底层模块,它们都应该依赖于抽象。
2、抽象不应该依赖于细节,细节应该依赖于抽象。

High level modules should not depend upon low level modules. Both should depend upon abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions.

猜你喜欢

转载自www.cnblogs.com/yeahwell/p/13388140.html