<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>节奏 on Tony Bai</title><link>https://tonybai.com/tags/%E8%8A%82%E5%A5%8F/</link><description>Recent content in 节奏 on Tony Bai</description><generator>Hugo</generator><language>zh-cn</language><copyright>2004-2026 Tony Bai. 版权所有.</copyright><lastBuildDate>Fri, 03 Jun 2011 00:00:00 +0800</lastBuildDate><atom:link href="https://tonybai.com/tags/%E8%8A%82%E5%A5%8F/index.xml" rel="self" type="application/rss+xml"/><item><title>把握好编码的节奏</title><link>https://tonybai.com/2011/06/03/hold-the-coding-rhythm/</link><pubDate>Fri, 03 Jun 2011 00:00:00 +0800</pubDate><guid>https://tonybai.com/2011/06/03/hold-the-coding-rhythm/</guid><description>最近观察到这样一种情况，项目组内的两位比较资深同事似乎都习惯于这样来编码：他们可能会花上两、三周时间将一个模块的成百上千行代码一气呵成的编写完，然后再去与其他人编写的代码集成在一起编译，测试，最终提交。这种情况让我有些惊讶，因为我觉得一个良好的编码节奏不应该是这样的，原因有三： .这样的节奏不利于问题的早发现早解决 我们都知道问题发现越早，其解决成本越小。如果只是一味地编写代码，甚至连一次编译都不...</description></item></channel></rss>