团队项目计划

这是现代软件工程课程团队项目计划作业，我们团队的项目题目是一个 Julia 调试器 Judy。

团队项目计划

写出项目的 NABCD。

需求：Julia 调试器是一个辅助性需求，并在很大程度上依赖于 Julia 语言本身，但我们能看到社区中许多人因为各自不同的原因希望有好用的调试器。

做法：资源方面，我们身边有真实的 Julia 用户、有工程经验的导师，亦容易获得来自 Julia 开发团队或 VS Code 团队的专业支持。技术方面，我们打算基于 julia 现有的执行器实现一个 binary 的调试器，而不是像多数社区项目一样通过宏实现，这样既降低了我们的开发难度，也更容易避免调试器本身受到被调试代码的影响而出错。

好处：对于用户，这将是第一个正常的 Julia 调试器，既不需要修改被调试代码，也不需要学奇怪的工作流就能使用，非常方便。对于 Julia 团队和微软，这也是双赢的一件事。

竞争：目前大家主要有这几种调试手法或工具：不用调试器，直接打印变量（需要反复运行并改代码）；用 gdb 调试（需要学习复杂的工作流）；用基于宏的调试工具（质量不佳，学习成本高，需要改代码）；用简单 IDE 自带的单块代码执行功能（只适用于短小程序）。可以看到没有一个方法支持大家习惯的“断点——单步执行——查看调用栈——修改——恢复执行”工作流。

交付：最好的交付方式是让 Julia 团队认可我们的产品，并写进官方文档和新闻中，这样能产生最大的影响力。

数据：做了用户调查，并在此基础上确定了需求和做法。如果成功实现的话，和现有竞品相比的优势是显然的。

对目标用户的用户调研，选取一种调研方式，记录调研的过程和结果。

采访了真实的 Julia 用户，收集到的主要信息有：

• 现在不能在运行中查看变量是一大痛点；
• 尚未用过多线程或多机运行的功能，这方面暂无调试需求；
• 未用过 gdb 调试或基于宏的调试工具，因为太麻烦了，目前还没有这么依赖调试器；
• 目前主要在用 Juno，可惜它不能打断点，只能在程序执行完后看到变量值，或者分块执行；
• 用打印语句手工调试也不是不能接受，除非确实有好用的调试器。

典型用户：典型用户是谁？他有什么特点？
典型场景：典型用户能通过 <某个场景> 完成他的某个任务，他之前有什么痛点，这个痛点是如何在几个相关联的步骤中被解决的？

这里我们可以偷个懒——软件行业经过这么多年的发展，无数人早已总结了好用的调试工作流，并以此为理念设计了各种 IDE。我们的目的并不是设计直接和用户打交道的 IDE，而是让现有的优秀的 IDE 支持调试 Julia，因此现有的 IDE 的调试功能需要我们提供什么接口，我们就怎么对接即可。

列出本团队代码规范是什么。

现在项目尚在规划阶段，我和其他团队成员也是第一次合作，不熟悉大家编码和工作流的习惯，需要在完成一些编码工作后才能视情况决定。

把本阶段所有计划要完成的任务都列出来，输入到项目管理软件中。

我们使用 GitHub Project 进行任务管理，以避免干扰 issues 的正常使用。

计划一个冲刺 (Sprint) 所需要的时间（在软件工程课中，一般是 10 天），说明哪一天开始，哪一天结束。并且注明每个团队成员在这 10 天大概计划投入的时间是多少小时。

我们计划为 2018-11-26 至 2018-12-05，共计 10 天，每天每人投入约 5 至 6 小时，其中约 4 小时编码，其余时间做代码评审、讨论、总结。

以终为始，写一个新闻报道，描述你的新产品在新闻发布会上的情况。

Judy - Julia debugging just made easy!

Debugging Julia programs has long been a painful experience. Now with Judy, you can finally set breakpoints, step through codes and browse all the stack frames, just in the familiar way.

Judy is a Julia debug engine, with a VS Code plug-in as front-end. It allows you to debug Julia programs directly using the debugging features of VS Code, without having to insert macros or other nonsense into your code. You can also integrate it into other IDEs with little effort.

(put some wonderful screenshots here)

"This is how a real debugger should work!" - An anonymous user.

Want to contribute? Send an issue or pull request now!

项目经理可以描述一下自己在项目管理中的计划或心得。

我一直很喜欢《人件》中讲的各种道理，终于有了一个机会付诸实践，想做好这个工作，为团队中其他成员正确估计工作量、消除对生产力的干扰因素、做好沟通和协调。目前最大的心得之一是，召集大家一起开会既麻烦每个人，沟通效率又不是非常高（不是每个人都愿意在所有人在场时发表不成熟的意见）。所以我在尝试单独和每个人保持联系，希望可以更好地了解大家的能力、兴趣方向和当前遇到的困难。一个让我比较担心的难点是之后的任务分配，这个项目整体性比较强，我希望找一个既高效又让大家都能很好地参与进来的工作方式，但愿在规划阶段结束后我能更了解每个成员，做出合理的任务划分。