摘要：
第九章主要讲的是估算，也就是在项目开始前，对时间、资源、成本等做一个大致的预测。作者认为，估算不是瞎猜，而是一种需要学习和练习的技能。估算能帮你避免意外，比如老板问你“这个功能多久能做完？”，如果你随口说“三天”，结果做了一周还没完，那就很尴尬了。好的估算能让你对项目的可行性有直觉，知道哪些事能做， 阅读全文
posted @ 2025-12-30 17:24
很温和
阅读(0)
评论(0)
推荐(0)
摘要：
这一章的核心思想大概就是，一个成功的项目不仅仅是代码的堆砌，更是一个系统工程。它强调了团队协作、流程自动化和持续改进的重要性。作者认为，团队应该像注重实效的程序员一样，遵循相同的原则，例如不留下“破窗”（即及时修复小问题）、保持代码的整洁和正交性，以及避免重复劳动。为了达到这个目标，作者提出了几个关 阅读全文
posted @ 2025-12-30 17:24
很温和
阅读(0)
评论(0)
推荐(0)
摘要：
第七章主要讲的是项目启动前必须搞定的那些“大问题”，就像盖房子前得先打好地基一样。作者认为，如果这些问题没想清楚，项目从一开始就注定要失败。这一章的核心思想是，在动手写代码之前，得先搞清楚用户到底要什么。作者管这叫“挖掘需求”，而不是简单地“收集需求”。因为用户说的往往不是他们真正需要的，你得像侦探 阅读全文
posted @ 2025-12-30 17:23
很温和
阅读(0)
评论(0)
推荐(0)
摘要：
第六章主要讲的是在写代码时应该注意什么。作者说，写代码不是机械活，得动脑子，不能靠运气。首先，作者提醒我们不要“靠巧合编程”。意思是，不能因为代码碰巧能跑通就不管了，得搞清楚它为什么能跑通。不然，以后改代码时，可能会莫名其妙地出问题。接着，作者教我们怎么估算代码的速度。他介绍了“大O表示法”，帮我们 阅读全文
posted @ 2025-12-30 17:23
很温和
阅读(0)
评论(0)
推荐(0)
摘要：
这一章主要探讨了如何通过“解耦”来达到这个目的。解耦就是减少代码各个部分之间的依赖关系，让它们能够独立地变化。作者首先介绍了“得墨忒耳法则”，它建议一个对象应该只和它最直接的朋友打交道，不要直接去调用朋友的朋友，这样可以避免牵一发而动全身的连锁反应。接着，作者提出了“元程序设计”的概念，认为应该把那 阅读全文
posted @ 2025-12-30 17:23
很温和
阅读(0)
评论(0)
推荐(0)
摘要：
这一章的核心思想是，程序员必须承认一个残酷的现实：完美的软件是不存在的。既然我们无法写出毫无瑕疵的代码，那么就必须采取一种“偏执”的防御性策略，来应对必然存在的错误和不确定性。作者将这种策略比作防御性驾驶。在开车时，我们不仅要遵守交通规则，还要时刻警惕其他司机的错误，并提前预判可能发生的意外。同样， 阅读全文
posted @ 2025-12-30 17:23
很温和
阅读(0)
评论(0)
推荐(0)
摘要：
这一章的核心思想是，工具能极大地提升你的能力，而掌握这些工具，让它们成为你双手的延伸，是提高生产力的关键。作者首先强调了纯文本的重要性。纯文本是人能直接阅读的格式，它比二进制格式更持久、更灵活，几乎所有的工具都能处理它，这为自动化提供了极大的便利。接着，作者推荐大家熟练使用命令行。与图形界面相比，命 阅读全文
posted @ 2025-12-30 17:22
很温和
阅读(0)
评论(0)
推荐(0)
摘要：
这一章的核心思想是，程序员必须承认一个残酷的现实：完美的软件是不存在的。既然我们无法写出毫无瑕疵的代码，那么就必须采取一种“偏执”的防御性策略，来应对必然存在的错误和不确定性。作者将这种策略比作防御性驾驶。在开车时，我们不仅要遵守交通规则，还要时刻警惕其他司机的错误，并提前预判可能发生的意外。同样， 阅读全文
posted @ 2025-12-30 17:22
很温和
阅读(0)
评论(0)
推荐(0)
摘要：
这一章讲的是一个优秀的程序员应该具备什么样的心态。不能只把自己当成一个敲代码的机器，而是要对自己的工作、甚至整个职业生涯负责。首先，别找借口。书里一开头就举了个例子，说“我的源码让猫给吃了”，这听起来很可笑，但现实中我们常常会找各种理由来推卸责任。注重实效的程序员不这么干，他们直面问题，出了问题就解 阅读全文
posted @ 2025-12-30 17:21
很温和
阅读(0)
评论(0)
推荐(0)
浙公网安备 33010602011771号