mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
68 lines
6.7 KiB
Markdown
68 lines
6.7 KiB
Markdown
六个开源软件开发的“潜规则”
|
|
============================================================
|
|
|
|
> 你想成为开源项目中得意满满、功成名就的那个人吗，那就要遵守下面的“潜规则”。
|
|
|
|
|
|
|
|
正如体育界不成文的规定一样，这些规则基本上不会出现在官方文档和正式记录上。比如说，在棒球运动中，从比分领先时不要盗垒，到跑垒员跑了第一时也不要放弃四坏球保送。对于圈外人来讲，这些东西很难懂，甚至觉得没什么意义。但是对于那些想成为 MVP 的队员来说，这些都是理所当然的。
|
|
|
|
软件开发，特别是开源软件开发中，也有一套不成文的规定。和其它的团队运动一样，这些规定很大程度上决定了开源社区如何看待一名开发者，特别是新加入社区的开发者。
|
|
|
|
### 运行之前先调试
|
|
|
|
在参与社区之前，比如开放源代码或者其它什么的，你需要做一些基本工作。对于有眼界的开源贡献者，这意味这你需要理解社区的目标，并学习应该从哪里起步。人人都想贡献源代码，但是只有少量的人做过准备，并且乐意、同时也有能力完成这项艰苦卓绝的工作：测试补丁、复审代码、撰写文档、修正错误。所有的这些不受待见的任务在一个健康的社区中都是必要的。
|
|
|
|
为什么要在优雅地写代码前做这些呢？这是一种信任，更重要的是，不要只关注自己开发的功能，而是要关注整个社区的动向。
|
|
|
|
### 填坑而不是挖坑
|
|
|
|
当你在某个社区中建立起自己的声望，那么很有必要全面了解该项目和代码。不要停留于任务状态上，而是要去钻研项目本身，理解那些超出你擅长范围之外的知识。不要只把自己的理解局限于开发者，这样会让你着眼于让你的代码有更大的影响，而不只是你那一亩三分地。
|
|
|
|
打个比方，你已经完成了一个网络模块的测试版本。你测试了一下，觉得不错。然后你把它开放到社区，想要更多的人测试。结果发现，当它以特定的方式部署时，有可能会破坏安全设置，还可能导致主存储泄露。如果你将代码视为一个整体时问题就可以迎刃而解，而不是孤立地看待问题。这表明，你要对项目各个部分如何与其他人协作交互有比较深入的理解。让你的补丁填坑而不是挖坑。这样你朝成为社区精英的目标上又前进了一大步。
|
|
|
|
### 不投放代码炸弹
|
|
|
|
代码提交完毕后你的工作还没结束。如果代码被接受，还会有一些关于这些更改的讨论和常见的问答，还要做测试。你要确保你可以准时提交，努力去理解如何在不影响社区其他成员的情况下，改进代码和补丁。
|
|
|
|
### 助己之前先助人
|
|
|
|
开源社区不是自相残杀的丛林世界，我们更看重项目的价值而非个体的贡献和成功。如果你想给自己加分，让自己成为更重要的社区成员、让社区接纳你的代码，那就努力帮助别人。如果你熟悉网络部分，那就去复审网络部分，用你的专业技能让整个代码更加优雅。道理很简单，顶级的审查者经常和顶级的贡献者打交道。你帮助的人越多，你就越有价值。
|
|
|
|
### 打磨抛光才算完
|
|
|
|
作为一个开发者，你很可能希望为开源项目解决一个特定的痛点。或许你想要运行在一个目前还不支持的系统上，抑或你很希望改革社区目前使用的安全技术。想要引进新技术，特别是比较有争议的技术，最好的办法就是让人无法拒绝它。你需要透彻地了解底层代码，考虑每个极端情况。在不影响已实现功能的前提下增加新功能。不仅仅是完成就行，还要在特性的完善上下功夫。
|
|
|
|
### 不离不弃方始终
|
|
|
|
开源社区也有许多玩玩就算的人，但是承诺了就不要轻易失信。不要就因为提交被拒就离开社区。找出原因，修正错误，然后再试一试。当你开发时候，要和整个代码库保持一致，确保即使项目发生变化而你的补丁仍然可用。不要把你的代码留给别人修复，要自己修复。这样可以在社区形成良好的风气，每个人都自己改。
|
|
|
|
---
|
|
|
|
这些“潜规则”看上去很简单，但是还是有许多开源项目的贡献者并没有遵守。这样做的开发者不仅可以为成功地推动他们自己的项目，而且也有助于开源社区。
|
|
|
|
作者简介：
|
|
|
|
Matt Hicks 是 Red Hat 软件工程的副主席，也是 Red Hat 开源合作团队的奠基成员之一。他历时十五年，在软件工程中担任多种职务：开发，运行，架构，管理。
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
via: http://www.infoworld.com/article/3156776/open-source-tools/the-6-unwritten-rules-of-open-source-development.html
|
|
|
|
作者：[Matt Hicks][a]
|
|
译者：[Taylor1024](https://github.com/Taylor1024)
|
|
校对：[wxy](https://github.com/wxy)
|
|
|
|
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
|
|
|
[a]:http://www.infoworld.com/blog/new-tech-forum/
|
|
[1]:https://twitter.com/intent/tweet?url=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html&via=infoworld&text=The+6+unwritten+rules+of+open+source+development
|
|
[2]:https://www.facebook.com/sharer/sharer.php?u=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html
|
|
[3]:http://www.linkedin.com/shareArticle?url=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html&title=The+6+unwritten+rules+of+open+source+development
|
|
[4]:https://plus.google.com/share?url=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html
|
|
[5]:http://reddit.com/submit?url=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html&title=The+6+unwritten+rules+of+open+source+development
|
|
[6]:http://www.stumbleupon.com/submit?url=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3156776%2Fopen-source-tools%2Fthe-6-unwritten-rules-of-open-source-development.html
|
|
[7]:http://www.infoworld.com/article/3156776/open-source-tools/the-6-unwritten-rules-of-open-source-development.html#email
|
|
[8]:http://www.infoworld.com/article/3152565/linux/5-rock-solid-linux-distros-for-developers.html#tk.ifw-infsb
|
|
[9]:http://www.infoworld.com/newsletters/signup.html#tk.ifw-infsb
|