普陀营销型网站建设,医院网站源码php,贸易公司注册需要什么条件,seo广告平台【代码精进】| 总结/Edison Zhou作为一个后端工程师#xff0c;想必在职业生涯中都写过一些不好维护的代码。本文是我学习《代码之丑》的学习总结#xff0c;今天第一天发车#xff0c;先来看看在命名上的一些常犯的坏味道。0为何要品代码坏味道Martin Flower在《重构》一书… 【代码精进】| 总结/Edison Zhou作为一个后端工程师想必在职业生涯中都写过一些不好维护的代码。本文是我学习《代码之丑》的学习总结今天第一天发车先来看看在命名上的一些常犯的坏味道。0为何要品代码坏味道Martin Flower在《重构》一书中给不好维护的这一类代码取了一个艺名代码的坏味道而这些坏味道一旦堆积多了整个系统虽然还是可以平稳运行但是就是让程序员不敢动更别提重构了。因为......哎都是打工人谁容易啊1不精准的命名直接来看一段坏味道代码public void ProcessChapter(long chapterId)
{Chapter chapter _repository.GetChapterById(chapterId);if (chapter null){throw new ArgumentException($Unknown chapter [{chapterId}]);}chatper.TransactionState TransactionState.TRANSLATING;_repository.UpdateChapter(chapter);
}
此段代码存在的问题方法名ProcessChapter命名过于宽泛不能精准描述意图是代码难以理解的根源所在。同类型的词汇请各位看官自查例如data,info,flag,process,handle,build,maintain,manage,modify等等等它们应该都出现在你我的项目代码中过。重构方法命名需要能够描述出这段代码在做的事情根据代码的逻辑含义调整其命名为 ChangeChapterToTranslating是不是无论谁来接手这个方法的代码就都好理解了public void ChangeChapterToTranslating(long chapterId)
{......
}
一个好的名字应该是描述意图而非细节的。那么我们再重构一下结合具体的业务将其命名改为 StartTranslation即开始翻译是不是就更能体现业务含义了public void StartTranslation(long chapterId)
{......
}
2用技术术语命名这是一个我也经常犯的坏味道ListBook bookList service.GetBooks();
这个bookList的原因是因为它的类型是List还有xxxDictxxxMap等它不费脑子但它却只是一种基于实现细节的命名方式。重构方法使用面向意图的名字。ListBook books service.GetBooks();
又如如果在业务代码中出现了Redis这类的中间件public Book GetByIsbn(string isbn)
{Book cachedBook redisBookStore.Get(isbn);if (cachedBook ! null){return cachedBook;}Book book service.GetByIsbn(isbn);redisBookStore.Put(isbn, book);return book;
}
通常来说这里只是需要一个缓存那么Redis也就只是这个缓存的一个具体实现如果换为其他的NoSQL存储如Memcached呢因此我们其实缺少了一个模型在这里其实就是一个接口假设这个接口如下public interface ICacheClient
{object Get(string key);void Put(string key, object value);
}
使用接口替代之后我们就是面向接口编程了public Book GetByIsbn(string isbn)
{Book cachedBook ICacheClient.Get(isbn);if (cachedBook ! null){return cachedBook;}Book book service.GetByIsbn(isbn);ICacheClient.Put(isbn, book);return book;
}
技术人喜欢用技术名词命名因为这是大家习惯的语言。但是对于业务项目而言需要尽可能将技术术语隔离开因为业务语言才是最好的命名方式。DDD领域驱动设计方法就号召我们建立统一语言这个统一语言是可以和业务部门的人员无障碍交流的语言换句话说也就是业务语言。另一方面来看这就倒逼技术团队需要建立团队的业务词汇表让团队成员达成统一共识这也是要统一共识需要付出的额外成本但是这个成本是有价值的。编写可维护的代码之路比如我们经常会写下面的参数命名public void ApproveChapter(long chapterId, long userId)
{...
}
假设通过业务分析这里的user其实是审核人而我们为了方便就命名为userId了。那么将其改为reviewerUserId是不是更加贴近业务public void ApproveChapter(long chapterId, long reviewerUserId)
{...
}
在实际开发中这样子的例子还有很多。3乱用英语来命名作为一个受了多年义务教育与高等教育的我们来说English一点也不陌生但是就是始终感觉用不到位。如果能用中文来命名我们是不会到处查单词用英文来命名的但是用中文没有B格啊我放弃违反语法规则的命名类是一个名字表示一个对象。而方法名一般是一个动词或动宾短语表示一个动作。但是有时候我们喜欢忽视这个规则。public void CompletedTranslate(Liststring chapterIds)
{ListChapter chapters _repository.GetByChapterIds(chapterIds);chapters.ForEach(chapter chapter.TranslationState TranslationState.TRANSLATED);_repository.SaveChapters(chapters);
}
CompletedTranslate 是个啥四不像结构改为 CompleteTranslation 是不是好一点动宾结构?public void CompleteTranslation(Liststring chapterIds)
{......
}
又比如一个方法名叫 ReTranslation额Translation好像是个名词吧意为重新翻译但作为方法名应该选择动词改为 ReTranslate 会更好Translate是个动词棒。不准确的英语词汇由于英文单词可以有多个含义且在不同场景下含义也可以不同这就难为我们中国人了。比如下面的一个枚举想表达的是审核状态public enum ChapterAuditStatus
{PENDING,APPROVED,REJECTED
}
但是Audit这个词虽然也有审核的含义但是它更偏重于财务审计这块而这里的业务是文稿的审核。因此改为Review可能会更加贴近一些public enum ChapterReviewStatus
{......
}
从上也可以看出技术团队建立一个统一的业务词汇表很有必要这是集体的智慧而非个体的。一个人的英语可能不太好但是一群人在一起总有那么一个会找出合适的说法。英语单词拼写错误这个我相信大家各自项目中都有不少拼错的案例很多人查了单词之后都还是拼错... 但是往往很多时候就是差了或者多了那么一个字母就会让人懵逼了。4小结本文总结了命名相关的两类坏味道一是命名是否具有业务含义二是命名是否符合英语语法。最后感谢郑晔老师的这门《代码之丑》课程让我受益匪浅我也诚心把它推荐给关注EdisonTalk公众号的各位童鞋参考资料郑晔《代码之丑》推荐订阅学习Martin Flower著熊杰译《重构改善既有代码的设计》推荐至少学习第三章????扫码订阅《代码之丑》????点击购买《重构改善既有代码的设计》年终总结Edison的2020年终总结数字化转型我在传统企业做数字化转型C#刷题C#刷剑指Offer算法题系列文章目录技术管理IT技术人的技术管理学习进阶商业知识IT技术人的底层商业知识兵器库.NET大会2020年中国.NET开发者大会PDF资料????扫码关注EdisonTalk不变的依旧是分享
