注册
登录
当我参加Ansible团队今后，我决议写下多年来所学到的软件工程实习和原理方面的经历。我的热情是测验，由于我信任杰出的测验既能够保证最低质量规范(惋惜许多软件产品都缺少这一点)，也能够辅导和塑造开发进程自身。以下许多主张与测验有关，其间一些准则乃至特定于Python，但绝大多数不是。(对于Python程序员，PEP 8应当是编程个性和攻略的第一站。)
1、不要编写你以为今后也许需求但现在不需求的代码。这是对将来幻想的用例的编码，而且这种代码一定会变成死码或需求重写，由于将来的用例老是与程序员的幻想略有不同。 注释代码也是如此，假如一段注释的代码正在进行发布，它不应当存在。YAGNI是编程的中心要素，最好参阅资料是极限编程解析(Extreme Programming Explained)。 2、不进行剩余的测验。根底设施，构造和库是需求测验的，不要测验浏览器或外部库，除非你真的需求。测验你自个编写的代码，而不是别的人写的代码。
3、屡次重复呈现的代码不需求测验。辅佐功用不需求测验，当你把它们分隔并重新运用时，需求测验。假如反复编写相似代码屡次时，您一般会很明白正在处理的疑问。 4、对于API规划(外部面向方针API)：简略的作业尽量简略完结，杂乱的作业极力优化。首要为简略事例规划，假如也许的话，优选为零装备或参数化。Addoptions或附加的API办法，用于更杂乱和更灵敏的用例(根据需求)。 5、尽早查看无意义的输入或无效状况，最好是反常或过错呼应，这将使程序员很明白疑问的确切信息。(除非真的需求，不然不要进行输入验证类型的查看)。 6、在也许的状况下，将测验方针视为黑盒子，经过公共API进行测验，这就不需求调用私有办法或修正状况。
对于一些杂乱的场景，编写测验真的是有协助的，由于这迫使程序员思考代码的做法以及在编写代码今后怎么进行测验。测验首要鼓舞更小、更模块化的代码单元，这一般意味着非常好的代码。 7、对于单元测验(包含根底架构测验)，应测验一切代码途径。 100%的掩盖是一个杰出的初步。除非你无法掩盖一切也许的摆放/组合的状况，只要一个非常好的理由才能使代码途径不全部经过测验，以时刻为托言早晚会糟蹋更多时刻。 8、代码是敌人：也许犯错，需求保护。尽量有更少的代码完成必需的功用，删去不必要的代码。 9、努力经过杰出的命名规范和已知的编程个性使代码可读和构成自我记载。一般跟着时刻的推移，许多程序员都不知道自个写的代码了。 10、代码注释——对一些无法清晰的代码，请尽早供给注释，阐明为啥要这么写，有无别的办法等。 11、编码进程中必须想想也许呈现的疑问，无效输入会发作啥，哪些状况会致使失利，这将有助于程序员在发作过错之前捕获更多过错。
12、简略的逻辑易进行单元测验，将逻辑分化为独自的函数，而不是将逻辑混合为有状况和有副作用填充代码。(测验的开支越少意味着测验更快)。 13、运用方针也许比运用杂乱的数据构造非常好。运用Python的内置类型及其办法将比编写自个的类型更快(除非您在C中编写)。假如思考功用，请测验了解怎么运用规范内置类型而不是自定义方针。 14、依靠写入是一个有用的编码形式，用于程序员搞明白依靠联系以及它们来自哪里(有方针，办法等作为参数接纳它们的依靠联系，而不是实例化新方针自身)。对于依靠写入的文章可参阅Martin Fowler的“Inversion of Control Containers and the Dependency Injection Pattern”。 15、代码越多，代码越差。程序员的方针应当是小型的可测验单元，以及更高档的集成和功用测验，以测验单元是不是正确协作。 16、规划API时应当思考到今后也许会遇到的更改，并思考到将来的用例——真的很主要。改动API对程序员和用户而言都是一种苦楚，而且创立向后的不兼容性是可怕的(尽管有时不可避免)。 17、假如函数或办法超越30行代码，请思考将其分化。最大模块尺寸为500行，测验文件一般比这更长。 18、不要在方针构造函数中作业，这很难测验。不要将代码放在__init__.py中(除了用于命名空间的导入)。 __init__.py不是程序员一般希望找到代码的当地。
19、在测验中，单个测验文件的可读性比可保护性更主要(打破可重用的块)。这是由于测验被独自履行和读取，而不是自个变成较大体系的一部分，明显过多的重复意味着能够为了方便而创立可重复运用的组件，这不仅仅是生产疑问。 21、在处理功用疑问时，请必须在修正之前进行装备。假如你现已剖析并证实代码实际上是值得的，编写一个测验随时对代码进行剖析，而且保留在测验套件中以避免功用回归。(增加时刻码老是会改动代码的功用特征，使功用变成更令人懊丧的使命之一)。 22、更小，更严厉的单位测验在失利时供给更有价值的信息。一般，运转超越0.1秒的测验不是单元测验。单元测验能够供给更详细的过错信息，对于单元测验实习一本不错的书是Gary Bernhardt的Fast Test, Slow Test。 23、遵从YAGNI准则：编写咱们需求的特定代码，而不是不需求的、杂乱性的通用代码。 24、同享代码一切权是方针。不共享或许就发现不了非常好的编写方法，比方共享出来，我们群策群力。 25、最后，能够通知产品司理或开发商，一味地增加功用并不是功德，保证中心功用的高效率作业就能够了。 |
| 本文出处： http://www.toutiao.com/a6429416000266043649/ |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
