程序员修炼之道第六章主要围绕当你编程时进行论述，这让我想到了自己以前的编程习惯，每次在看到题目后都是直接上手，不做太多的思考，在编程时想到什么就加什么，因此程序总是很乱，自己都看不明白。但是这一情况在经过王建民老师的一次考试后得到了缓解，我也开始在编程前思考大纲，将程序模块化。
编码的时候偶尔会发生这种情况，就是你无意写下的代码让你的程序成功运行，或者说再回过头来看的时候，你并不清楚这段代码到底有什么作用，但这种情况毕竟是少数，因为编码的时候通常都有很强的目的性，如果没有的话是无法达成目标的。可见，这种巧合编程我们不能对其保有依赖性。
之后学习了重构的知识，尽量不要动原先的功能，要采取短小和深思熟虑的步骤。我还学习了做出易于测试的代码，有有单元测试、合约测试等，还有构建测试窗口、使用测试装备。我还明白了不要使用我不熟悉的具有向导价值的代码。不要盲目地进行编程。试图构建你不完全理解的应用，或是使用你不熟悉的技术。就是希望自己被巧合误导。
第七章提出来很多在项目开始之前的准备和一些陷阱。这让我明白了在开始开发之前一定要
深思熟虑和做好充分的准备。我明白了要明白要去挖掘需求，避免不必要的需求，更要建立需求文档，要明确用例图的范围、边界等。在设计需求时，要有发展的眼光看待系统的使用，不能让系统故步自封。我明白了要积极的追踪需求的项目，维护已确定的需求词汇表，要把需求明确的写出来。可以用UML活动图捕捉工作流，而且有时要为手边的事务建模，概念层类图很有用。
在面对棘手的问题时，列出所有在面前的可能途径。不要排除任何东西，不管它听起来有多无用或愚蠢。现在，逐一检查列表中的每一项，并解释为何不能采用某个特定的途径。你确定吗？你能否证明？有时你会发现，自己在处理的问题似乎比你以为的要难得多。感觉上好像是你走错了路——一定有比这更容易地方法！或许现在你已落在了进度表后面，甚或失去了让系统工作起来的信心，因为这个特定的问题是“不可能解决的”
不要做形式方法的奴隶，批判地看待方法学而从中提取精华，融合到每项工作中。 对于无法判断项目是否拖延，可采取一种行之有效的技术构建原型，而对于有困难的地方，可进行“概念验证”。 最可怕的事情：花了几周认真开发，却发现原来只要一个原型。