我们将继续与准备带领开发团队的人员分享
手册中的摘录。
在上一部分中，我们讨论了所有外来事物，其中包括等待技术领导者升任新职位，现在我们回到熟悉的事物-编程本身。 在这里，昨天的开发人员可以感觉到自己的元素，但是他不必放松身心-责任范围正在不断扩大和转移。 在cat下，我们简要概述了Rainwater在他的书中带来的所有新职责和适应技巧。
根本区别在于两个细微差别。 首先，线索要早得多地进入流程，直到胜利结束，才将其关闭。 其次，当开发人员专注于为他设定的狭窄任务时，他的老板会全面审查产品，而在情况需要时不要忘记详细介绍产品。 让我们与作者一起努力，并概述在应用程序创建的每个阶段团队负责人的角色。
要求和规格的定义
即使产品处于围产期状态，即产品的总体概念，要求或功能列表，良好的技术诀窍也可以与产品一起使用。 但是，在这里您需要立即澄清：Rainwater坚信开发人员不应参与营销人员或产品经理的工作，或者，他应该全力避免这种情况。 并不是说“技术人员”了解市场现实和商业要求是不可能的，也不是应受谴责的，但是将这两个角色结合起来是非常困难的。 除其他外，内部开发人员获胜的风险更大，并且产品的特性将根据程序员团队而不是最终用户的利益进行定制。 如果已经准备好产品的一般性功能方面的知识，并由知识渊博的人对其进行了测试，则工作起来将更加轻松，安全得多。
对于这两种角色的混合，在我们的分类中经常属于牛仔之类的开发人员经常提倡-他们渴望“车库”时代，这是由小型团队来回制造整个产品而无需外部交互的情况。 作者急于消除所有关于此分数的幻想：在现代条件下，技术和非技术小组之间的互动应该在整个应用程序生命周期中定期进行。 举行第一次会议是为了共同制定规范。 开发经理（或领先的开发人员之一）熟悉产品说明，从技术角度排除他认为不合理或不切实际的所有内容，并制定最终计划以将其翻译为技术语言。 然后，各小组会不时开会以“检查时间”，并确保实施与原始计划的偏差不大。
建议的此类会议的频率大约为每周一次，但是，当然，您需要调整总体发展速度和特定公司的流程组织功能。
出于其他原因，也将需要召开定期会议-偏离原始路线的尝试可能不仅来自开发方面。 为了保持竞争力，大多数应用程序都通过其他工具和功能不断增长。 因此，可以无限地重复考虑，评估和放弃想法的过程，只是规模要小于主要规范的规模。 对于Tehlid而言，紧跟产品开发计划非常重要-这不仅从组织角度为他提供了回旋的余地（职责分配，条款确定），而且还可以让您提前计算整个系统的后果，其和谐性和可持续性。
在同意使用一项新功能之前，您应该问自己几个问题：
- 拟议的变更在短期和长期内会对系统架构产生什么影响？
- 拟议的变更将如何影响将要发生的网络基础架构？
- 拟议的更改将如何影响用户与该产品进行有效和高效交互的能力？
- 拟议的变更将对必须与他紧密合作（实施，陪伴）的员工的行为产生什么影响？
这样的思考将有助于发现陷阱，并为与其他团体的对话设定总体方向。
设计方案
当需求得到流程中所有参与者的认可和认可后，Rainwater称之为协调建筑和设计决策的时机就到了。 换句话说，技术指南需要描述将执行在规范阶段指定的功能的系统，并考虑负责特定过程的组件。 按以下顺序操作至关重要：
首先是架构，然后是组件。
作者多次强调这一点，因为许多不熟悉产品设计技术的开发人员陷入了这个陷阱。 列出需求列表，为每个需求规定必要的组件，然后将产品视为它们的简单组合，这似乎是合乎逻辑的。 但实际上，这种机械方法会产生僵化，随机组织的怪物，这些怪物会从参与支持项目的开发人员那里吸取所有汁液。 为了避免这种情况，您需要从整体到特定方向采取另一种方式。 您已经具有开发视角的产品通用功能愿景-您需要使用开发视角的通用架构“镜像”产品，即架构。
建筑结构如果我们诉诸于世俗的隐喻，那么体系结构就是产品的骨架，然后就可以在其上构建私人决定执行程序的实体。 我们稍微复活了这个隐喻，并增加了一个澄清：必须使骨骼变尖才能生长新的肢体。 体系结构的两个主要要求是组件的清晰逻辑组织和灵活性，随着项目的发展，灵活性将增加新的组件。
也许在开发的这个阶段可以说是最负责任的-专家们说，正是由于忽视了体系结构问题，才最经常导致项目崩溃。 在常见的故障原因中，它们的名称为：
- 缺乏思想，草率的组织（或完全没有组织）。
- 系统的刚性和直截了当，阻止了其根据商业需求进行扩展。
- 组件之间的互连过多，配置缺乏灵活性。
- 较高级别的复杂性过高，因此很难修改基本组件。
因此，应该认真处理建筑的任务，而不要浪费资源。 请记住，您奠定了直到最后工作的基础-它必须承受将来等待项目的所有更改。 这个过程在很大程度上是富有创造力和远见的，但是标准的结构化方法对于平衡系统很有用。 例如，绘制具有完整连接集的框图，甚至实现简单的布局（带有存根和返回值的一组低级组件），以确保体系结构在垂直投影中工作。 在开始开发真正的，成熟的组件之前，非常需要后者-轻松消除带有“玩具”元素的错误会更加轻松。
在此阶段的工作结束之前，您应该准备回答以下问题：
- 用户将如何与系统交互？
- 需要组装哪些组件才能确保系统正常运行？
- 确保系统功能的组件交互机制是什么？
- 哪些技术最适合创建此应用程序？
- 应该如何将系统交付给客户？
组件规划在开发通用框架时，是时候专门研究并将当前相关的组件植入有机结构中了。 这里的主要困难是承受连接性的必要措施。 一方面，不应将组件视为特定操作集合的严格隔离的容器，而应将其视为一个器官系统，每个器官相互通信，但执行其功能。 同时，应避免区域之间的强烈相互依存，其结果是对一个组件的修改将导致整个系统的整个变化链，甚至是故障。
在最后阶段概述了技术堆栈，现在您必须详细了解它。 在选择语言，选择图书馆时，不仅要由专业人士指导，而且还要严格遵循务实的动机。 说，您是否有足够的称职人员来支持基于先进，稀有或复杂技术构建的系统？ 反之亦然，如果您偏爱较旧的技术，它的前景如何-它们会在整个生命周期中保持运转，兼容性问题会开始出现吗？ 与硬件解决方案，基础架构的创建，配置和维护有关的所有问题都应得到同样的重视。
开发与质量控制
这样，计划最终完成，项目开始工作-应用程序的实际开发开始了。 技术领导者在此过程中的作用主要在于监视，以便一切都按照条款和标准进行； 通常，他仅在不可抗力的情况下直接参与代码创建。 在大多数情况下，负责人执行代码策略的功能，即定期对代码进行严格的审查，以确保它们不与体系结构框架和编程的基本原理相抵触。
在检查期间，技术负责人可能会遇到不同类型的错误。 雨水使读者将注意力集中在两个方面：
- 违反标准 。 这包括样式，命名，评论-通常，所有有助于第三方理解代码中发生的事情的方式，以及一些出口点或讨厌的GoTo运算符的粗心大意。 必须确保开发过程中的所有参与者都使用相同的语言-这使代码透明，并允许您快速解开错误的动作。 参数和变量的名称应清楚地表明其内容，注释应有助于追踪开发人员思想的代码，证明其决策的合理性。 顺便说一句，如果团队中的某人顽固地拒绝评论该代码，则值得考虑为什么。 通常这只是懒惰或思维特质，但在某些情况下，这可能是员工本人并不真正了解自己在做什么的一种征兆-感到困惑或只是出于充分的理由复制了别人的代码。 还必须仔细监视经常忽略错误处理的人员：对开发人员而言，无法识别错误源是一个严重的缺陷。
- 连通性弱和相互依存性强是可以一起考虑的两个干扰领域，因为一个方面的存在暗示了另一个方面的存在。 实际上，这里的一切都取决于分支的程度及其类型。 由于在输出方面具有高度分支，所以该过程的功能涉及访问许多其他过程，这当然是不希望的。 相反，入口处的分支具有积极的作用，因为它表示严格的封装。 如果您在分析这些参数的代码时有疑问，最好绘制带有标记对象层次结构的框图。 它立即显示出您需要了解的所有信息：是否可以追踪对象的血统书，箭头排列中是否存在逻辑，或者一切看起来都混乱不堪。
如果代码警察发现了在这些方面和其他方面的违规行为，则逮捕程序如下所示：将代码连同必要的注释发送回给开发人员，暂停对相应组件的工作，直到修复缺陷为止。 尽管有一些技巧，但非常可取的是，开发人员自己解决这个问题-如果您为他做所有事情，那么代码检查的指导部分就会丢失。
不要将修订推迟到更好的时候。 首先，它很可能会在将来再次出现，并且需要更多的资源来解决整个麻烦。 其次，破窗理论也适用于编程-不整洁，混乱的代码生成更多不整洁，混乱的代码，仅仅是因为它似乎是有效的。
最后，谈到质量控制，人们不得不谈到臭名昭著的人为因素。 雨水建议经理在中间位置。 对代码干扰的某种程度的抵抗是自然而良性的。 完全愿意听从别人的指示并接受别人的意见甚至会提醒您-通常，这意味着开发人员实际上并不在乎他发布的内容。 但另一方面，无法感知到合理的批评会阻碍职业发展和团队合作。 因此，这种技术将必须使皮肤变厚，并且不要害怕坚持自己，而不会对她的心脏产生负面反应。
测试中
在此，领导者必须牢记两个基本规则：应进行测试，并组织其行为是您的责任。 如果公司拥有自然参与流程的测试部门，则不会有任何问题。 否则，您将不得不从自己的储备中分配资源。
根据作者的说法，在第二种情况下，存在某些优点：测试对于开发人员是一项有用的技能。 吸引新移民参加这些任务特别有用，这样他们可以快速获得资格。 首先，您最多可以承担测试任务一半的工作时间。
否则，为了确保良好的检查质量，必须确保该产品不会一直在同一组中进行烹饪-理想情况下，应在侧面进行测试。 如果一个公司有几个开发团队，那么与其他领导者达成共识以创建一个混合团队可能是有意义的。