三月读书笔记3

Posted 2023-04-01 JIANGzihao0222

阅读了《人月神话》贵族专制、民主政治和系统设计，画蛇添足，贯彻执行，为什么巴比伦塔会失败？这几章，对于《人月神话》这本书也有了更深的了解，这本书在宏观的大层面的角度看待软件工程的系统开发，没一句讲的具体知识，讲的全是一个项目的开发注意事项。首先，运用大教堂的成功，巴比伦塔的失败，将概念的完整性的重要性完美的呈现在我们面前，在这个过程中，为了概念的完整性，我们宁可舍弃一些一些优秀的的方法，程序，概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。实现同样是一项高级别的创造性活动。具体实现中创造和发明的机会，并不会因为指定了外部技术说明而大为减少，相反创造性活动会因为规范化而得到增强，整个产品也一样。概念的完整性的确要求系统只反映唯一的设计理念，用户所见的技术说明来自少数人的思想。实际工作被划分成体系结构、设计实现和物理实现，但这并不意味着该开发模式下的系统需要更长的时间来创建。经验显示恰恰相反，整个系统将会开发得更快，所需要的测试时间将更少。同工作的水平分割相比，垂直划分从根本上大大减少了劳动量，结果是使交流彻底地简化，概念完整性得到大幅提高。然后也要解决画蛇添足的问题：坚持至少拥有两个系统以上开发经验结构师的决定。同时，保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。同时，也要贯穿只许结构师的决策，要进行文档的规格说明，同时，也要及时的更新，修改。会议是必要的，相同小组--结构师、用户和实现人员--每周交流一次。因此，大家对项目相关的内容比较了解，不需要安排额外时间对人员进行培训。小组十分睿智和敏锐，深刻理解所面对的问题，并且与产品密切相关。没有人是"顾问"的角色，每个人都要承担义务. 当问题出现时，在界线的内部和外部同时寻求解决方案。正式的书面建议集中了注意力，强制了决策的制订，避免了会议草稿纪要方式的不一致。清晰地授予首席结构师决策的权力，避免了妥协和拖延。交流和交流的结果--组织，是成功的关键。交流和组织的技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。

本学期阅读计划

三月份和四月份看完《构建之法》并完成读书笔记6篇 五月份和六月份看完《梦断代码》并完成读书笔记三篇 快速看完《构建之法》后，我有几个不懂的问题 1.看完单元测试中写的代码用到C#，我们需要自学C#吗 2.单元测试和产品代码有什么不一样？ 3.进行团队开发如何进行快速有效地分工？ 4.如何在做软件时培养创新意识？ 5.oracle,SQL Server,My SQL这几种数据库都要掌握吗？能否在了解后选一种进行深入学习和使用？ 6.一般情况下我们都是自己构思一个软件并实现，那么在软件需求分析这一块怎么得到实践？