78
社区成员




项目 | 内容 |
---|---|
这个作业属于哪个课程 | 课程社区 |
这个作业的要求在哪里 | 作业要求 |
我在这个课程的目标是 | 积累软工经验,进行软工方法论实践,提高工程能力 |
这个作业在哪个具体方面帮助我实现目标 | 软件工程项目总结,梳理思绪 |
以下是我对原来问题的一些个人理解
A1 作为团队的架构师,实际上由于经验不足在Ficus项目初期设计的架构在后期除了一些顶层设计基本上已经发生了根本改动,很大一部分原因是因为个人经验不足,由此我想软件设计实际上还是一个很依赖经验的过程,而不是依赖理论(抽象),如果经验足够很容易就可以设计出一个可维护性和可扩展性强的架构,直接避免了过早扩大化/泛化。
A2 就js/ts目前 Eslint 工具已经可以很好的支持一些语义的限制,也可以做一些代码耦合度的分析,此外CodeReview机制也在一定程度上限制了低质量代码在项目里泛滥。
A3 这是一个与PM有关的问题,不过作为开发我认为这是在项目一开始需求调研后就应该想明白的事情,然后可以以此作为宣传点。在功能分析的象限自然也是越全面越好,并不存在互斥的问题。
A4 在我心里单元测试永远是先行的测试方案,它可以保证在还没有完成主体代码前就进行小范围测试,保证了在开发初期就可以有鲁棒性强的代码,而TDD的思想也是基于此(结对时我们就用的这个方法)。集成测试、部署测试、压力测试需要根据具体情况进行使用。
A5 这也是个和PM直接有关的问题,PM必须要在团队中有一定威望和话语权,在分配相对合理的前提下很容易就做出绩效评价。我们团队的贡献分配非常和谐。
暂无
整体体验还是很新奇的,实践了一些有趣的开发方法(TDD),最大的感受就是两个人写代码确实比一个人写快乐,因为两个人中我对语言/算法比较熟悉,但并不熟悉GUI相关知识,这一点和我的队友互补,我们的合作也是轻松且愉快的。此外也深刻体会到了结对编程的检出错误成本远小于单元测试/集成测试,很多错误都是在互相进行代码审查中进行的,而且极限编程每周40小时工作制也很重要,超过了这个时间明显感觉到代码质量下滑。
其实项目初期我是很忐忑的,因为说实话我个人开发Web应用的经验也有限(仅限于一些Vue的小打小闹),而且我们团队说实话在一个月内(alpha阶段至少要实现主要功能)对做出一款不但要求文档内联系、更要求文档间联系的完备的笔记软件心里也没有底,最后能产出这样一个软件平心而论是我个人一开始没想到的。
从零到一无疑是最艰难的一步,记得我们当时因为muya可以在本地实现所见即所得文本编辑功能都兴奋不已。但实际上问题远远没有解析渲染一个Markdown那样容易,光配一个Electron+Vue的环境就费了很大功夫。然后接踵而至的是所见即所得模式行为、Markdown的中间表示转换、榕树渲染、tag的储存、文件引用的解析、榕图渲染、大纲、多平台UI适配、菜单、快捷键、榕林行为等等,虽然遇到了很多技术难题,但好在都解决了。
但也必须承认,Ficus目前仍是一款充满了“妥协”的软件,榕林功能需要进行继续打磨、超过50KB文件的渲染切换存在的一定问题、文本编辑体验仍需提升,但根本原因还是有限的时间导致我们不得不把一些开发计划往后移。目前对我而言只能说基本满意,但之后有时间我一定会把所有代码在好好过一遍(狠狠立下Flag)
这次团队合作是我一直以来最舒服的团队合作,可以说我所有不擅长的工作都有人精通,我只需要做我喜欢做的那一部分就可以了。感谢我们PM能组织起这样一支团队,也感谢团队里的大家在这两个月来的努力和付出。
作为团队的架构师,我之前虽然阅读了一些架构设计的书,本来想信心满满得写出一个一眼就看到尽头的架构,然而个人经验和能力显然不满足这一条件,最初画出来的UML图除了几个上层设计和IR设计基本上都在不断重构。在这重构的过程,我最大的认识还是设计模式永远不是解决问题的唯一解(而且也不一定用得上),有时候往往一个简单的组合关系就可以解决代码中的“坏味道”。
最后再次感谢gg=G团队里的所有人,缺少了我们中的任何一个人都不会有这款软件的诞生。
(本文编辑于我们团队软件Ficus)
团队的贡献分配非常和谐
要避免每个人的分数都是一样的。