我开始研究一个相当复杂的软件.这是一个个人项目,但我仍然付出了很多努力.现在,我习惯于处理其他人的解决方案/设计或者以非常可控的方式发展的项目.
这一次,我开始两次编写基础知识,我很快发现自己陷入困境.所以我休息了一下,决定在编写单行之前写下完整的解决方案.我所做的(按顺序)是:
以CLI命令的形式编写用例(这是一个命令行应用程序)
写一些帮助
设计类,数据文件的结构和各个部分的功能工作流程.
现在,我整个部分都会变得很慢.我已经建立了一个个人维基,我用它来编写这些规范,但我清楚地感觉到我缺乏经验和明确的方法论.
我知道软件设计是一个非常复杂的主题,并且已经写了很多关于它的书籍,但我希望你能分享你的经验/建议/方法.
在处理个人中型项目时,您在开始编码之前指定了什么？怎么样？
提前致谢
有很多人比我有更好的经验来帮助你了解具体细节,但我认为总有一点值得记住.
你不需要第一次100%完美.事实上,如果你的目标是你甚至可能永远不会完成.实际情况是,在您构建系统一次之前,您将无法完全理解设计.
刚开始,继续前进,保持单元测试覆盖率的顶部,并且当您更好地理解系统及其复杂性时,然后逐步重构以改进它.
在处理个人中型项目时,您在开始编码之前指定了什么？
我指定了功能规范:
我担心这可能太容易了,如果我刚开始编码(这就是"怎么样"),忘记"为什么"和"我想编码什么"(对于"相当复杂"的软件,在几个月或几年内它可能需要发展).
我还想或多或少地理解我将要开发的"范围":为了大致评估(达到一个数量级):
它会有多大
我是否可以完成它
是否值得入手
可以首先开发它的哪个子集
为了风险管理,我要补充一点,我想要开发的一些内容暗示使用一些我不熟悉的软件; 为了最大限度地降低与此相关的风险,我还做了一点点丢失原型设计.
怎么样？
我概述了一个功能规范,使用笔纸.我写的一些内容是高级(业务级"愿景"文档),有些是较低级别的,更像是设计(一些UI细节).有时候我停下来并且对如何组织它感到困惑,但接着继续,推断每个页面对每个主题都有或多或少的凝聚力,以后我可以解释如何组织页面(很像你的wiki,也许).
我既做了也没有提前指定软件架构:
我开始考虑基本架构(一些小组件)开发,然后添加代码; 并且,我添加的代码,如果任何组件变得太大和复杂的话,我再细分成数个较小的组件...这是一个渐进的过程...因为它在说Systemantics,的复杂系统的工作原理是总是发现已经进化从一个简单的系统工作.
我不记录架构; 或者更确切地说,架构的唯一文档是代码本身:例如,源代码在源目录,命名空间和DLL中的排列方式.
我现在对架构有理论上的理由,但我没有记录这些原因:
我是唯一的开发者
代码记录了实际的体系结构
架构的原因在我的脑海中,并且可以通过源代码中的命名约定以及各种组件的依赖性来发现.
如果(仅当)我不是唯一的开发人员,那么我可能认为值得记录架构及其基本原理.
我上面所说的关于软件架构的内容也适用于软件处理的数据.
至于测试,我稍微编码然后测试它; 或编写测试,然后编写将通过该测试的功能.我没有做"大爆炸整合",即没有任何测试的几个月的写作.
我的流程中最大的缺点之一(或者缺少的东西)是提前估算工作量,然后根据估算跟踪实施情况......这是"个人"项目流程与付费项目之间的差异之一. d为商业上的其他人做.我怀疑这是否合适:如果估算是商业上的最佳实践,那么也许我应该在个人项目中做到这一点.
京公网安备 11010802040832号 | 京ICP备19059560号-6 