【转载】顶级程序员的10条最佳实践
前言：很无耻的转载了，主要是觉得说得还不错的，另外我附加一些自己的感想，如果原文版权方看到了，可以要求我删除原文部分，谢谢！
1、慎重选择第1门语言
编程语言各有不同，不过区别不大。但用语言的人区别就大了。选择了一门语言你就选择了一个群落。
– Sam Kaufman，自由职业者，iOS 开发者，10x management
如果你想快速建立原型（尤其对于希望对产品进行迭代升级的创始人来说），那就用 Ruby 或者 Javascript。
– Erin Parker，Spitfire Athlete 创始人兼首席开发者
Charles：我觉得第一条真是金玉良言啊，有时候，真的选择了一个编程社区，对你的影响，比选择了编程语言要严重得多。我第一门学习的编程语言是小霸王的Game Basic，但是浅尝辄止，然后是VB，然后是Pascal，从Pascal开始被语言后面的文化影响，比如Pascal在中国上海的文化，就是竞赛专用语言，所以你学这个东西的时候，会接触竞赛，认识一堆竞赛的人，了解一堆后面的故事。后面大学了，学了C/C++，但是很惭愧，没学到能了解后面社区的程度，直到我误入了PHP这个大坑，社区里高度良莠不齐，功利主义，被同学鄙视。不过我这里还想补充下，慎重选择第一门语言，没错，但是选一门，比踌躇不前要好多了。看知乎很多同学问，学编程，是选A还是选B，底下一片争论。有这空闲都学会了。
2、你不是程序猿！
伟大的开发者能够建构并开发应用。惊艳的开发者能够在关注业务的同时做这件事。业务端的人大都不懂编码，但是肯定能够理解特定功能背后的动机。
别人说什么开发者就做什么，没有去理解为什么要这么做，导致双方均错失了机会，这样的事情太常见了。
– John Coggeshall，自由职业者，web 开发者，10x Management，PHP 核心贡献者
精通编程是一个崇高的职业目标。一旦实现了这个目标，别忘了考虑一下你自己。不要成为任何公司的奴隶或者在毫无价值的东西上浪费你的时间。
— Greg Sadetsky， Python 及 Javascript 专家，10x Managemen；协同办公空间 Abri.co 创始人
要想按期完成，得在开始技术工作之前事先进行项目沟通（哪怕这并非先决条件），因为其他人的响应速度千变万化。
– Andrew Wilcox ，web 应用开发者，Meteor 核心贡献者，10x Management
Charles：我个人的体会是，想要做到这一点，应该尽量选择自己喜欢的东西。爱编程这个行业，爱自己做的产品，你就容易上心。我身边的氛围算是一般的，给我感觉就是数名同事满足于完成任务。工作对他们来说是职责所在，没什么所谓的事业心这种东西，大家都在捍卫自己的职责，有了扯皮，没了热情，做东西都妥协。要么就一味服从。爱行业，爱产品，很难说对业务毫无兴趣，怎么可能呢？
3、保持敏捷，不断交付
早发布，不断发布，边说唱边发布。
– Max Nanis ，自由职业者，web 开发者，生物信息学专家，10x Management
不断测试。好的测试包如保单和煤矿里的金丝雀之结合。它能帮助你在生产周期中更早地找出错误，而错误越早发现越容易解决。
– Jeremy Green，自由职业者，web 开发者，专长 Ruby on Rails，10x Management
快速失败。编码（及生活）时我希望尽早知道什么地方不能工作，而不是放任不管让它增殖扩散。全面放开，快速失败，修补缺陷，不断继续。
– Stephanie Volftsun，Knotch 联合创始人兼 CTO
为所有代码编写自动测试！尽可能践行测试驱动的开发。
– Zoran Kacic-Alesic，Industrial Light & Magic 研发主管
Charles：这点我是没有做到过，也没有尝试过的。但是我近年在GitHub看这种项目，都带一个build pass的小徽章，那是持续集成系统提供的状态查询，可以这么猜测，持续集成，测试驱动，自动化测试已经是非常广泛和普遍接受的理念了，只是中国的软件开发领域里，这么实践的着实不多，这让我挺遗憾。希望后续能在团队中摸索尝试和推广。
4、保持对测试流程的控制
许多项目深受多测试周期之苦。这会拖累项目，导致组织整体出现高级别的问题。
程序员应该专注于对自己的代码进行单元测试及半回归测试。他们比其他任何人更了解代码库，也知道自己会影响到哪些变更。有时此类变更会由于 QA 测试范围有限而缺失，因此导致生产环节出现重大问题。
– Sanjib Sahoo，tradeMONSTER CTO
要想在力所能及的情况下尽快开发出无缺陷代码，永远永远也不要把写测试放到后面。我们更清楚这一点。要检查一下测试的覆盖率，确保 100% 无死角。
– Seth Purcell，Signpost 工程副总裁
Charles：这个不怎么看得懂，估计我是在测试团队建设比较差的项目里，完全感觉不到这些。
5、如果你是自由职业者，要学会说不，哪怕面对的是金钱
要对时间和成本有一个合理的评估，然后把它加倍。如果大家都说“这应该很简单，”那就做
– Ryan Waggoner ，自由职业者，web 及移动应用开发者，10x Management
Charles：工作这么多年，仍旧没学会的一点，就是开发估时，基本上每次估时不是过多，就是过少。所以我基本倾向于估时过多一点，这样我可以提前完工，不然我就只能加班了。
6、荣誉属于过去—理论是一回事，但实践更重要
改进软件开发质量的最好方式就是去开发软件。许多雄心勃勃的刚入门的工程师花了很多的业务时间去读书，关于最新工具的、关于开放流程的，诸如此类的东西。
很多人都是这么消磨自己的闲暇时间的，但这样很容易就把你给耽搁了。别这样，通过尽可能用脑来强化大脑负责开发软件的那部分。
–James Cropcho，General Assembly 的 Ruby on Rails 专家及讲师
不断探索。我见过的许多编码者手上都有几个在进行的业务项目。做业务项目迫使你要探索新技术然后学习创建应用的方方面面。你可能需要做前端的 HTML/CSS，后端的 API 集成，数据库优化，做移动 app，还得设置自己的服务器。
– Andrew Waage，Retention Science CTO 及联合创始人
Charles：这条告诉我们，怎么做全栈程序员，有自己的热爱的项目，什么都自己动手。
7、结对评审是你的秘密武器
结对编程非常必要。两个程序员联合开发同一个模块可以相互审查对方的代码。开发团队每周也要召开代码审查会议，让每一个开发者给其他人的代码提供反馈意见，解释如何更好地改进代码。这能够形成一种协作文化，把开发者的自负抛开！
– Sanjib Sahoo
Charles：没试过，第一次听说时候，我第一个疑虑是，这样人力要除以二了，后来一个十八摸过来的同学告诉我，其实不是，他说，你想想你在电脑前浪费了多少时间，另一个人盯着你的时候，你不会那样浪费时间，其实，两个人结对，可以当三个人用，哪个有魄力的领导敢试试么？
8、像躲瘟疫一样避免过早优化
只有在问题和解决方案都出现在你面前时才进行重构—过早重构是时间上的巨大浪费。不要投入半年后可能被扔掉的任何东西的完善上。过早优化是罪恶之源。
–Seth Purcell
不要过早优化！我不断看到工程师在用户还没有到 1000 的时候一再对扩充到 100 万的用户规模担心。
– Mariya Yao，Xanadu Mobile 创始人兼创意总监，移动开发者及设计师
Charles：在我厂，能做到大的业务，没几个，但是你为了升级不得不具备做大业务的能力，所以，就算你的业务不大，你也不得不思考，大了以后怎么办，然后把这些功夫都做足，才能取得足够的经验。有的时候，理论和事实都是违背的。所以，我的建议是，找一个快速增长的明星业务，就可以避免过早优化。
9、你的代码只写一次，可别人会读它千万遍
你写的代码机器会解析执行，可其他人却需要读你的代码，理解它，摆弄它。你必须明白，你的代码会有未来的观众。代码也是一种书写形式的沟通。
– Tracy Chou，Pinterest 软件工程师
听起来很奇怪，但是你永远都得替自己的未来着想。问问自己：如果你有健忘症的话，你还能不能理解自己写过的代码？
– Wai Ching Jessica Lam，Sugarbox 联合创始人兼 CTO
通读你的文档。设计改动很多，有时候代码更新的时候注释不一定会跟进。保持文档的更新，未来的人（包括你自己）理解起来就更容易。我说不清有多少次我看回自己代码时总在想：“我到底在干什么？”只要我写出了好的注释，未来头疼就少很多。
– Kitt Vanderwater，Google 软件工程师
Charles：注重代码可读性超过注重一切其他的，是我一直推崇的，一段效率很差的代码，如果可读性很好，大牛分分钟就能给你搞好，但是可读性很差的代码，只要有一点小bug，别人都很难给你改对了，甚至你自己都改不对。写代码时候，我就问自己，一年后加入看到这么一句话，我还懂么？不懂就换个写法，最无奈的时候，就写一段中文在那里，解释一下这个代码到底在干什么。
10、这是一个崇高的职业。把你的技能用到好的地方。
帮助他人是深层次的人类需求。想办法用你的工作来改善人类，你就会有成功的把握。
– Greg Sadetsky
Charles：程序员拥有这点自豪感，是最基本的。