software第一周作业

| 这个作业属于哪个课程 |https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS|

| ----------------- |--------------- |

| 这个作业要求在哪里| https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/homework/15692 |

| 这个作业的目标 | <发一篇关于自己的博客随笔> |

github
https://github.com/dwjdyx/dwjdyx.git

1. 介绍自己
   我是24级计算机科学与技术专业的学生。虽然主修计算机专业，但我并没有将发展方向放在传统的上层软件开发上，而是把主要精力投入到嵌入式软件方向的学习当中。至今我已经自主学习嵌入式相关知识一年半，期间不断练习单片机底层开发、硬件调试，独立完成过几个软硬结合的实战项目，并且报名参加了电子设计竞赛。尽管最终没有拿到奖项，但备赛过程让我积累了大量项目实战经验，锻炼了自己排查软硬件故障、解决实际问题的能力，收获颇丰。在课余生活里，我平时比较宅，闲暇之余喜欢阅读小说放松身心；大部分空闲时间还是会用来钻研嵌入式技术，不断打磨自己的专业能力，朝着嵌入式软件工程师的目标稳步前进。
   2.现状、经验和计划
   （1）之所以选择这个专业，只是单纯听说比较赚钱，当然选择的时候也没有考虑到35危机这个大关。。。而且显而易见这个专业也有太多大佬小时候就深耕电脑领域，所以秉承着比不过就换条路的原则，非常幸运地找到了与计算机沾边自己还感兴趣的嵌入式方向进行学习。现在已经学了stm32,esp32，做了几个项目巩固练习，当然离正式的工程师还差的挺远，嵌入式也有几个方向，我主要是对机器人感兴趣，而且当前机器人领域也很热门，不过目前还在艰难地学机器人学，什么笛卡尔坐标系真是头大，痛并快乐着。。。
   技能：
   需求对齐与代码健康度（4，6）
   验证深度与测试覆盖（4，7）
   遗留系统现代化（3，6）
   开源杠杆与社区贡献（5，6）
   手动掌控力与底层原理（5，7）
   提高水平手段：
   看网课，做项目，找开源，通过ai解决问题和优化项目，和别人组队交流心得
   （2）心得
   a)上课是我当前人生阶段的必要任务，认真上课，课后完成作业，尽力做到最好就算是没有辜负这个阶段，而且老师上课讲得这么辛苦总不能啥也不听吧，最主要还是考试，完全不听考试抱佛脚也难抱。。就算是尊重老师自己也有收获
   b)在大学中既体验到了”陌生人“式的师生关系，也体验到了”餐馆与食客“式的师生关系，体验到了”狱警与犯人“式的师生关系，也体验到了”教练与学员“式的师生关系。我希望这门课属于”教练与学员“式的师生关系，作为学生，哪一节课不想如此。如果老师布置的作业对我来说有点困难，我会权衡这个作业是否值得我花费大量时间与精力去完成它，E，而且当前ai这么发达，作业不会当然是问ai找提示再解答，还是不会再找ai解答
   c)合理引用与参考他人资料是在注明出处的前提下，借鉴别人的观点、成果，并在此基础上加入自己独立的思考与创新，以此推进工作；而抄袭剽窃则是不加标注地直接照搬他人文字、代码或成果，将别人的劳动冒充为自己的产出，最根本的区别就是是否标明来源、是否具备属于自己的原创工作内容。
   （3）我未来打算成为一名嵌入式软件工程师并为此做好长期准备。相比其他计算机专业的同学，我的优势在于赛道差异化，避开了上层软件开发激烈的内卷竞争，软硬结合的技能也更有技术壁垒；劣势是身边缺少一同学习嵌入式的伙伴，遇到难题只能独自摸索，缺少线下交流讨论的环境。本学期我计划系统学习PCB相关知识，练习焊接与硬件调试，独立完成一个从方案设计、画板打样到代码调试的完整嵌入式项目。
   （4）计划学习一下怎么根据客户实现一个项目吧，就是完整实现一个项目的流程和注意事项以及后续维护的事项，不过最重要的是这门课及格哈哈，80分以上
   目前都是用c写代码，代码量大概2000行左右，在门课上就上课时间加课后作业时间，B
   3.提有质量的问题, 给认真的反馈

问题一：软件工程中的规范流程是否会降低小型项目的开发效率？
对应章节：第1章 软件工程概论 1.1 软件工程是什么
问题描述：《构建之法》第1章提出，软件工程是一种系统化、规范化的软件开发方法，软件开发应该像传统工程一样，通过需求分析、设计、编码、测试、维护等过程保证软件质量。
但是软件工程中的规范流程是否适用于所有软件项目？对于小型项目而言，严格的软件工程流程是否反而会降低效率？
我认为软件工程思想本身是必要的，但是不同规模的软件项目应该采用不同程度的软件工程方法。
对于大型软件项目，例如操作系统、企业管理系统或者互联网服务平台，规范流程非常重要。因为这些项目通常由多人甚至几十人共同开发，如果没有明确的需求分析、接口设计和代码规范，不同开发人员之间很容易产生冲突，最终导致项目难以维护。但是对于小型项目或者学习型项目，完全按照大型项目的软件工程流程执行，可能会产生效率问题。
例如，一个学生为了学习某个新的开发框架，想快速完成一个实验项目。如果按照完整的软件工程流程，需要先编写需求文档、设计文档，再进行评审和测试，这些过程可能比真正编码花费更多时间。软件和传统工程有一个区别：软件具有较强的可修改性。
例如建造一栋房子，如果结构设计错误，需要拆除重新建造，成本非常高。但是软件开发中，如果前期设计不完善，可以通过重构代码进行调整。
因此，软件工程中的流程应该是一种指导方法，而不是固定规则。

问题二：程序员是否应该在编码之前完成完整设计？
对应章节：第2章 个人技术和流程 2.1 单元测试和个人开发流程
问题描述：书中强调软件开发过程中应该进行计划、设计和分析，而不是拿到任务后直接开始写代码。
但是对于一个未知领域的问题，程序员真的能够在编码之前完成完整设计吗？
我认为设计非常重要，但是设计不可能完全脱离实践。
很多时候，开发人员只有真正开始编码，才能发现原本设计中没有考虑的问题。
例如嵌入式系统开发中，一个方案在理论上可能非常合理，但是实际开发时可能遇到：

• 芯片运行资源不足；
• 通信速度达不到要求；
• 传感器数据不稳定；
• 软件架构无法满足实时性要求。
  这些问题往往不是通过提前设计能够完全预测的。
  如果完全不设计直接编码，会导致项目后期混乱。例如不断增加功能后，代码之间产生大量依赖，最终难以维护。但是如果过度强调前期设计，也可能造成“设计过度”。例如开发一个简单功能，如果花费大量时间设计复杂架构，可能反而降低开发效率。
  因此，我认为软件开发更合理的方式应该是：先进行一定程度设计，然后通过编码验证设计，再不断修改。
  设计和编码不是两个完全独立的阶段，而是不断循环的过程。

问题三：个人英雄主义和团队开发之间是否存在矛盾？
对应章节：第3章 软件团队 3.1 软件团队的特点
问题描述：《构建之法》第3章提出，现代软件开发越来越依赖团队合作，一个优秀的软件团队需要明确分工、有效沟通和共同目标。
但是团队开发是否会限制优秀程序员个人能力的发挥？
团队合作对于大型软件项目非常重要，但是团队模式也可能带来一定限制。例如，一个经验丰富的程序员可能能够独立快速解决问题，但是在团队开发中，需要遵守统一规范，例如代码风格、开发流程、接口约定等。这些规范虽然能够减少团队协作问题，但是也可能降低个人开发速度。另外，过度分工可能导致成员只关注自己的模块，而不了解整个系统。
例如：

• 前端开发人员不了解后端逻辑；
• 后端开发人员不了解用户需求；
• 测试人员不了解代码设计思想。
  这样虽然提高了短期效率，但是可能降低团队整体技术水平。
  我认为优秀的软件团队不是简单把任务分给不同的人，而应该让成员既有自己的负责领域，又能够理解整体系统。
  特别是在学习阶段，如果过早固定角色，例如只负责测试或者文档，可能不利于个人技术成长。
  因此，我认为团队合作和个人能力提升并不冲突，关键在于团队是否能够提供交流和学习环境。

问题四：代码复审是否一定能够提高软件质量？
对应章节：第4章 两人合作 对应小节：4.2 代码复审
问题描述：书中提出代码复审的重要性，认为通过另一个程序员检查代码，可以发现问题，提高代码质量。
但是代码复审是否真的能够有效发现软件中的问题？
代码复审确实有价值，但是效果取决于复审方式。如果代码复审只是检查：

• 变量命名是否规范；
• 格式是否统一；
• 注释是否完整；
  那么它的价值有限。
  真正有意义的代码复审应该关注：
• 程序逻辑是否正确；
• 模块设计是否合理；
• 是否存在潜在性能问题；
• 是否容易维护。
  例如，一个函数可能完全符合代码规范，但是算法复杂度过高，或者设计导致后期无法扩展，这些问题只有具有经验的人才能发现。同时，如果团队成员技术水平接近且经验不足，代码复审可能只能发现表面问题。因此，代码复审不仅是一种检查方式，更应该是一种技术交流过程。

问题五：测试是否应该由开发人员自己负责？
对应章节：第5章 团队和流程 5.1 软件团队的组织和流程
问题描述：《构建之法》强调软件开发过程中测试的重要性。
但是开发人员自己进行测试是否可靠？
我认为开发人员参与测试是必要的，因为开发人员最了解代码设计和实现方式。但是完全依赖开发人员测试可能存在问题。
原因是：程序员在开发过程中通常按照自己的设计思路测试，而用户实际使用软件时，可能会采用完全不同的方法。
例如，一个程序员测试登录功能时，可能只测试：

• 正确账号密码；
• 正常输入格式。
  但是用户可能输入：
• 空密码；
• 超长字符串；
• 特殊字符。
  这些情况可能暴露隐藏问题。因此，专业软件团队通常需要独立测试人员，因为测试人员能够站在不同角度发现问题。但是如果完全把测试交给测试人员，也可能降低开发人员质量意识。
  所以更合理的方法应该是：
  开发人员负责基本测试和单元测试，测试人员负责独立验证和系统测试。

C

4. 前车之鉴
   (1)https://book.douban.com/subject/4006425/discussion/22803961/
   （你是否也觉得自己是科班，但没学懂计算机？）
   读完《在失望中寻找希望》这篇文章，我最大的感受是，每个人的成长道路都不完全相同，不应该因为自己和别人存在差距，就轻易否定自己。文章中的作者曾经在本科阶段迷茫过，虽然成绩不错，但回头看却发现自己并没有真正掌握计算机，只是在按照老师安排的内容学习。这让我意识到，学习成绩和真正的能力并不是完全等价的，尤其是在计算机领域，主动思考和实践往往比单纯完成课程更加重要。文章中作者提到自己本科阶段学习数据结构时，只停留在考试和概念层面，而在后来旁听清华大学的数据结构课程时，才真正认识到计算机知识之间的联系。这一点让我感触很深。计算机并不是一门只需要记忆知识的学科，很多内容只有通过实践和思考才能真正理解。例如学习编程时，能够按照教程写出代码并不代表掌握了编程能力，真正重要的是遇到没有见过的问题时，是否能够分析原因并解决问题。
   其实我自己也有类似的经历。刚进入大学时，我也经常感觉自己和周围同学有些格格不入。我平时比较宅，虽然经常上网，但是关注的方向和身边同学并不完全一样，所以对于他们讨论的一些流行文化、兴趣话题并不了解。更明显的是，虽然大家都是计算机专业，但是有些同学高中时期就已经接触过电脑和编程，对计算机相关知识非常熟悉，而我直到大学才正式接触计算机，刚开始甚至连一些常见的计算机术语都不了解。刚开始的时候，我也会因为这种差距产生焦虑，觉得自己是不是起步太晚，和别人相比已经落后了。但是后来我逐渐认识到，每个人都有自己的成长节奏，没有必要完全按照别人的路线发展。别人可能很早接触计算机，但这并不代表自己没有机会追赶。真正重要的是找到自己感兴趣的方向，并持续投入时间学习。当然，文章也提醒我，不能只是沉浸在自己的世界里。作者反思自己过去的问题时提到，最大的不足在于缺少主动思考和交流，而不是单纯能力不足。这让我认识到，在保持自己兴趣的同时，也应该主动接触新的知识，多实践、多交流，不断发现自己的不足。总的来说，这篇文章给我的启发是，人与人之间的差距并不可怕，可怕的是停止成长。起点不同并不能决定终点，重要的是是否愿意主动改变自己。找到自己的方向，坚持学习和实践，即使曾经迷茫，也依然能够不断进步。

（2）https://news.cnblogs.com/n/531362/
（半路出家，认真学习，对自己狠心，不断在实践中进步）
读完《半路出家，认真学习，对自己狠心，不断在实践中进步》这篇文章，我最大的感受是，一个人的起点并不能决定最终的发展方向，真正重要的是是否愿意主动学习，并且坚持实践。主人公初中没有毕业，最开始甚至连电脑都没有接触过，但因为一次偶然的机会接触到了编程，便确定了成为程序员的目标。虽然起点比很多人低，也经历了很多困难，但是她没有因为基础不足而放弃，而是在不断学习和实践中提升自己，最终凭借能力进入优秀的技术公司。这让我认识到，学习一门技术最重要的并不是一开始掌握多少，而是是否具备持续成长的能力。
我自己也是类似的情况。作为计算机专业学生，我接触计算机的时间其实比较晚，大学之前并没有系统学习过编程。刚开始接触嵌入式时，也因为自己不是相关专业背景，和周围已经有编程基础的同学相比感觉差距很大。尤其是在参加工作室考核失败后，也曾怀疑自己是否适合继续学习嵌入式，觉得自己需要额外补充硬件、单片机等大量知识。但是后来我意识到，专业背景并不能完全限制一个人的发展方向。真正重要的是找到自己感兴趣的方向，然后投入时间不断积累。通过自学单片机、STM32以及参与项目实践，我逐渐发现自己确实喜欢嵌入式开发，也在学习过程中不断提升自己。这篇文章给我的启发是，不应该过分关注自己和别人的起点差距，而应该关注自己是否每天都在进步。很多能力不是天生拥有的，而是在不断实践、犯错和改进中培养出来的。只要保持主动学习的态度，坚持积累，即使是跨方向学习，也依然能够找到属于自己的道路。