Varnish开发人员指南¶
这是Varnish开发人员应该知道的事情的特意简短的列表。
行为¶
理智一点。
如果有疑问，就想一想。
如果仍有疑问，请提出要求。
承认你的错误，那样会更快。
你不应该画画 bikesheds.
我们将把您从项目中剔除，而不是添加另一条规则。
技术人员¶
我们的编码风格指南是FreeBSD的 style(9)
有关工具链的开发人员选项，请参阅Autogen.des脚本。
我们总是--Werror，没有无害的警告，只有没有很好地表达意图的源代码。
我们更喜欢源代码，而不是解释发生了什么的注释，这样像FlexeLint和Coverity这样的工具也有机会。
我们的参考平台是Ubuntu和FreeBSD。
断言有负成本，它们节省了开发人员下一次的时间。
我们的许可证是BSD 2条款或更宽松的，没有GPL或LGPL。
花了11年时间才出现第一个重大安全问题，但这太快了。
错误、问题、功能请求和VIP¶
错误、问题和功能请求一开始就是GitHub的问题。
周一15：00-16：00(欧洲时间)，我们在IRC(#Varnish-hking on irc.linpro.no)上进行“错误清洗”，以决定谁和如何处理问题。
我们无能为力的问题已经结束了。
如果功能请求有意义，它们会被转移到维基/VIP页面，直到有人实现它们。
错误的最常见情况是常态，而不是例外。
建筑材料¶
这些规则是从X11项目导入的：
决定一个制度不是什么，和决定它是什么一样重要。
不要满足世界上的所有需求；相反，要使系统具有可扩展性，以便能够以向上兼容的方式满足更多的需求。
唯一比从一个例子中概括更糟糕的是从根本没有例子中概括。
如果一个问题没有被完全理解，最好是根本不提供解决方案。
如果你能用10%的工作量获得90%的预期效果，那就使用更简单的解决方案。
尽可能地隔离复杂性。
提供机制，而不是政策。