随笔 - 217  文章 - 4  评论 - 4  阅读 - 23455

程序员修炼之道阅读笔记之三

程序员修炼之道阅读笔记之三

第七章:在项目开始之前

第三十六节:需求之坑

需求很少放在表面上,通常,它们深深埋藏在层层假定、误解、政治手段之下。需求,不是搜集出来的,而是挖掘出来的。

对于需求的分析,我们开发人员是难以考虑周全的,只有与用户一起工作,以用户的角度思考,我们才能真正掌握需求。

制定需求文档。看待用例的一种方式是强调其目标驱动的本质,它强调的是要重视需要做成什么以及需要什么条件。需求文档最好配一些UML用例图。

不要曲解需求的含义,需求不是架构、不是设计、不是用户界面,而是界面。同时,在需求这个问题上,我们需要“看远些”,我的理解是:让需求抽象一些,抽象比细节活得更长久。

建立项目词汇表,上面的词汇是开发者和用户的特定词汇,保证在开发过程中保持一致性。

第三十七节:解开不可能解开的谜题

解决迷题的关键是确定加给你的各种约束,并在其中确定你确实拥有的自由度。

问题就相当于一个盒子,不要在盒子外面思考——要找到盒子。

在处理问题时,遇到不可能解决的问题时,切忌先入为主,不妨退一步思考,是否还有更简单的方法,不能放过任何你觉得愚蠢的方法。

第三十八节:等你准备好

有时犹豫的人会得以保全。

作为一个了不起的表演者,你知道何时开始,何时等待。在自己没有准备好之前,倾听反复出现的疑虑——等你准备好再开始。

对于某些东西,我们可能不愿意轻易做出承诺,总希望再等等,更多意见的提出。但这很可能是一种拖延,怎么区分是有效的等待还是拖延的接口呢?我们应该快速地构建原型,并进行推延,可能很快我们就找到了更好的解决方案。

第三十九节:规范陷阱

编写规范是一个重要的职责,它解释并澄清系统的需求,消除了主要的歧义,同时,它也是一份与用户的合约。

编写合约是一件困难的事情,譬如说系鞋带。有些事情,“做”比“描述”更简单。

作为一个注重时效的程序员,将编写程序的各个步骤都规范化固然没错,但不要把这些步骤都鼓励开来,而是把他们进行无缝衔接。

第四十节:圆圈与箭头

不要做形式方法的奴隶。

设计文档里的圆圈和箭头用来解释他们指代的作用,但这还有可能是推翻我们原先设定的证据。感觉这个是承接上一节的内容,不要被以前的假设和设计所限制,留有一定的弹性空间。

我们相信,盲目地采用任何技术,而不把他们放进你的开发实践和能力的语境中,这样的处理日后可能会让你后悔。

不要迷信工具以及各种方法学,注重实效的程序员会批判地看待他们,并从中提取精华,融合成每个月都在变得更好的一套工作习惯。

第八章:注重时效的项目

第四十一节:注重时效的团队

对于之前的几章,偏重于程序员个人本身的发展与成长,这一章主要讲的是如何提高团队的效率。

团队必须为破窗户负责,这也是为产品的质量负责。一个团队是一个整体,应该时刻注意周围的变化,不然只会像青蛙一样被煮熟。

团队作为一个整体,最重要且必须要有的过程——交流。一个沉默寡言的团队绝对是一个糟糕的团队,一个团队的个性需要每个成员奉献出自己的力量。

不要重复你自己(DRY):由于个人理解程度的不同或者新成员的加入,团队总会面临重复的内容,适当的指派一名管理员,让他专门维护这些资料,所有对此有疑问的人都不必自我寻找,只要去找管理员就行了。

正交性:对于较大的团队,更应该通过功能进行组织划分,而不是工作职务。比如开发多个项目,会有多名开发,多名测试,多名设计,他们之间更应该按照具体项目进行划分,一个项目的开发,测试和设计为一个小团体。

自动化:确保一致性和准确的一种很好的方式是使团队所做的每件事情都能自动化,如果还没有做到那就尝试去做。

知道如何停止绘画:团队是由个体组成的,给每个成员足够的空间,并支持他们,而不是一直给他们具化各种需求。

第四十二节:无处不在的自动化

不要使用手工流程。人的可重复性并不像计算机那么好,着重于使用自动配置的技术去实现计算机的自动化。

项目的构建,一般使用自动化对其进行初始化,但在项目构建的最后要根据版本的不同对其进行测试。

第四十三节:无情的测试

早测试、长测试、自动测试。

一个注重时效的程序员,一段代码真正完成——这个代码经受的住所有的测试。

测试的主要类型:

①单元测试:对某个模块演练

②集成测试:子系统之间能够协调的工作

③验证和校验:是否满足用户的需求

④资源耗尽、错误及恢复:现实条件下,程序怎样运行

⑤性能测试:程序是否高速运行,性价比是否高?

⑥可用性测试:用户在真实条件下的测试

测试的方法:

①回归测试:今天的数据与昨天的数据进行对比,是否相同

②测试数据:现实世界的数据和合成数据

③演练GUI系统

④对测试进行测试:故意引发bug,看测试是否执行

⑤彻底测试

第四十四节:全都是写

代码要跟文档紧密结合,我们要认真对待注释及文档,他们不是可有可无的东西。

我们喜欢看到简单的模块级头注释,关于重要数据和类型声明的注释,以及给每个类和每个方法所加的简要头注释,用于描述函数的用法和任何不明了的事情。

应当使用特定的格式进行注释,通常对应语言或者 IDE 有推荐的注释格式。

可执行文档,即使按照特定格式进行注释,然后利用工具提取注释内容并生成文档。例如 JavaDoc

有时文档撰写者和开发并不是同一人,但他们应当接受同样的原则,特别是 DRY,正交性,以及自动化原则等。

第四十五节:极大的期望

在现实世界中,一个产品的成功很大程度上取决于它是否满足了用户的需要,有时不需要添加太多的功能。如果需要用户对我们抱有期待,我们就需要温和的超出用户的期望——意外的惊喜。

在开发产品的过程中,我们需要同用户进行交流,充分了解用户的需求,也让用户充分了解开发者的能力和产品,对最终的产品模型进行协商。

额外的一公里(额外的惊喜):

给与用户比期望的多一点,例如下面这些特性:

①气球式帮助或工具提示帮助

②快捷键

③彩色化

④作为用户材料的快速参考指南

⑤日志文件分析器

⑥自动化安装

⑦用于检查系统完整性的工具

⑧运行系统的多个版本、以进行培训的能力

⑨为他们的机构定制的splash屏幕

第四十六节:傲慢与偏见

无论在那个时代,我们都应该为在自己的作品上签字感到自豪。

不要试图阻止查看你代码的人,同样的,你也可以怀着同样的心情查看它的代码。我们需要看到对所有权的自豪。

看到自己签名的瞬间应该感到自豪,这是对代码质量的保证。

 

posted on   跨越&尘世  阅读(27)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 【.NET】调用本地 Deepseek 模型
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
< 2025年2月 >
26 27 28 29 30 31 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 1
2 3 4 5 6 7 8

点击右上角即可分享
微信分享提示