标签: code-organization

假设我有一个这样的命名空间:

var myNamespace = {
    foo: function() {
    },
    bar: function() {
    }
};

将此代码拆分为定义foo和bar单独的文件的最佳方法是什么？

我并不担心加载时间 - 我会在部署之前将其连接回一个文件.

我是软件开发的新手.我个人认为,分层体系结构是一种很好的方法,可以减少面向对象方法中软件开发过程中出现的复杂性,更不用说保持代码的有序性.现在,我遇到了一些DDD(Domain Driven Design)引入的问题.当然,初级水平的.
这就是 -
让我们说,我想构建一个应用程序来保存数据库中的"人"相关数据,并在wpf数据网格中显示人员详细信息(DDD绝对不适用于这种规模的应用程序,但只是为了简化像我一样的业余爱好者).所以,我设计了一个域类"Person",类似于 -

    public class Person
    {
        public Person(dataType paramA)
        {
            this.PropertyA = paramA;
        }

        private dataType _fieldA;
        public dataType PropertyA
        {
            //encapsulates _fieldA    
        }

        public dataType PropertyX
        {        
            //some code that manipulates private field    
        }

        private dataType MethodPQR(dataType param)
        {        
            //some code    
        }
    }

现在,我对DDD的理解说,架构(最简单的版本)应该如下(如果我错了,请纠正我) -

注意:

1. 我希望datagrid绑定到一些ObservableCollection,只是为了立即反映任何类型的更改.

2. 它是一个wpf应用程序,但不一定是MVVM模式,我故意想使用后面的代码(我不知道后面的代码本身是代表应用程序层)

所以我的问题是 -

1. 什么样的代码应该属于应用层？

2. 我的猜测是,我绝对不应该将我的域对象(Person)的ObservableColletion绑定为datagrid的itmsSource.那么我应该从域对象中提取什么类型的对象,以及如何？

3. 为了保持表示层对象和域层对象之间的解耦,可能存在类似的约定DataGrid.那么非"直接"方法是什么？

4. 如果Code-Behind与应用层进行对话,那么应用层应该与存储库进行通信吗？但是,如果需要某种类型的域访问而不是与数据访问相关(可能不在此应用程序中,但它可能会发生,对吧？),应用层应该与哪个域人员层中的X人进行对话？

我知道我所有的问题和问题都是非常业余的.但它们确实是问题和问题.所以,如果有人有时间,任何回复都将受到赞赏.

编辑:我不确定Data Repository是否应该有域模型的引用.

我不明白使用Xcode工作区来组织彼此依赖的项目.例如,我看到很多开发人员创建的工作空间结构如下所示:

Workspace
|-- App
|-- A Common Library
|-- Another Common Library

这提供了什么好处？如果有人直接打开"App"项目他们是不是无法实际构建应用程序？他们必须意识到工作空间存在必要的依赖关系.

在我看来,更好的方法是使用这样的嵌套项目:

App
|-- Libraries
|   |-- A Common Library
|   |-- Another Common Library

然后,不存在无法构建的项目.它似乎更符合Git关于子模块的想法.

我在工作空间中看到的唯一用途是将常见项目分组,彼此之间没有依赖关系.我想听听别人对此的看法,因为我可能会遗漏一些东西.

标头/ cpp文件中应标头的顺序是什么？显然,后续标题所需的那些应该更早,特定于类的标题应该在cpp范围内而不是标题范围,但是是否有一个集合顺序约定/最佳实践？

我应该如何为程序而不是库命名我的Haskell模块,并将它们组织在一个层次结构中？

我正在做一个叫做Luminosity的光线追踪器.首先,我有这些模块:

Vector Colour Intersect Trace Render Parse Export

每个模块都很好,但我觉得这个组织缺乏.

首先,我把每个模块放在下面 Luminosity,所以例如Vector现在Luminosity.Vector(我认为这是haskell程序的标准？).

然后我想:矢量和颜色是独立的,可以重复使用,所以它们应该分开.但它们太小而无法变成图书馆.

他们应该去哪儿？已经有(上hackage)一Data.Vector和Data.Colour,所以我应该把它们放在那里？或者这会引起混淆(即使我将它们与我的其他本地导入一起导入)？如果没有,应该是Luminosity.Data.Vector或Data.Luminosity.Vector？我很确定我已经看过两个都用过了,虽然也许我刚刚看到一个使用非传统结构的项目.

我还有一个简单的TGA图像导出器(Export),可以独立于Luminosity.它似乎是正确的位置Codec.Image.TGA,但同样应该Luminosity在某处,如果是的话,在哪里？

如果Haskell项目的结构或其他维基解释了这一点,那就太好了.

使用AutoOpen属性的推荐原则是什么？

(这个问题可能是在类似命名类型上何时使用模块功能VS静态功能的延续)

专家F#指出"当你定义ad hoc顶级运算符和函数时,这可能很有用:"

因此,这似乎可以减少代码组织中的模块角色,当您在技术上需要编写代码但从客户端角度删除它的存在时.

还有别的吗？你什么时候使用它？

我遇到了一些在头文件中有一个大的静态函数的代码,我只是好奇它是不是可以做到这一点.例如,如果许多.c文件包含标题,为什么不直接定义非静态函数并将其链接？

关于何时/何时不将静态函数定义放在C中的头文件中的任何建议或经验法则,我们将不胜感激,

谢谢

我正在使用GIT来管理内容管理系统(CMS)项目.CMS可以有多个插件(模块).

所以基本上,我想拥有3种类型的存储库:

• 核心CMS开发(每个新项目都是最后一个稳定和未配置版本的结帐)
• 每个模块/插件1个存储库.(每个新项目都会检查他们想要实现的模块的最后一个稳定版本)
• 每个项目1个存储库(每个客户端将是一个存储库,代表来自核心CMS和模块的个性化)

对于类型1和类型2,我猜它是简单的基本存储库.但当涉及到客户项目时,我感到困惑:

• 首先,我将克隆CMS,然后进入/ modules /文件夹并再次克隆所有必需的模块？这将在存储库中创建一个存储库!第一个repo会尝试记录每个模块的.git /文件夹吗？
• 我无法使用子模块,因为每个客户端都需要对其模块进行个性化.
• 如果我修改模块的核心组件(不是个性化,只是修复错误),我可以将该单个文件推送到原始模块存储库吗？
• (不是说会传播到周围的模块unitTest)

所以问题是:我应该如何组织存储库/文件/文件夹以提高效率？

你有什么时候做单元测试

• 一些一般的单元测试
• 更复杂的测试检查边缘情况,取决于一般情况

举个例子,想象一下测试一个CSV阅读器(我刚刚编写了一个演示符号),

def test_readCsv(): ...

@dependsOn(test_readCsv)
def test_readCsv_duplicateColumnName(): ...

@dependsOn(test_readCsv)
def test_readCsv_unicodeColumnName(): ...

我希望只有在父测试成功的情况下才能运行子测试.这背后的原因是运行这些测试需要时间.许多失败的报告可以归结为一个原因也不会提供信息.当然,我可以把所有边缘情况都塞进主要测试中,但我想知道是否有更有条理的方法来做到这一点.

我发现了这些相关但不同的问题,

• 如何构建具有依赖关系的单元测试？
• 单元测试 - 让单元测试调用其他单元测试是不好的形式

更新:

我发现TestNG具有很强的内置支持测试依赖性.你可以写这样的测试,

@Test{dependsOnMethods = ("test_readCsv"))
public void test_readCsv_duplicateColumnName() {
   ...
}

我目前的项目变得非常庞大.我有许多活动,适配器,片段,布局xmls和其他资源.

在我(较小的)之前的项目中,我组织了1个包/ 1类别样式的东西.所以我有com.stuff.xy.adapter,com.stuff.xy.activity,等等.现在这些包包含太多项目,我发现自己浪费了大量时间在包层次结构中搜索特定的类.

我使用Eclipse,并且有一些可以使用的快捷方式(例如转到类定义),但那些往往是情境化的(我不能用它来快速跳转到布局定义xml).

你能否分享一些有效组织大型项目的技巧？或者也许是一些插件？(例如,如果我可以将处理特定应用程序屏幕的源文件组合在一起 - 适配器,布局,活动和片段代码 - 这样我可以快速打开它们)

编辑:经过几个月的大型项目开发

首先,我尝试使用Eclipse工作集.它并没有真正为我减少,我的问题是我们的单个Android项目太大了,包含许多资源,类,接口等.在单个项目的上下文中处理工作集只花了太多时间,我认为它们主要用于在单个工作区中组织项目.

从长远来看,我们将我们庞大的单个项目分成了许多较小的android-library项目和一个依赖于所有这些较小的项目的"主要应用程序"项目.通过这种方式,我们可以在这些库项目之间分割资源(有许多布局,值,样式仅在应用程序的某些部分中使用)和代码.我还创建了一个基础库,所有其他库都依赖于它,并包含应用程序每个部分所需的资源和(基础)类.