今天：读后感：
构建之法：现代软件工程》读后感
最近读了邹欣老师写的《构建之法：现代软件工程》，感觉这书把软件工程那点事儿讲得特别明白，让我有很大感触
1.我在大一做编程作业的时候，根本不想它的内在，就想他要啥，我就给啥呗。从来不考虑他给的例子里面把变量变了会不会导致我的整个代码会满足不了题目要求。
但是看完这本书之后就会发现我的问题，这解决编程问题就像盖大楼，得一步步来，需求分析就是搞清楚用户要啥，相当于确定大楼要盖成啥样、有啥功能；设计呢，就是规划大楼的结构，哪里是房间、哪里是走廊；编码是搬砖盖楼，测试是检查楼结不结实、有没有漏水啥的，维护就是楼盖好后，住户发现问题了再上报给你，你再修修补补啥的。这么一套流程走下来，一个代码才能从想法变成能用的东西，这过程里每个环节都少不了，少了几步可能最后这代码就不对，就没法用。
所以我就自己想了个办法，分步骤来编写代码：第一步是审好题目，理清思路，必要的时候列一个表格，知道用户要什么，我该怎么做；第二步是上手操作，把用户的需求按照要求做好；第三步是检查代码，不能把有纰漏的产品给用户。
2.我在大一的时候学习编程，就感觉看看就会了，不咋上手，但是上手了也能做出来，但是会出现一个极为严重的问题，就是代码的质量极其低。
那么关于代码质量，这书也给我整明白了。以前觉得测试一下就能保证质量，其实不是。从最开始弄清楚用户需求，可不能理解错了，到设计的时候把结构搞合理，代码写得工整好看懂，再到各种测试，这一路下来每个步骤都得重视质量，要不然最后代码一堆毛病，用户用着闹心，还得返工，白费功夫。就跟做饭似的，买菜、切菜、炒菜每个环节都得用心，要不然炒出来的菜能好吃吗？
所以我自己就想要想写的代码有质量，必须是多写代码，写到自己吐，再去追求质量，这样不仅可以通过测试，更可以提高质量，用户用着也舒服，也不用自己白费力气，更不至于自己写的代码，过一阵子自己都不认得了，那就尴尬死了。
3.团队合作这块吧，书里说软件开发不是一个人能玩得转的，得一群人分工合作。有做产品规划的，有写代码的，有专门找 bug 的。就像打篮球，后卫、前锋、中锋各司其职，还得配合好。里面提到的敏捷开发，每天开个短会，大家说说干到哪了、遇到啥问题，然后接着往前冲，这办法听起来就很实在，能让团队里的人时刻保持同步，别干着干着有人跑偏了。这让我想到以后不管是在学校做小组作业，还是上班搞项目，分工明确、好好沟通真的太重要了，要不然容易互相扯皮，最后事儿也办不好。
对于团队合作这一块，我倒是没跟别人合作过，书里面讲的不错，看的我挺热血的，倒是让我挺期待的
最后再谈一下自己的感受吧，其实这个书里还讲了好多实际项目的例子，成功的、失败的都有。看那些例子就跟听别人讲亲身经历一样，能学到不少经验。比如有的项目因为需求总变，最后搞砸了；有的因为技术没选对，掉坑里了。这些事儿就像一个个提醒，以后自己做项目的时候，得注意这些坑，遇到类似情况知道咋处理。
不过想了一想，这软件工程领域发展也快，新东西一直冒出来，像现在人工智能和软件开发结合，又有新的玩法了，书里的内容得结合着最新的东西一起学，才能跟上趟，才能不被时代淘汰，才能以后能跟别人竞争竞争工作岗位。
总的来说，《构建之法》这书把软件工程的门道讲得挺透，不光教知识，还教怎么思考问题、解决问题。看完感觉自己对代码研究、软件开发有了新认识，知道这事儿得科学规划、团队协作、重视质量。以后自己搞开发的时候，得把这些学到的用上，慢慢积累经验。也挺期待在软件开发这事儿上，自己能多折腾折腾，搞出点像样的东西来，才真算是上过学，才真算是学过软件工程吧。
