你也许曾经想过要学习如何开发软件—或只是想临时的写出一个脚本—但不知道如何入手。 幸运的是，现在的互联网上到处都有丰富的学习资源让你能在短时间里成为一个程序员。

因为互联网的出现，使程序员们可以通过它讨论软件开发技术，发布学习指导，以及共享代码实例让其他人可以在线学习。 如果你感兴趣如何才能成为一个程序员，从网上这些大量的优秀的培训资料、学习向导入手将会是个不错的开始。 » 阅读全文：程序员101：如何自学编程

我收集各式各样的至理名言。最近我一直在研究敏捷软件开发；有收获吗？下面就是能够指导敏捷软件开发团队的26条核心原则。

• 用例一完全能够运行后再开发用例二。厨房里有一种说法正好可以印证这个问题：“做好一盘菜后你再做下一盘”． 对于软件开发来说一个最大的问题就是人们喜欢并行开发多个任务。因为不可避免的，我们设计的功能中总会有一部分会被放弃砍掉，如果提前开发，很可能做无用功。 一次只开发一个用例（或很少几个用例，这根据你的开发团队的大小而定）； 让这个用例功能完整； 让相应的测试用例都能通过； 相应的文稳都补齐； 只有在当前的用例完全开发完成后，才做为一个整体提交到版本库，才进行下一个用例。
• 避免提交一个半成品。 这一点大家似乎都知道，但这条原则必须列入任何一个开发指导里。 能够听取这些忠告进行开发测试然后提交代码的程序员一定不会发生代码提交到版本库使整个项目无法编译码通过情况。 如果系统编译失败，那一定是有人抄近道到了。
• 不要在还没有任何使用案例的情况下设计通用模块。 只有在你知道有具体用例的情况下，你才可以实现一个具体的类，而且你在该类中只应该实现当前该用例需要的方法。 你也许会想到将来这个类会有其它的用途，你可以用注释的方式记录一下，但不要去实现它，只有在有了具体用例后你才可以实现它。
• 一定不要在没有使用例的情况下往类里添加成员方法。 这跟上面一条极其相似，除了这里针对的是数据成员。 开发人员很容易想到：一个‘客户记录’里应该有‘送货地址’的信息，但一定不要在没有任何用例要求这个属性的时候实现这个属性。 » 阅读全文：关于敏捷开发的26个心得

在 SDTConf 2009 论坛上，Corey Haines 和我共同主持了一个叫做“最臭的臭弹”的研讨会。会议上，我们试图去寻找下面两个（不同的）问题的答案：

• 作为一个经验丰富的开发人员，回顾往事，最臭的让你最受折磨的代码是什么样的？也就是说，请指出一种代码，如果你能根除掉这种很臭的代码，那么在你的程序中的大部分设计问题都会迎刃而解
• 我们有如此多的不同的原则和指导来帮助我们去实现好的设计。对于一个新手来说，他应该从哪里开始？哪种代码风味（code smell）或原则，对于一个新手来说，可以最大程度的帮助他们做出好的设计（节省好几年去总结经验）？

尽管字面上这两个问题很相似，但我认为这第二个问题更具有广泛的意义，跟第一个有很大的不同。

不管怎样，这次研讨会都能称得上是一个热闹的会议。我们有不少很厉害的辩手来批判所谓的最臭的代码的味道（最臭的臭弹）： » 阅读全文：最臭的臭弹（Biggest Stinkers）

我遇到很多客户做过压力测试 – 有大规模的，也有小规模的 – 有用开源工具的，也有用商业软件的。 压力测试本身变得越来越容易，越来越可以支付的起——因为出现了很多很好用的压力测试工具。还有一些公司提供在线压力测试服务。尽管做压力测试越来越容易、越来越有效率、而能花很小的代价产生很大的压强，但是我的所有客户都遇到了同样一个问题：压力测试并不会报告是什么导致了问题。它只会报告这有了问题，例如：查询页面在并发50个用户使用时变慢下来，但它不会显示什么导致了变慢。捕获到的性能统计数据例如CPU和内存使用量只是强调了潜在的问题区域，但并不会指出实际的根源在应用程序的什么地方。
» 阅读全文：为什么压力测试会耗费我们如此多的时间