跳转至

软件开发经验分享

无9 杨希杰

【自我介绍】

大家好，我是电子系九字班的杨希杰，很高兴今天能到这里和大家分享一些软件开发的经验。

我的话呢，21年6月-12月作为队长带领浣熊财记团队参加移动应用创新赛，咱们的王继良老师是我们团队的指导老师；最终获得了国赛二等奖的成绩。在这个过程中我个人收获了很多关于app开发的思考：22年寒假的时候，电子系科协软件设计大赛，我也做了一次经验分享，视频上传B站了；但是那个可能不是很够提炼哈，想到哪一点就写到Xmind思维导图中，然后就讲出来了。这一次呢我会从软件开发的流程一步一步往前走，来跟大家分享我自己在应用开发的过程中的一些感悟，希望能对大家有一些启发。

下面这几点是我今天想说的一些内容，讲完之后我可能会问问大家的想法哦～

  • 软件开发的原点是什么？
  • 怎么做创新app？
  • 设计和开发是怎样的关系？
  • 怎么编写代码更轻松？

希望大家能从中得到一些启发。我主要按照自己的经验来讲、可能有一些不足的地方，请大家多多指教。

讲稿中标题后面的 〇 表示是重要的内容。在我讲完之后我会把讲稿链接发在课程群里面

先让我们看看实际软件开发的过程：产品经理 -> 后端开发 -> 前端开发

  • 产品经理
    • 需求分析 应用定位
  • 后端开发
    • 数据结构确定 前后端接口明确
  • 前端开发
    • UI UX 的具体实现

【应用类型】〇

  • 课程大作业（完成）
    • 来源：课程本身 希望大家完成某个项目的构建 更多的是练习
    • 考虑因素：完成度 成绩高低
  • 自用app（有用）
    • 来源：用来提高自己工作学习的效率 用软件提高生产力
    • 考虑因素：因为主要是自己用 所以用着舒服就可以了 随便怎么开发都可以 不太需要考虑他人的感受
    • 例：主要是一些工具类app 比如一些笔记类软件、日程管理软件、音乐播放器、小型计算器等等
  • 发布app（对很多人有用）〇
    • 来源：绝大多数来源于自用app 在解决自己遇到的问题的过程中 发现别人也遇到了一样问题 于是将app发布出来就变成了上架app
    • 考虑因素：用户群体 满足圈子内用户的需求
    • 例：THUinfo 小红书 MkDocs B站
  • 商业app（利益）
    • 来源：利益驱动/钱 发布app
    • 考虑因素：成本 持久化 用户反馈
  • 软件设计比赛（创新）〇
    • 比如移动应用创新赛 微信小程序设计大赛 安卓应用设计大赛 软件设计大赛
    • 考虑因素：这些比赛可能创新所占的比例很高 完成度是其次的 社会影响力可能也会是评价指标之一
    • 如果你做的是创新app，这个app在市面上从来没有出现过，那么其实不需要太在意功能完整性，只要你做出来展示出理念可能就已经很不错了；当然能做出来更好。

【应用目标】〇

一般当你想要开发一个软件的时候，你的考虑往往是解决一个现实的问题——没有问题的话其实和玩/练习差不多了

  • 比如想和朋友实时聊天 然后微信就被开发出了
  • 比如想和小伙伴交流问题 然后知乎就有了
  • 比如我觉得市面上的记账软件都不太符合我的需求 我们团队就设计开发了浣熊财记
  • 再比如有人觉得C/C++虽然功能齐全 但比较老了 写起来很困难 于是各种现代编程语言就被设计出来

总之如果你想做有用的app，我觉得是需要做到问题导向的——去解决什么问题，目标用户有哪些需求，脑子里面带着问题去想解决方案，然后去开发软件。

发现问题

很多时候，不要为了开发应用而去开发应用，而是面向问题来思考是否开发某个应用。可以头脑风暴一下自己身边有哪些问题和机遇——

  • 看看自己生活中有哪些觉得不爽的地方
  • 看看自己身边有哪些可以改进的地方
  • 现在手机上的应用哪些还不够好用
  • 有哪些app可能在十年内会发光发热

其实你会发现 这不就是写论文的过程（调研）吗？看看别人做了什么，然后找找gap。调研的时候你可以头脑风暴、可以发问卷、可以调研同类的软件、可以看看相关的论文，更可以和相关的人聊一聊。信息收集的多了，你就知道哪些地方还有缺口，哪些地方还可以改进，这个就是gap。

再次考量

当然不要重复造轮子，如果市面上已经有你想要的那种app了，那就没太大必要重新自己实现一遍了（商业化可能是特例吧）

自己/别人/市场需要这样的一个app嘛？

  • 我想开发一个记账的app——市面上那么多记账的app、你希望开发的app特色在哪里？
  • 我想开发一个游戏——你打算给用户带去怎样的快乐？还是给自己带来怎样的收益？
  • 我想做一个新的清华树洞——知乎足够了嘛？之前的树洞为什么停止维护了呢？
  • 我想从零开发一个操作系统——现有的Linux有什么不足嘛？

如何创新

  • 其实你解决了别人没有解决的问题就是一种创新、你满足了别的软件没有满足的用户需求这也算创新，这其实是比较平常的，因为有来才有去。这也是刚才说的发现问题。
  • 已经有了理论的创新（深度学习、3D渲染）或者技术的创新（AR、NLP），直接将这些创新拿来放到自己开发的软件中。别凭空而来 最好是源于问题或者源于一些新出的技术。我感觉顺着论文写app还挺爽的（指先发一篇论文阐述清楚一种新的技术 然后把这种技术用软件的方式表现出来）
  • 如果你是第一个做某件事情的人，这个路途大约会非常艰难，你头脑蹦出一个idea，然后你发现别人都没做过，这个时候你要开始做，我想这是完全的创新，但是可能比较难

比如我们创建的浣熊财记，其中数据结构的设计 就是看了很多同类的记账软件之后，觉得不符合直觉，我们就重新提出了标签和关注系统；财记则是发现记账中有着回忆在其中，而同类软件很少注重这一点，因此我们提出来，实现了相关的功能。创新点其实不是凭空提出来的，一般来说都会有基于一些gap。

还有就是我们的app中比如NLP的功能，其实最开始也是没有想到的；后来我去看了一下苹果的API文档，发现NLP的API是非常好用的，然后就添加了从用户输入的条目中提取内容和金额的功能。这算是用了新的技术吧。

【应用形式】

应用存在方式

应用使用方式和提供服务的方式

  • 使用方式
    • 命令行
      • 如果面向的是熟知操作系统相关的用户，也许命令行程序就已经足够了，你可以减少对UI的考虑，多在内部逻辑功能上下功夫。
    • 图形界面
      • 如果你想创建UI程序，也要注重你的目的：如果只是想给用户提供一个功能的使用接口，那其实做的简单一些也没有什么关系；如果是注重用户交互体验，那你的交互设计、动画、页面逻辑应该要下很大功夫
  • 提供服务的方式：本地计算 or 网络后端服务
    • 大家可能知道服务即应用（SaaS），我这里想说的是：Linux后端服务为主还是应用在平台上的实现为主。比如你想做一个在线的棉花糖提问箱，网页后端写好，不论是浏览器还是本地应用，调用服务就可以搭建app了，也许一个浏览器应用就足够了；但是如果你想做游戏，那可能本地构建还是更好一些。有些东西，能通过网络实现的话，其实没必要写平台（对应OS）的代码。如果希望跨平台，各种跨平台的框架也是可以考虑的

当然你可能要同时支持好几个、可能会融合

应用平台选择

设备选择：手机、平板、电脑（几种设备是很不一样的哦 我在之后会说到这一点）当然你可能要同时支持好几个

系统选择：

  • iOS or Android？
  • iPadOS or Android？
  • macOS or Windows or Linux？
  • 跨平台？浏览器？

一些区别在哪里呢？

  • 比如你想开发游戏，有一说一 用Linux应该会很辛苦，因为Linux平台用户较少、可能没有很好的游戏引擎、硬件的支持会弱一些。
  • 如果要做商业软件，比如你要做机械设计软件、电路仿真软件，那大概率就选择Windows了，因为Windows的后向兼容承诺，你几十年不更新app都没问题；macOS就没有这么幸运了，我去年暑假开发的切换输入法的工具直接在去年9月份升级系统之后寄了；还有苹果平台会不断让你给app添加一些新的应用信息，这一点我也觉得挺烦的，总之就是你得不断更新你的app，不然要么被下架、要么打开闪退。
  • 跨平台的话，对于中小型软件来说我觉得是不错的选择，比如使用Flutter、React Native、Qt这些框架，一份代码，跨平台，不是很爽嘛。但如果你要做复杂一些或者专业一些的app，我觉得跨平台就是累赘了，原生应用肯定是最好的选择。

【互动：让大家想想自己想开发怎么样的app 找两位同学说一说】

【承上启下】那应用类型、形式、平台选择好了 下一步要做什么呢？问两位同学（其实不是开发 是设计）

【设计】〇

什么是设计

苹果公司为什么成功？是硬件软件的科技嘛？我觉得更多的是设计 好的设计让软硬件结合起来 实现了好的系统。苹果算是全球数一数二的设计公司。

回到现实中，盖楼、建房子的时候没有图纸怎么盖啊？第一步一定是画图纸

一样的，没有设计方案，直接去写代码一定是空中楼阁

一般来说都是想好了再动手。开始写完整的项目代码前最好已经有详细的数据结构、UI、UX设计，如果代码已经写的差不多了又开始改需求、改设计、改文档的话，代码是比较难调整的，甚至要重构很多部分。这时有同学就会问了，怎么可能在前期思考的时候面面俱到呢？是的，但至少要想个八九不离十，如果前期设计走了歪路，后面应用开发就很难开发好了。

对于咱们信息学院的同学来说，可能不是很看重app的设计（我大一的时候就是这样），不论是UI还是UX。实际上用户拿到你的app第一眼看到的就是你的界面，而不是你的功能。UI设计的好，用户的体验很容易上去了；交互逻辑也是很需要重视的内容。工科的同学需要将设计看得重一些

设计包含什么

不仅仅是界面UI、交互UX、还有你的数据结构DataStructure、代码组织ProjectManagement；我愿意将这些都称为设计

  • 数据结构DataStructure：app基本上都是数据驱动的，你需要管理应用中的数据流。
    • 我们做的浣熊财记就是数据驱动的，所以最初设计数据时，我们用表格全部列出了我们需要的数据类型，后来使用数据库设计了数据关系。
  • 界面UI：用户一眼看到的就是你的UI，好的UI很容易给用户带来好的印象。
    • 我们当时迭代UI迭代了快5版，最终形成了现在的风格。最开始的app，拿给老师提建议的时候，老师就提到说，女生绝对不会喜欢这样的界面，有点阴沉。我们团队三个男生完全没发现这个问题，所以多去找别人看你的UI提建议也是很好的。
  • 交互UX：符合直觉的交互、或者简明的交互不至于让用户在你的app中迷路。
    • 我们当时设计界面的主逻辑的时候，考虑给左边添加一个设置栏。但左侧的边栏真的好用吗？小屏设备上还挺难搞的，不如就在下面放着一排的按钮来切换页面。
  • 代码组织ProjectManagement：基本上就是几个人如何合作的问题，因为开发app很难是一个人的事情。在代码细节上，更多是哪些文件要放到哪些文件夹，项目到底有几份可执行文件，Git使用的规范是怎样的……等等。这些都会影响实际的开发效率。如果组织的好，打开工程看到的就是清楚的思路和逻辑；组织的不好，想修一个bug半天都找不见要改的地方在哪里。

设计其实是一个整体规划，如果不知道从哪里下手，可以先看看官方的一些设计文档。

不同设备的不同设计思路

我这里以苹果的HIG（Human Interface Guideline）为例，做一个简单的说明。

各个平台的Design Themes 和 各种系统UI组件的推荐使用方法

  • 电脑
    • Flexible
      • 窗口大小可调整
      • 一个操作可以从右键、菜单栏、工具栏等多种方法调出
    • Expansive
      • 一般电脑的屏幕是很大的 有时还会外接显示器
      • 全屏模式适配
    • Capable
      • 一个小的操作背后是专业的处理
    • Focused
      • 电脑是生产力工具 设计UI时需要考虑让用户保持专注
  • 手机
    • themes
      • Clarity
        • 凸显重要内容
      • Deference
        • 动画呈现页面、元素间的逻辑
      • Depth
        • 用深度呈现层级
    • principles
      • Aesthetic Integrity
        • 有冲击力
      • Consistency
        • 应用内组件交互呈现一致性
        • 尽量与系统的组件和交互一致
      • Direct Manipulation
        • 即时处理用户的输入
      • Feedback
        • 动画
      • Metaphors
        • 与真实世界物理形成类比
      • User Control
        • 给用户足够的指引和说明
  • 平板

好的app有哪些特质

  • Good apps are ... （210519 开发前沿技术分享 —— 王恒进 WWDR）
    • focused：解决一个具体的问题，而不是在一个app中做很多事情
      • 这个其实是和很多商业app相违背的 比如微信知乎淘宝B站 你会发现它们的功能越做越复杂 app越来越臃肿 这个也没有办法 因为一个平台有了用户流量之后很难再开始一个新平台
      • 我们如果想做一些初创的app 其实不需要考虑太多 只要把app的亮点尽力展现出来就好了
    • effective：也许app背后的功能很复杂，但呈现给用户的应该是容易上手，好用、易用的app
      • 比如颜色：一个按钮调出调色盘 这个调色盘能不能支持各种工作者的调色需求呢？能不能支持各种颜色标准呢
    • accessible：无障碍、辅助功能面向的人群非常广，让app触达每一个人
      • 比如对于视障听障人士来说 你们团队制作的app是否易用呢？
      • 当然不仅仅是对残疾人来说。比如我现在使用的放大镜功能、比如为我们父母那一辈添加更多的指引、把开屏广告的关闭按钮放大一点等等
      • 不是那么必要 但是很能体现人文关怀
    • modern：指技术上的现代化，让app构建在最新推出的技术上
      • 比如 AR NLP IoT WIFI6 Bonjour
    • delightful：讨人的，好玩的。一个app应该让用户感到愉悦
      • 大概是一种综合感受吧 可以将你做的应用拿给其他人看看他们的感受

设计的呈现和具化

  • 思路
    • 草稿纸和铅笔 or iPad和Apple Pencil
    • 文本编辑器 备忘录
    • 在线文档
  • 进一步整理思路
    • 思维导图软件：Xmind
    • 在线文档
  • 设计文档
    • Markdown、Word等格式化文本
    • 非常重要 有了设计文档 设计人员和开发人员才能一起合作
    • 包括但不限于 UI UX 数据结构 代码组织
  • 用户交互设计 UX 和 矢量界面设计 UI
    • Adobe XD、Sketch：专业的界面设计软件，有界面、有交互。Sketch是macOS平台独占，我用起来感觉还挺爽的。
    • Apple Design Resources 这是苹果给出的设计资源，可以看到给了Sketch和XD的模版。
    • 下策：emmm Powerpoint/Keynote 能画矢量图的
    • 总之你需要让你的应用成型 能够展现给开发人员 让开发人员知道从哪里入手

【开发】高效编写代码

设计远比写代码重要

再说一遍：一般来说都是想好了再动手。开始写完整的项目代码前最好已经有详细的数据结构、UI、UX设计，如果代码已经写的差不多了又开始改需求、改设计、改文档的话，代码是比较难调整的，甚至要重构很多部分。这时有同学就会问了，怎么可能在前期思考的时候面面俱到呢？是的，但至少要想个八九不离十，如果前期设计走了歪路，后面应用开发怎么都开发不好了。尤其是在团队合作的时候，一定要把思想落实下来到纸上，否则别人可理解不了你自己在想什么。

工程设计

提前设置好工程的各种属性 最好去查一些资料 这样后面事半功倍（什么是工程 其实就是一个文件夹哈 里面装了应用的代码文件和资源文件）

苹果这边就是Xcode Windows的话是Visual Studio 安卓的话Android Studio 其他的工程一般用包管理工具或者make

像我们的浣熊财记其实工程设置还比较复杂的 但相对来说开发起来就比较容易（Dev版本 语言设置）

技术探索

从操作系统的角度来考察app：应用应该是基于操作系统提供的服务的。

系统提供了的服务就别重复造轮子了；操作系统提供的是非常多的，可以将文档通读一遍看看哪些传感器、哪些加速芯片、哪些系统的网络AI可以直接调用（Apple Developer | Technologies）

GitHub上搜一搜看有没有类似的app或框架：比如我们在开发浣熊财记的时候就找了语音识别的SwiftSpeech库

个人编写

  • 熟练掌握Git
  • 时常refactor
    • 所有的commits中，refactor应该要占比较大的比例
    • 多写注释
  • 边学习边写
    • Google / YouTube / Bilibili / Documentation
    • 多写博客

多人合作

  • 制定规范
  • 多交流
    • 其实就是开会ww
    • 线下交流可能会更效率一些，如果有条件还是尽量组织线下的交流吧

测试添加

测试可能大家比较陌生哈。对于小型app来说，你运行程序，然后通过打印调试信息和应用的实际表现来判断程序是否正常执行，其实这就是测试。但一般来说，测试指的是自动化测试，让机器去自动检测程序的功能是不是都正常运行；包括等值判断、抛出错误检测（以用户登陆为例）。在大型的工程都会这么做。

那么测试重要吗？

  • 对于语言工具包来说，由于无法直接运行，所以测试是必要的。你甚至是在面向测试编程，可以先写测试代码，然后按照测试代码来写你的程序，也即面向测试编程。
    • 比如我之前做的一个标记语言解释器ExMark
  • 对于个人开发的程序来说，无论是命令行程序还是GUI程序，测试都可有可无，大多是时候，是没有必要添加测试的。首先直接运行即可查看成果；专门添加测试反而会浪费时间，更不用说应用的结构可能随时会改，测试的代码也需要不断更新。
  • 对于开源程序来说，自动化测试是比较需要的，别人提交的代码有没有问题呢？在别人添加新功能的时候有没有破坏现有的功能呢？给开源的仓库添加自动化测试会让开源项目的管理变得轻松。
  • 对于大型团队开发的程序来说，首先要做好数据的封装和代码的模块化，然后做模块化测试。这是非常必要的，能够发现很多边界情况。甚至会有专门的测试人员来编写测试代码。

ExMark测试片段：

Swift
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
class Test_element_code: XCTestCase {
    func test_common() {
        let file = """
        [c](code)
        """
        let ans = """
        <p><code>c</code></p>
        """

        let html = Render_Document_to_HTML(Parse_Lines_to_Document(Parse_File_to_Lines(file)))
        XCTAssertEqual(html, ans)
    }
}

在讨论测试的时候，往往会说到持续集成（Continuous Integration, CI）和持续交付（Continuous Delivery, CD）。一般的话，是结合Git的commit或push功能，在每次远程仓库检测到新的代码时，就进行自动测试，没有问题则直接发布。你会发现很多app不断在应用商店更新，这些不会是工程师手动提交的，是由云端仓库自动打包代码生成应用自动提交的；网页也是一样的道理。我知道的CI工具有 GitHub workflow 和 Xcode Cloud。

本篇文章发布的方式 .github/workflows/issueMySite.yml：

Text Only
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
name: publish site
on: # 在什么时候触发工作流
  push: # 在从本地main分支被push到GitHub仓库时
    branches:
      - main
  pull_request: # 在main分支合并别人提的pr时
    branches:
      - main
jobs: # 工作流的具体内容
  deploy:
    runs-on: ubuntu-latest # 创建一个新的云端虚拟机 使用最新Ubuntu系统
    steps:
      - uses: actions/checkout@v2 # 先checkout到main分支
      - uses: actions/setup-python@v2 # 再安装Python3和相关环境
        with:
          python-version: 3.x
      - run: pip install mkdocs-material # 使用pip包管理工具安装mkdocs-material
      - run: mkdocs gh-deploy --force # 使用mkdocs-material部署gh-pages分支

【维护与迭代】第一版上架前后

时间不够时的取舍

第一版应用大概会有很多bug lol 这很正常

在比赛最终评审或者要交付上架应用的时候，你的应用大概不能有太多明显的bug吧，时间别卡那么紧，可能需要提前规划一下

也不要有什么压力，第一版做出来之后你很快就能看出要改进的地方；万事开头难，只要你做出第一版，后面的更新迭代是很容易的

如果时间确实不够 或者你们想实现的功能太多 emmm 总之选最重要的吧 如果时间特别紧 就选那些相对独立的模块

注意收集用户建议

当时我们浣熊财记团队设计的app，在移动应用创新赛的答疑环节，一位年轻女老师就指出，我们的配色太深了，女生是不会喜欢的。确实我们团队三名男同学没注意到这一点。

还有我当时拿着浣熊财记在iOS Club参加过一次微沙龙，然后就有两个同学就指出，上面的那个大卡片好像没有什么用。我觉得说的很对，然后我们团队就取掉了。

考虑吸收别人提出的建议总是好的

简单聊聊开源

开源、保证架构演进正确，不仅仅是你把代码po出来别人看。如果一个开源代码得不到从社区来的issue、pr，那么我觉得这个开源可能没有太大的意义。当然一些练手的项目确实想让一些萌新看到一个框架怎么实现，开源是很不错的，毕竟GitHub是「代码托管平台」。

有的同学就把自己的编程作业或者大作业po在GitHub上，我的话就比较反感这样的行为，因为说实话没有意义啊，学弟学妹看到了，减少了练习时间，很久很久也不会有人帮你改进这些作业；我比较欣赏的是一些同学把自己整理的考试半开卷的A4纸的LaTeX源文件开源，这样学弟学妹可以用，里面有错误也可以帮忙改进，这样几年过去，这一份A4纸会越来越完善，开源的目的就达到了。

在选取开源许可证的时候，也要注意不同许可证的区别。比如我们的项目最后使用了GPL-v3的协议，这样能让开源项目形成回流，创造出更好的应用（虽然现在还没有人pr就是了ww）。想了解开源许可证的基本信息和不同开源许可证的区别，可以看看微信 | 微月人话 - 从MIT协议谈契约精神。

ps. 要开源的话就认真写好README哦～

【其他】

app的读法

app读/æp/，最好不要读成A P P，因为app本身是application的缩写。

自我介绍 续

大家可能会比较好奇哈，我一个电子系的同学，为什么和软件走的这么近呢？电子系其实比较软硬兼顾，本科阶段学习的内容比较基础、大类培养。当然这也与我自己的爱好有关系，我比较喜欢编程，感觉写代码来操控电脑这件事情很酷；很喜欢macOS，因此也花了很多时间来研究系统和软件相关的知识；另外我也致力于使用软件提高自己的工作学习效率，如果市面上没有软件我就会想着开发一个来自己用；还有呢就是我喜欢和志同道合的人交流，第一次在GitHub上收到外国人的评论是真的很开心。

搞软件，比较重要的可能是技术。我进入大学之前是很少用过电脑的，虽然当时对编程一无所知，但是选了学校的App Inventor开发课程，我记得做过记单词的app。大一的时候学习了C和C++，我记得当时寒假我用Qt做了一个记账本；大二的时候加入电子系科协软件部网站组学习了前后端知识，当然还有Markdoown啊Git这类开发不可或缺的工具；大二我还加入了新成立的iOS Club，遇到了很多一样在开发苹果平台应用的同学；在大二的暑假，我报名参加了移动应用创新赛，成立了浣熊财记团队，最终获得了华北赛区一等奖，国赛二等奖的好成绩。一路走过来，我自己也对软件开发也有了很多自己的认识，想和大家分享一下自己的一些经验。

浣熊财记简介

  • Bilibili｜CCCC 浣熊财记介绍
    • 包含软件使用演示 答辩Keynote展示
  • 浣熊财记简介
    • 浣熊财记 是一款新时代针对大学生和刚步入社会的青年的财记软件。
      • 记账快捷简单：截图一键导入，语音智能识别
      • 沉淀生活轨迹：花销折射生活，财记凸显回忆
      • 定制标签关注：标签多维管理，关注核心呈现
      • 注重情感体验：浣熊相伴成长，成就激励前行
    • 记账已经是老生常谈的话题了，但事实上其有旧难题和新挑战，比如记账麻烦、分类让人纠结、管理让人不爽、新的消费形式难以记录等等。
    • 浣熊财记 则针对这些问题和挑战，结合调研结果，提出了新的记账形式，以便捷的技术实现在移动端，让记账快捷简单、分类方面全面，努力沉淀生活轨迹、注重使用者的情感体验。
  • 浣熊财记海报
  • GitHub｜浣熊财记
    • 浣熊财记使用苹果新推出的UI框架SwiftUI构建
    • 目前已经在GitHub开源，欢迎感兴趣的同学一起维护开发

CCCC简介

第六届 中国高校计算机大赛 移动应用创新赛 苹果公司和浙江大学联合举办

从6月报名、7月初初赛、8月底复赛、10月底决赛（今年因疫情推迟到12月）

  • 初赛有一个项目的说明文档就可以了 两页左右
  • 复赛就需要更详细的设计方案了 还需要制作介绍视频等
  • 决赛则需要进行现场展示，需要制作Keynote，海报、1min展示视频等

我们「浣熊财记」团队，通过初赛在复赛中获得华北赛区一等奖，在全国总决赛中获得二等奖。去年咱们学校还有一个背单词的项目也获得了国赛二等奖。

iOS Club 简介

THU iOS Club 官方的称呼是 清华大学未来移动应用学生科技兴趣团队。

成立比较晚，具体来说是前年（2020年4月）才成立的，社团也仍在探索期。目前比较主要的事务就是组织大家参加CCCC。

欢迎大家关注 iOS Club的微信公众号