在上这门课之前的期待

#

在提出问题之前，我想先聊一聊为什么自己选择这门课。我自己在业余时间里会开发一些小项目，然而多数都会半路夭折，少有成功。我自己分析原因是我自己不够专业，还是个草台班子，手工作坊，没有形成工业化，标准化的开发流程。因此我希望通过这门课来补齐短板，正式进入软件工业化时代。

第一章里有一段描述了软件开发的不同阶段：玩具阶段，业余爱好阶段，探索阶段和成熟的产业阶段。我觉得我现在正处在业余爱好阶段和探索阶段之间，虽然有意识地在进行标准化的开发过程，但是仍然不够专业。因此，我希望在上完这门课后至少能半只脚迈入产业阶段。

问题一

#

在《构建之法》第三章——软件工程师的成长这一节当中讨论了几个软件工程师的思维误区，第一种是分析麻痹，即想弄清楚所有依赖关系之后再动手，心理上过于悲观，没法前进。文中给出的解决办法是足够好和最小可用产品。减少前期过度分析。我的问题是如何能够确保最小可用产品足够好，即使开发到后期仍然是一个完美的基座而不需要大幅度修改呢？

在我个人实践过程中也经常遇到这样的问题，想先分析清楚之后再动手，但是很容易陷入分析——设计——发现缺陷——分析的死循环当中，迟迟无法行动。后来又看了别人写的文章：shit it until finish it。也开始尝试过最小可用产品的想法。这种想法确实很好用，让我能够快速地度过前期开发的过程。但是到了后期，我发现最小可用产品和我想扩展的设计不兼容，而此时已经积重难返了。如何快速分析，设计出足够好的最小可用产品对我来说仍然是个很大的难题。

问题二

#

在第五章 团队和流程这一节中，书中讨论了集中团队软件开发流程。实际上我现在还没有和人一起开发过，之和AI一起合作开发过。目前我的开发过程更像是书中描写的明星模式，在这一模式下，我会把一些简单直接的任务交给AI负责。我的问题是，AI在团队合作开发过程中能够扮演什么样的角色呢？

我在网上经常看到有人将一个项目交给AI agent，然后一个晚上之后一个项目就开发完成了。但是我个人实际的使用体验来看，即使是有些简单的功能，AI也没法正确的实现。问题最严重的就是我是用的工具已经更新到了4.4版本，然而AI给我的代码仍然是古早版本的API。也许是我用的AI不够智能的原因，但我总是很担心AI开发代码的可靠性，因此即使它生成了代码，我也需要再次审查，而因为思路不同，有的时候审查的时间甚至超过我自己开发的时间，可谓得不偿失。

问题三

#

在第八章 需求分析这一节中，书中讨论了软件团队如何才能准确而全面地找到需求。我比较好奇的问题是，对于游戏软件的需求分析应该如何做呢？

我认为游戏软件的需求分析是相对比较复杂的，因为一般的软件大多数是作为工具被人们使用。而游戏软件需要满足玩家群体的情绪价值，自然，游戏玩家的需求就是给他们创造的情绪价值越多越好，然而众口难调，一部分人的情绪价值得到满足，另一部分人就会觉得无聊。而现在市场上有“最少数的群体发出了最大的声音”这一现象，导致很难弄清玩家真正的需求。

问题四

#

在第十一章 软件设计与实现这一节，探讨了软件设计实现的具体流程。好吧，我必须承认我以为软件工程这门课的目的就是讲如何更好设计软件，我也是为了这部分内容而来的。没想到这一部分只有短短数十页。仅仅看这数十页并没有让我领悟到如何从手工代码作坊进化到标准化工业工厂。那么这里还是提出这个问题，什么样的软件开发流程、开发模式才是最适合我的？希望能够通过课程的学习与实践让我早日进入到成熟产业阶段。

问题五

#

最后一个问题并不完全算是问题，而是一些感悟。读完了书之后我认为软件工程起源于软件，但是又高于软件。软件工程的根本其实是人。不管是哪种开发手段、哪种模式，最终的目的都是为了更好的服务人。因此，我认为这门课讲的更多的其实是社会与软件的工程。说到人，其实我觉得，软件工程还应该考虑的一个事情是用户群体。对于一家软件开发公司来说，除了软件这种硬资产，更具有价值的其实是固定用户群体这样的软资产。当你有了一定数量的固定用户群体，软件的推广就不再是一个问题，因此如何维护好用户群体这一软资产其实也是软件工程应该考虑的因素。

以上是我对《构建之法》的一些思考与想法，希望通过这门课的学习，我能够成为一个真正的专家。