随着团队的成长，如何在整个应用程序体系结构中保持一致性？

46

作为一家创业公司的唯一开发人员，我能够在我们的应用程序的体系结构和框架中做出很多决定。

快进4年，后来又进行了收购，我有一支5人的团队，很多时候感觉就像是荒野的西部。做出任何设计决定的人都会喜欢它们：在一个地方将DB类型的整数和枚举放在一个地方，在另一个地方使用字符串，此问题的框架，然后在其他地方针对同一问题的不同框架，等等。

如何执行一致性？对我来说，这很重要，但是我的团队成员似乎赞成“如果有效，那么有效”的方法。

我想我的问题很大一部分是：期望这样的标准对我来说是不现实的吗？我遇到这样一个想法：作为扼杀创造力的独裁者，但是做他们想做的事情似乎是不可扩展的。

architecture management team-building

— Deekor
source

8

您能否就现有的SDLC流程向我们提供尽可能多的信息？您是瀑布，敏捷等吗？您使用TFS还是任务管理？您执行代码审查还是使用FxCop或其他形式的代码验证？您是否制作设计文档？您有指定的建筑师角色吗？

— 吴敬达

1

可能重复做

— 蚊蚋

1

@gnat：如果答案有任何暗示，则不是一个很好的重复。

— 罗伯特·哈维

2

公平地讲，这些标准应该在很早就根据一些公认的“最佳实践”文件制定，因此没有人可以抱怨偏itis或精英主义。如果您很难从一个人那里得到压力，那么您就必须考虑一个牛仔对其他团队是否值得拥有一个健康的环境，并替换掉那个牛仔，反正他们会很早就离开，他们总是这样做。然后，我认为下面给出的所有建议在签入之前使用严格的代码审查并添加体系结构组件都将产生奇迹。

— Patrick Hughes

1

这是软件工程的圣杯（除了另一个圣杯，这是准确的需求启发）。

— PMF

52

是什么让您如此特别？

我的CPU说正常，我想回家。你为什么要打扰我？

您可以通过强迫所有人发出拉动请求来应对这种态度。但是现在截止日期迫在眉睫。错误的代码压在您原始城堡的大门上，您最终屈服于压力。否则，您赢了却发现所有人都离开了，没有人使用您的原始城堡。

有很多工具可以解决此问题。源代码控制，代码审查，编码标准等，但问题的核心和实质是您对最佳内容的主观意见必须被视为相关。为此，您必须赢得并保持他们的尊重。这样做，这要容易得多。这样做失败，没有任何工具或实践可以拯救您。

最好的方法是尽早沟通。在我确定了这个想法的6个月后，不要告诉我“我们在这家商店中不对数据库类型使用字符串”。告诉我它已经被埋藏在文档中两年了，这让我没有理由。

无论出于何种原因，您都有所关心的事物。如果您关心它们并有重点，请在每个模块的编码之前，之中和之后立即清楚地传达这些内容。

跟踪代码是一种绝妙的做法。投资所需的任何工具和实践，以便您可以在编写代码后的几分钟内查看代码。配对程序和工具只是一个客人椅子。

为什么？我编写代码后经过的每一秒都会成倍增加更改它的成本。那是因为我对代码的记忆只有一半的寿命。当我的膀胱需要休息时，我开始忘记它。

将您关心的事物减少到其基本原理。与其给我列出101条要遵循的规则，不如给我介绍它们违反的10条原则，这样我就可以找出应遵循什么规则102。

通过帮助我看到您的想法，使我能够强加自己的愿景，我们会相处得很好。

我期望像这样的标准是不现实的吗？我遇到这样一个想法：作为扼杀创造力的独裁者，但是做他们想做的事情似乎是不可扩展的。

那不要管教！使这成为积极的经历。这不是一些新时代的嬉皮话。这是基本心理学。您正在尝试修改人类行为。随机和积极是最有助益的（请问拉斯维加斯）。如果您消极，则必须与您的强化保持一致。那是无法企及的痛苦。传播智慧时要保持积极态度，您可以随随便便。

我知道你来自哪里，因为我去过那里。您已经控制了，现在不见了。你要回来。好吧，克服它。现在您有了一个团队。他们不需要被控制。他们需要的是领导才能。您需要的不是控制权。影响力。它工作得更好，而工作却少得多。掌握并放松。这应该是有趣的。

只要做对了，您就可以休假了，这仍然会起作用。怎么样？通过不仅成为领导者，而且使其他人也成为领导者。一旦将您的愿景灌输到团队中，他们就可以在您离开时通过模仿自己所做的事情来工作。指导新手，并鼓励他们加强和影响他人。

我知道这很难。我们没有涉足这个行业，因为我们善于与人打交道。我们与代码进行最佳沟通。没关系。只需快速且经常执行即可。告诉我你的为什么更好。听我说不是。在我还在考虑的时候这样做。我喜欢编码。在这个星球上，我几乎没有人可以谈论。成为其中之一。

— 橙色蜜饯
source

4

很明显，您所说的“跟踪代码”是什么意思……但是google除了世界各地的犯罪法外，没有给我任何帮助。

— 杰里米

3

加上“编码标准”的名单

— BЈовић

5

由于我似乎正在介绍该术语，因此我将给出“代码跟踪”的词源。我已经签入了一些代码，这些代码使用抽象工厂来获取其时间戳。一位同行开发人员尝试合并（签入代码），并且自签出以来一直在滚动更改代码。她注意到我的工厂，以为这很好奇。她不确定为什么我要这么做。于是她走过去问我。当我看上去很困惑时，她说：“哦，我只是在跟踪你。” Facebook正在改变我们的词汇表。

— candied_orange

1

真正！“ 通过帮助我见到您，使我能够强加自己的视野，我们会相处融洽。 ”诗歌，代码和哲学融合在一起时，我很喜欢！

— Pedro Lobito

@candied_orange：我对整个“代码跟踪”感到困惑。你只是在戳她吗？在您回答的上下文中，似乎她会在代码中缠扰您。

— 罗伯特·哈维

23

首先，让人们维护自己未写的东西。开发人员很容易养成使用他们习惯的框架和技术的习惯。必须在框架和方法之间进行切换，这很烦人。如果有人被迫离开自己的代码角落并经常经历，这将引发一些抱怨，并希望引起一些富有成果的讨论，这些讨论可能导致人们希望对某些事情进行标准化。

接下来，提取请求和代码审查。未经代码审查，切勿将代码合并到您的主分支中。任何人都可以做到。同样，当某人看到与他们本应做的事情不同的事情时，它可以促使讨论和团队合作以寻求更好的解决方案。它还使每个人都照看代码库，这（希望）使人们关心它以及其中包含的代码的状态。

最后，进行设计讨论。它们可以是正式的也可以是非正式的，但是可以有。让那些想参加的人参加。讨论您要使用什么框架，枚举与整数的优缺点，等等。然后做出决定并将其记录在某个地方（例如标准文件）。然后，您可以指出何时出现问题。同样，不要害怕重新审视标准决策。技术会（迅速）变化，因此团队和公司的需求也会随之变化。

帮助人们看到您所看到和感觉到的东西，就像他们对代码的质量有好处。然后，在出现意见分歧时，轻轻地推动讨论以寻找标准。

— Becuzz
source

这种方法的好处是，经理不仅要强加自己的偏好，他还给团队提供了决定的机会，并赋予他们权力来执行它。

— 罗宾·贝内特

6

每当有人想要将代码合并到主分支/主干中并在检查代码时使人们遵循这些标准时，都要执行代码检查。

我并不是说只有您应该执行代码审查。每个人都应该查看其他人的代码。这样可以在整个团队中传播有关系统的知识，但同时也会导致Carol检查Bob的代码并说：“我看到您在那里使用了整数。我总是使用枚举。” 他们发现您所看到的差异，并且假设他们关心，他们将意识到每个人都必须走在同一个页面上。

可接受的，商定的标准将出现，此时您要记录下来并确保人们遵循它们。这将包括诸如“ ...中的数据库枚举”之类的内容。您还可以包括记录要使用的框架等。

— 马修
source

我想我的问题很大一部分是期望这样的标准对我来说是不现实的。我难以接受一个扼杀创造力的独裁者的想法，但是做他们想做的事似乎没有可扩展性

— Deekor

3

@Matthew，虽然我通常同意您的意见，但我会以相反的顺序进行。首先进行设计审查，然后在设计审查期间/期间制定准则。如果您将编写所有内容的重担放在架构师/负责人的头上，那将重担转移到了干预者身上。

— 尼克·阿列克谢夫

@Deekor：你必须选择战斗。找出需要放下的脚步，并记录下来。您不必决定一切。

— 罗伯特·哈维

2

@Deekor，您可以执行标准和通用编码实践，而无需“扼杀创造力”。无论如何，这是一个虚假的论点。通用的编码标准导致易于维护的软件。免费的编码导致噩梦。

— 马修

1

@尼克亚历克斯耶夫，我同意；将进行编辑。

— 马修

1

在可能的情况下，您可以编写工具/脚本来自动分析项目，并确定项目使用的标准，工具和方法。您可以通过在CI构建中运行自定义工具来实现此目的。

将工具的输出写入“记分卡”文档，例如带有单位（例如，每个“应用程序”或项目或api或其他）的行的google工作表，其后是各度量标准的列。这将使人们了解现有标准，采用程度如何等，并为混乱提供一些秩序。

您也可以手动更新列，但祝您好运并保持最新：D

— mcintyre321
source