很多人一开始学编程，都觉得软件工程就是写代码。只要功能跑通了，就算完成任务。但读完《构建之法》前几章，我最大的感受就是：写程序和做软件，完全是两回事。
书里反复强调一个观点：软件不只是代码，还要考虑用户、需求、质量、维护、迭代。我们在学校里写的作业，大多是“一次性程序”，写完交上去就不用管了。但真实世界里的软件，要长期运行、多人协作、不断更新，这就需要一套规范、流程和思维方式，也就是“工程思维”。
书中讲的个人技能，让我印象最深的是代码规范、单元测试、代码复审。以前我写代码，怎么方便怎么来，变量名随便起，结构想到哪写到哪。自己看没问题，别人一看就头大。而真正的工程开发，首先要保证代码可读、可改、可维护。规范不是束缚，而是降低协作成本。
单元测试更是颠覆了我以前的习惯。过去都是先写代码，最后随便测两下。书里却说，测试应该和代码同步写，甚至先写测试再写代码。这样做的好处是，从一开始就保证功能正确，后面改代码也不怕把原来的功能改坏。很多bug不是能力问题，而是没有提前预防。
代码复审也让我明白，优秀的软件不是一个人闷头干出来的。别人能轻易看出你发现不了的问题，比如逻辑漏洞、边界情况、冗余写法。互相审查，既是帮别人，也是提升自己。一个人再厉害，也有思维盲区。
读完第一部分，我意识到：一个好的工程师，不是写得快，而是写得稳、写得规范、写得让人放心。我们不能只停留在“实现功能”的层面，而要学会对整个软件的质量负责。从变量命名到文件结构，从测试到文档，每一步都体现专业度。未来不管是做项目还是工作，这种严谨的习惯，都会成为我们最核心的竞争力。