[2023软工作业]个人作业-阅读和提问

fox_816

已于 2023-02-25 16:29:01 修改

阅读量154

点赞数 1

分类专栏： 2023软工作业文章标签：软件工程 Powered by 金山文档

于 2023-02-25 16:25:45 首次发布

本文链接：https://blog.csdn.net/fox_816/article/details/129217158

版权

2023软工作业专栏收录该内容

4 篇文章 0 订阅

订阅专栏

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程
这个作业的要求在哪里	个人作业-阅读和提问
我在这个课程的目标是	掌握软件工作开发方法，并进行实践
这个作业在哪个具体方面帮助我实现目标	引导我对书籍《构建之法》进行阅读于思考，对软件工程进行初步了解

一、5.3.6章节对MVP（最小可行产品）的疑问

在对MVP的描述中，举了这样一个例子：

一个社交网站已经有很多用户，都是免费的，产品团队想设计一个付费的VIP服务，MVP的做法可以是这样的——在目前的用户入口页面中加一个“VIP服务”的连接，指向一个简单的介绍页面（用最小成本做出了）。观察到底有多少用户点击这个链接。如果点击量太小，那么这个服务就不用做了。

问题提出：我认为在产品调研阶段进行MVP是不合理、不负责任的。

个人观点：

一方面，如果我们使用一种直接采用链接说明“点击该链接查看VIP”服务的方式，此时点击链接的数量仅能代表对VIP服务好奇的人数。根据我的个人经验，其中大多数用户会进一步根据价格深入考虑是否购买。这会导致得到的点击量大于（甚至远大于）真正想要购买VIP服务的人数。

另一方面，用户在使用前多会希望体验详细全部的服务，如果仅提供功能不全的服务反而可能会让用户先入为主，认为VIP服务不过如此，不值得购买。这就会导致流失一批可能购买VIP服务的用户。

二、8.6.3章节经验公式

在对估计实际时间花费中，提出了这样一个经验公式：

Y = X ± X ÷ N //注：Y是实际时间花费。中间的±表示加上或减去。
其中：对某件事的估计时间X，以及做过类似开发工作的次数N。

问题提出：我认为该经验公式的不合理处在于，没有考虑对于身边知识资源利用的作用。并且过于夸张了在没有经验时软件工作人员对于估计的偏差。

个人观点：

对于夸大无经验估计的偏差：个人认为在开展软件开发前，该开发人员至少肯定具备了熟练的算法、数据结构知识，并且具备基本的前后端开发知识与相关理论，缺乏的只是具体细节。就我个人而言，数据库大作业我负责前端，便是第一次进行前端开发的情况。事实上，前端开发的理论成本在一定程度上主要是对Vue框架的学习，以及实践成本主要是对框架的具体应用（而这是熟能生巧的，基本上用过一次第二次就熟练了）。所以对我而言，对时间估计的偏差大约是少了50%左右，而这大部分是由于对于一些细节处理（如路由、前后端对接、Vue框架具体理解）的问题。

对于身边知识资源利用的作用：我认为在进行软件开发（尤其时第一次实践时），知识资源利用（如优秀的前辈、博客、网课资源等）是起到极大作用的。当能够充分利用这些资源时，对于上述的细节处理问题（如路由、前后端对接、Vue框架具体理）会得到很快的解决；反之，当无法寻求帮助时，可能会深陷泥潭。

三、9.4章节团队讨论

会议经过如下流程：

会议开始 -> 理清事实 -> 表达感情和直觉 -> 乐观的分析+创意 -> 悲观的分析+创意

问题提出：先乐观再悲观是否合理，如果以悲观的分析结尾是否会抑制开发人员的开发热情。

查阅资料：程序员在项目中总会遇到许多未知的事物，也会常见的出现延期状况，此时PM与程序员压力都很大，如果任由悲观情绪蔓延，不宜于团队氛围；就程序员个人而言，程序员都是乐天派，乐观的情绪会保证其工作效率，但同时也会容易使其没有压力、思维不缜密。

我的困惑：我认为就程序员个人而言，应当“理智上悲观，抑制上乐观”。但对于团队而言，仍不确定是否应该会议以悲观结束。

四、10.1.3怎样定义典型用户

其中有一句注意：

问：那这样不就是损失了大量潜在的用户，我们至少得争取一下为所有人服务，如果不行，再回到少部分用户？
答：不妥，我们宁可从小部分人除法，要非常明确地定义谁是我们的用户。

问题提出：我认为从小部分人出发是不妥的。

个人观点：软件的设计于开发不应当是为了小部分用户（如果以盈利为目的），当我们明确定义了各类（受欢迎的、不受欢迎的）典型用户后，我们应当以受欢迎的典型用户的较大较合适软件的群体出发设计软件。如当今短视频软件抖音快手等，就是将手机操作不熟悉的中年人士作为典型用户之一，所以软件设计简单方便。正是由于该典型用户群体大，才使得软件成功。

五、11.1.3其他设计方法中的文学化编程

对文学化编程书中的介绍如下：

程序员在写程序的时候，要理解在文档中的需求，同时还要在程序里写相关的注释，这些不同目的的“写作”各有价值，但是一旦需求或程序发生变化，这些不同的文档很难保持同步。 更不用说程序员最常见的毛病 “我以后会加上注释的…”Donald Knuth 在20世纪70年代末开始尝试并提倡 Literate Programming 的思想并在自己的软件项目中身体力行。这一方法和常见的 “写程序，时不时加上一些注释” 相反， 它是 “写文档，时不时有些代码”。 它使用了宏（Macro）来进行抽象和信息隐藏。 通过工具的支持，它的源代码可以提取出让计算机编译执行的部分（叫 Tangle），以及文档（叫 Weave）。

问题提出：这种编程方式看起来就像是在源文件中边写文档边写代码，这样是否会导致由于过于看重文学而编程效率下降？这样将设计文档和代码放在一起，是否会难以维护？

查阅资料：以下是一段文学化编程代码：

作者：李阿玲
链接：https://www.zhihu.com/question/26978956/answer/34854743
来源：知乎

@p @!init function get_strings_started:boolean; {initializes the string pool,
  but returns |false| if something goes wrong}
label done,exit;
var k,@!l:0..255; {small indices or counters}
@!m,@!n:text_char; {characters input from |pool_file|}
@!g:str_number; {garbage}
@!a:integer; {accumulator for check sum}
@!c:boolean; {check sum has been checked}
begin pool_ptr:=0; str_ptr:=0; str_start[0]:=0;
@<Make the first 256 strings@>;
@<Read the other strings from the \.{TEX.POOL} file and return |true|,
  or give an error message and return |false|@>;
exit:end;
tini

这个是一段Pascal代码，其中@<Make the first 256 strings@>这个部分是一小块代码，长这样：

作者：李阿玲
链接：https://www.zhihu.com/question/26978956/answer/34854743
来源：知乎

@<Make the first 256...@>=
for k:=0 to 255 do
  begin if (@<Character |k| cannot be printed@>) then
    begin append_char("^"); append_char("^");
    if k<@'100 then append_char(k+@'100)
    else if k<@'200 then append_char(k-@'100)
    else begin app_lc_hex(k div 16); app_lc_hex(k mod 16);
      end;
    end
  else append_char(k);
  g:=make_string;
  end

作者认为：文学化编程听起来就像在拿着剪刀浆糊在弄程序。虽然作者本人有点喜欢这一套，但是，这种东西实际上会造成两方面的问题：代码不好维护；代码容易写的很ad hoc。

但另一方面：文学化编程让人们从由屈从于计算机工作方式的编程方式，调整为适合人类思维逻辑的编程方式。

我的困惑：我仍难以接受文学化编程，因为它看起来让程序员写程序时频繁调整写注释和写代码，并且难以评价其优劣。