happydeer-CSDN博客

翻译无我编程：你的工作不代表你

如果你的工作不代表你，接受别人对你工作的批评就要容易得多了！

2013-12-15 18:45:41 5288 1

原创《程序员的修炼：从优秀到卓越》目录及部分精彩内容

《高效能程序员的修炼》之续集——《程序员的修炼：从高效到卓越》目录1. 绝地反击之术待办事项不靠谱今天上班可以放羊你没有说服我真正失败的项目激情造就天才勿以专家自居行百里者半九十管理中要有信任博伊德迭代法则十年磨一剑 2. 编程之道切忌一根筋破窗理论要么热爱，要么离开简单之美乐于删代码你是程序员这块料吗你循规蹈矩吗科里定律：坚守一个目标最牛的编码套路孤独的人是可耻的你有编程伙伴吗软件

2013-12-13 08:52:52 7265 7

翻译别盲目听从你的用户

你的应用程序或网站开始以一种合理的方式收集有用的用户活动数据了吗？忽略用户反馈可能让你最终难逃失败的命运，但盲目地听从每一个用户的请求也会让你必败无疑。

2013-12-11 10:17:02 3599 1

翻译一个好的创意值多少钱？

如果你想取得成功，不要再担心没有伟大的创意了，转而去专注于培养卓越的团队吧！

2013-12-11 08:41:07 7511 11

翻译你的团队能通过电梯测试吗？

你团队里的每个人都应该能通过由陌生人主持的“电梯测试”——在60秒之内，清晰地解释他们在做什么，以及为什么人们会在意他们正在做的事情。

2013-12-09 08:25:46 8088 8

翻译最有效的一种技术领导是“以身作则”

对于软件开发者来说，以哄骗或痛斥的方式让他们服从不是一个有效的激励方法。如果你想提高团队的工程水平，你需要一个领导，而不是靠一个训导员去强制执行。

2013-12-07 07:34:24 5297

翻译磨刀不误砍柴工

作为一名软件开发人员，你该如何磨快你的锯子?

2013-12-07 07:24:45 9878 24

翻译费茨定律的另一面

如果我们想要用户点击某些UI元素，为了获得最大的点击率，我们应该把它们做得大一点，并且尽可能把它们放在屏幕的角落或边缘。接下来的问题是，如果我们不想让用户点击某些UI元素，我们应该做些什么呢？

2013-12-06 08:45:03 5299

翻译科里定律：坚守一个目标

科里定律告诉我们：每一个变量，每一行代码，每一个函数，每一个类，每一个项目都应该坚持一个目标。遗憾的是，我们通常要等到最后结束的时候才会发现那个目标。

2013-12-05 08:28:50 4405 3

翻译程序员：孤独的人是可耻的！

喜爱软件开发的人，是不是那些宁可与计算机打交道也不愿意与人打交道的反社会、反人类的人呢？如果是这样的话，随之而来的问题是，所有的软件项目最好都由一个人来独自完成吗？

2013-12-03 12:42:21 8715 15

翻译最牛B的编码套路

当你能编写精彩的代码、并且能用精彩的言辞向世人解释那些代码时，到那时候，我会觉得你已经掌握了最牛的编码套路！

2013-12-02 08:38:14 57237 147

翻译培训有用吗？软件行业应采用“学徒制”

晚上学习理论，白天编程工作——这种组合方式特别有效。

2013-12-01 09:27:44 12303 44

翻译你按照涂料桶上的说明做了吗?

在过去的很多年里，软件开发一直是这种被粉刷坏的房子的缩影。但是现如今，软件开发领域已经足够成熟了，我们已经有了好些个可供参考的“涂料桶”。

2013-11-28 09:48:06 3701

翻译 UI设计切忌墨守成规，但改变也须用数据说话

就编码而言，协调一致总是优于标新立异；但如果说到用户界面，一致性却并不总是好的。用户界面应该内部保持一致，但横向与世界上的其他应用程序保持一致就没必要了。

2013-11-27 11:04:54 3651

翻译删代码的乐趣

我曾经不止一次地被指责说我删除了别人注释掉的代码。我说，如果你能给我一个不删除的理由，那我就不会再删了。否则，我认为这是很正常的事情。

2013-11-26 20:01:55 5195 12

翻译对于编程：要么热爱，要么离开

最近，有人在JoelOnSoftware.com论坛上发了一个帖子，题为“Thinking of leaving the industry”（考虑转行）——面对如此不确定的经济大环境，某程序员想知道选择软件开发作为职业是否正确...

2013-11-26 09:03:48 11286 13

翻译成为优秀程序员的方法就是抛开编程？

你的兴趣爱好越广泛，你就越能胜任你的工作。

2013-11-25 17:33:26 14458 62

翻译 Jeff Atwood质疑iPhone的单键设计

我喜欢使用iPhone，但我对它的一个设计不敢苟同：苹果始终坚持，设备的正面永远只能有一个按键。单单一个按键要控制多少东西啊！功能过载了！我现在都害怕使用iPhone的“Home”键了，因为它“让我思考”。我很多时候都在误操作。事情本不应该是这样的！

2013-11-25 09:15:22 3621 8

翻译基于用户行为数据进行持续的产品创新

亚马逊如何进行快速的创新？在可用性方面，为了超越靠猜测行事，你必须去观察用户如何使用你的软件，除此之外别无他法！

2013-11-23 14:31:31 4164

翻译可用性并非阳春白雪

写代码？这个环节的工作其实不难。开发出人们真正想用的应用程序，然后把它们发布到用户手上，这才是难事！如果你的项目里没有人关心可用性，那么你的项目注定会失败。

2013-11-21 08:59:53 2744 3

翻译 Jeff Atwood：Google的头号UI问题

谷歌在用户界面上追求的“极简主义”是让人叹为观止的。但是，真有人在使用“I'm Feeling Lucky”（手气不错）这个功能吗？

2013-11-18 08:55:34 3163

翻译 UI设计——最后一根稻草

如果你想再加一个什么UI元素，请确信，你所加的那个UI元素不是压倒骆驼的最后一根稻草。

2013-11-14 08:39:43 2880

翻译敢于说不

创新并不是要接受所有的东西，而应该对除了关键性功能之外的所有东西统统说不。

2013-11-13 08:39:11 3326 1

翻译用户界面很难做

我无意评论“女程序员不懂情调”；我的意思是，对“大部分程序员不擅于设计用户界面”的指责不无道理。

2013-11-11 08:45:30 4069 3

翻译象牙塔式的开发

我向来不鼓励象牙塔式的开发模式——开发团队常年封闭在“高塔”之中，一门心思地做着魔法一样的软件。这些开发者根本不知道用户会怎样使用他们做出来的软件。你若问他们，“最近一次面见用户是在什么时候？”他们甚至可能都回答不上来！因为缺失强有力的证据，开发者都假设其他所有人都是开发者。这种想法的危险性就不用我多说了吧！根据我的经验，越是把开发者孤立起来，他们最终做出来的产品就最糟糕。尽管大部分团队都有专

2013-11-11 08:35:16 3417 3

翻译功能越多越好吗？

有时候，我怀疑商业软件当前的模式劫数难逃。乏善可陈的功能被没完没了地堆砌在一起，到头来几乎总是走向灭亡。

2013-11-07 08:28:11 3092

翻译别把产品发布当目标

产品终于开发完成了，发布了，万事大吉了？Oh, no~~~ 这不是终点。别把产品发布当目标！

2013-11-04 09:46:43 2286 3

翻译如何写技术文档

技术文档是怎么写出来的？过程非常滑稽、有趣！

2013-11-02 11:08:55 4769

翻译程序员是“逻辑人”

在软件开发者身上的所有“坏毛病”中，最严重的可能是：我们自以为是典型用户... 任何人都能做出来一个没人会用的复杂软件。这其实并不难！把软件做得容易使用才是需要真本事的！

2013-10-30 09:27:44 5680 7

翻译让程序员设计界面的后果

每个软件开发人员的内心深处，都有一个当美工的小我，而且呼之欲出。但倘若他真的出来了，你就麻烦了。不可避免的是，你的用户也惨了。

2013-10-29 08:56:17 5962 18

翻译异常驱动的开发(Exception-Driven Development)

不管怎么样，软件在发布的时候总是会带有bug的。所有软件都是这样。只要是软件，它就会崩溃，它就可能丢失数据，它还会难以学习、难以使用。问题不在于你在发布软件的时候带出去了多少bug，而在于你能多快地修复那些bug？如果你的团队一直在践行异常驱动的开发模式，答案就很简单了——别担心，我们马上就会改进我们的软件！看着吧，我们会越做越好！

2013-10-25 09:58:49 3150

翻译大多数时候是软件的Bug，但是... 有时候的确是硬件的问题！

尽管软件是不可靠的(这已经臭名昭著了），但我们不能总是把矛头指向软件。有时候，你面对的确确实实是一个硬件问题。

2013-10-23 17:44:09 4853

翻译困惑：单元测试该在什么时候写？

很多年以来，用于随机测试（ad-hoc test）的工具我都是自己开发的。但在最近的一个项目中，我终于采用了NUnit和TestRunner来做正式的单元测试。下面是我编写的第一个单元测试，看起来很简单，而且轻轻松松就通过了：_PublicClass UnitTests Private _TargetString As String Private _TargetDa

2013-09-29 15:22:32 5609 2

原创《高效能程序员的修炼》勘误表(2013.11.16更新)

页码行号2013年7月第1版译文建议的修正备注58我只是想说…这一段须用楷体这段话是那位律师说的，须用特殊字体标出192将得不到真正的进步你将得不到真正的进步加入主语“你”使句子更通畅21

2013-08-15 18:17:43 3560 6

翻译 YouTube上的版权保护

YouTube网站上90%的内容都是有版权的，而且很显然在这些内容的使用上并没有得到授权——基于这个现实，我们该怎样去理解YouTube在版权保护方面的官方立场呢？

2013-08-08 08:49:22 30438 4

转载《高效能程序员的修炼》读后感 By Yong Zhang

想不到我工作中经常GOOGLE搜寻技术问题的stack overflow网站的创办人竟然是本书的作者！看了一遍全书，果然名不虚传。本书更多的从人文角度而非技术角度去阐释了作为一个程序员，应该具备的基本素质，所以在看这本书的过程中，感觉非常轻松并且内容也很通俗易懂，又很贴近工作和生活中的实际，书中通过一个程序员的职业生涯的角度去说明了作为一名合格的程序员，需要具备的基本素质，同时也分享了作者

2013-08-07 10:55:10 2519

翻译纪律造就强大的开发者

最近，Scott Koon谈到了纪律作为开发者的一项基本素质的重要性。他是这么说的：每个月，总有一些新的编程语言或者方法论冒出来。随后，信徒们的溢美之词便会充斥互联网的每一个角落。这些东西貌似都能提高生产力和产品质量。但他们忽略了所有成功的开发者都拥有的一个特质。这个特质足以决定项目的命运。那就是纪律！不受纪律约束的开发者不能保障产品的按时发布，他们也不会写出易于维护的代码。相反，自律的开

2013-08-05 08:47:41 4135 4

转载程序员，你当的了吗？——读《高效能程序员的修炼》有感

想当程序员吗？想做软件开发吗？嗯，单单会写几行代码是远远不够的。

2013-08-02 21:24:29 6542 1

翻译程序员不爱读书，但这很不明智

StackOverflow.com的主旋律之一，就是软件开发者不再照着书本学习编程了。Joel Spolsky曾经提到过：“程序员似乎已经不再读书了。相比于程序员的从业人数，编程类图书市场小得简直不值一提。”

2013-07-22 09:16:05 26131 102

翻译十年磨一剑——一夜成名背后是十年的努力

Gmail的原开发主管Paul Buchheit曾经说过，Gmail的成功是一个漫长的过程：Gmail的开发始于2001年8月，在此之后的很长一段时间里，几乎所有的人都不喜欢它。有一些人因为它的搜索功能而使用它，但他们也带来了无穷无尽的抱怨。甚至有相当一部分人认为我们应该终止这个项目，或者按照一个企业级的产品重做这个项目——它应该有一个本地的客户端程序，而不是这个异想天开用JavaScript

2013-07-17 10:06:35 8381 11

空空如也

空空如也