《系统分析师UML实务手册》读后感一
最初我喜欢这本书可能是因为非技术方面的原因，这本书中有很多我喜欢的插图。这本书的第一章的第一句话是这样说的：读这本书通常有两个原因：1. 你是一名程序员。2. 你想成为更好的程序员。我们需要更好的程序员。
这本书的每一章都可以总结出一句话，其实每章开始的插图就是这句话的浓缩。
本书的第一章是关于什么是整洁代码的讨论，引用了Bjarne Stroustrup（C++之父）、Grady Booch（UML的创始人之一）等人当然也Bob大叔（本书的作者Robert Martin）自己对整洁代码的理解。
不管是现实世界还是软件项目中，命名都是一件让人头疼的事情，给小孩起过名字的就知道，你希望把你对孩子的期望包含在这个名字中，你又希望这个名字读起来要好听，至少不至于将来成为别人的笑柄（比如庞光大、魏升京这样的名字），可能你还要考虑族谱班辈的排列等等。软件项目中的命名情况会更加复杂，简单的说命名的原则是"见名知意"，当然你还需要用各种方式防范命名冲突的问题，不同的编程语言也有自己不成文的像契约一样的命名规则和方式（例如匈牙利命名法），这些可能都是需要考虑的事情。我个人并不喜欢匈牙利命名法，加上一个类型前缀的感觉就是永远和这个东西绑定到一起了，就如同用C语言的malloc函数分配内存创建一个能放100000个元素的数组，你愿意用下面哪种写法呢？记住：好的名字相当于为代码写了一段有用的注释。
int* myArray = NULL;
/* 写法1 */
myArray = malloc(100000 * sizeof(int));
/* 写法2 */
myArray = malloc(100000 * sizeof *myArray);
第三章讲的是函数，说了这么一句话："Function should do one thing. They should do it well. They should do it only. "（函数只应该做一件事情，把一件事情做好，而且只由它来做这一件事情），听起来很简单的一句话但是要践行这条原则却并不容易，所以我们的代码中才会有很多的坏味道（请参考《重构：改善既有代码的设计》一书的第三章）。事实上，上升一个层次，我们在设计类的时候也应该如此，这是面向对象设计原则中说的单一职责原则（SRP），当我们的代码中出现了冗长的方法或者巨大的类的时候，我们就应该依据职责来对其进行拆分，这样程序的结构才会趋于合理，最终达到"高内聚"的目标。当然，这一章里面还提到很多理念，包括：Command Query Separation（一个方法要么执行某种命令，要么返回查询数据）、DRY（不要重复自己）、Prefer Exceptions to Returning Error Codes（异常优于返回错误码）等。
【推荐】国内首个AI IDE，深度理解中文开发场景，立即下载体验Trae
【推荐】编程新体验，更懂你的AI，立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包，你的智能百科全书，全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell：AI 加持，快人一步
· Linux系列：如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列：如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列（二）：开始使用ML.NET
· 被坑几百块钱后，我竟然真的恢复了删除的微信聊天记录！
· 没有Manus邀请码？试试免邀请码的MGX或者开源的OpenManus吧
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· Docker 太简单，K8s 太复杂？w7panel 让容器管理更轻松！