如何与大学生一起实施发展过程

在我作为软件开发人员的第一份工作中，我的团队使用敏捷/混乱来管理我们的项目工作流程，并且效果很好。我有一些经验丰富的导师，他们使我走上了正确的道路-我欠他们很多谢意。我在那里工作了几年，然后在几个月前搬到了一个新的机会。

快进我目前的工作。我在大学的教授指导下工作。自从我上大学以来，几乎每个程序员都是学生（他们很便宜而且很多！）我的老板有管理经验，但是没有软件开发经验，并且软件团队并不总是站在我老板的头脑中。这些条件已经创造了完美的环境，创造了一些非常差质量的软件。软件项目似乎有些无赖，没有设计思想，并且采用了一些真正令人恐惧的做法。我知道情况会更好。

我想实现一个开发过程，以帮助每个人步入正轨，提高代码质量，并部署更稳定的软件。我只是不确定从哪里开始。

可以说，我不是在寻找诸如“使用Scrum”，“设置看板”或“看看敏捷！”之类的答案！（尽管对此表示赞赏）。更具体地说，我希望深入了解如何为该工作环境实施开发过程。员工通常在上班之前工作1至2年，通常没有经验，几乎不可能安排包括每个人在内的日常站立会议。

在这样的工作场所如何提高质量，效率和沟通能力？

更新：阅读了一些答案和评论后，我想我还会提供一些其他背景知识。

我不认为自己在艺术软件开发的高手，但我很足够的经验来识别不好的编程当我看到它。在花一两分钟与他们合作之后，我可以确定开发人员是否才华横溢。我很舒服，我自己的能力，以找到一种方法来解决问题巧妙，然而，在我实在缺乏经验的面积是项目管理，而其他开发人员参与（这就是为什么我在这里问你的精彩人民的建议）。

我听起来像是进入这个办公室的每个学生都是一个完全昏昏欲睡的人。这里有些坏蛋，但是我遇到的大多数学生都是聪明的，想学习的，并对工作充满热情。有些人才刚刚起步，他们不知道自己不知道什么。没关系。刚开始编程时，我的生活就再好不过了！

清除错误所需的时间比预先检查所需的时间更长。如果您要与（可能）不熟练或不了解良好实践的开发人员打交道，这意味着在经验丰富的人员查看他们的代码之前，他们应该不能更改（主）代码库。

您不想对方法进行解释，所以让我略过这一部分：使用敏捷任务来设置可以独立开发的不同功能。

开始使用功能分支，以便每个人都在单独的分支上工作。任务完成后，开发人员将无法将其代码合并到master分支。如果您使用的是Git，他们仍然可以启动拉取请求。否则，请使用任何您喜欢的跟踪完成任务（/分支）的方法。

然后我们进入审查过程。您所疑问的是，是否还有一些经验丰富的开发人员的判断力比学生的信任度更高。因此，让我详细说明两种方式：

如果有经验的开发人员，请给他们任务以检查完成的任务的代码。如果很好，他们可以将其合并到master分支中。如果不是这样，他们可以自己重构它，也可以将需要改进的内容反馈给开发人员。

如果没有经验丰富的开发人员，那么您总是会遇到问题。如果没有人能从不良代码中发现优质代码，那么就不可能保持代码质量。
您所能做的最好的事情就是召开评审会议，让开发人员在其他开发人员面前介绍并解释其实现。尽管这不能保证防止所有问题（例如，如果所有开发人员都对良好实践有相同的误解，但仍将防止大多数问题发生（例如，如果至少一名开发人员具有正确的想法并可以表达出来）；或者问题出在什么时候来自开发人员对问题的理解彼此不同）

在这样的工作场所如何提高质量，效率和沟通能力？

• 质量 -由经验丰富的开发人员检查代码。在没有经验丰富的开发人员的情况下，请进行小组审查，以至少充分覆盖您的基础。
• 效率 -如果正确设置独立任务，则可以最大程度地减少彼此等待的人。在并非所有人都同时可用的环境中，我假设您正在处理很多“等待A人”的延迟。跟进那些没有取得进展的开发人员，仅检查他们是否需要帮助，甚至只是让他们发泄挫败感（这些挫败感可能会显示出对可避免问题的误解）。
• 沟通 -设置开放政策，以便开发人员可以向某人寻求帮助，反馈或启发。在没有合格的指导者的情况下，请尝试促进团队互动（即使您有可用的指导者，您当然仍然可以这样做，但是在没有指导者的情况下这样做的重要性会增加）。尤其是在人们以不同的时间表进行远程工作的情况下，开发人员通常与他们的同事关系并不密切，并且往往彼此之间不交流。即使是少数社交聚会，在其他时间也可以改善与工作相关的交流。

对于这样的新人来说，可能会离开的环境，最大的事情就是强制性代码审查。

它们有助于传播应采取的措施的知识。它们有助于防止最差的代码进入代码库。它们促进实施的一致性。

因为营业额和经验不足，沟通比平时更重要。

除了解决方案以外，它的想法更多，但是找到了代码库的一个关键部分，其中包含与学生开发人员可能要做的项目相似的功能和元素，并且非常好地进行了清理。新开发人员的一个大问题是他们不了解代码库的规范和约定，因此他们将查看其他代码以了解如何设置自己的代码。在混乱的代码库中有许多新手开发人员，这意味着他们将看到混乱，并认为这是可接受的或做事的最佳方法。然后，即使在高周转环境中，不良做法也会长期存在。

通过至少有一个原始的，编写得很好的代码部分（甚至只有一个文件），您可以告诉您的学生开发人员将其用作最佳实践的示例。告诉他们，如果他们可以编写类似的代码，您会感到很兴奋，而其他许多代码可能不是正确的处理方式的好例子。

添加注释或其他文档以解释为什么以某种特定方式完成操作，这也将有助于新开发人员通过更好的代码实践来更快地加快速度。

持续整合 -

这是一个实用和概念性的框架，可用于逐步，灵活地实施团队工具，技能和流程。

CI是从编写代码到部署的工作流程的概念。这些任务在概念上实际上是独立的。

CI特别是自动化。从在屏幕上键入代码开始，这对质量和生产率具有深远的影响。

• CI任务的实现可以独立，详细和同时解决。重点可以根据需要转移。
• 不要引入“汤到坚果” CI工具
  • 你们都会被过程分散注意力，并倾向于粉刷封装的任务技能。
• 物超所值

• 期望成为全职变革代理。成为领导者；不只是经理，也不只是高级编码员。

• 具有战略性

  • CI的“圣杯”是一种可交付使用的工具，可用于部署自动化。如果他们不能触摸它，他们将无法进行FUBAR。
  • 培训和培训材料。
    • 记录流程。
    • 创建一个程序员手册，让它有机地发展。
    • 必选
    • 探索概述了针对特定技能和代码库本身。
  • 灌输专业的程序员价值观，例如：
    • TDD绝对创造品质
    • 代码审查包括所有工件：注释，注释掉的代码，单元测试等。
    • “对于发现了多少个错误我感到很尴尬”
    • 个人代码所有权感和对“冒犯”所有者的恐惧并没有抑制客观性。

• 战术上

  • 离散CI任务本身可以自动执行，例如，版本控制提交触发编译和单元测试。
  • 自动化实施的规则，例如代码格式。
    • 当心过多的学问细节。该工具将开始被忽略。调节规则执行，以免造成压力。
  • 立即实施测试驱动开发
  • 优先处理并强调每个更改
    • 不要以为关键的知识和技能飞速发展。
  • 不要急于破坏正确的实施
  • 领导变革并遵循
    • 新手入职培训和一些基本培训是必要的。
    • 明确的培训和对新事物的明确指导
    • 至少要培训一些最低的概念性标准。不一定要是正式的，但随机浏览YouTube并不是培训。亲自验证-再次避开手续。
  • 成为代码审阅者，审阅所有代码。
    • 明确指导具有挑战性的错误修复并分享重要的学习经验。
  • 刚性好。对不起，不得不说。但这是真的。
• 创造文化
  • 有专业的期望
  • 标准化工具
  • 强调学习生产指标
  • 成为导师
  • 在引入变更时，仅依靠个人的“做到这一点”的主动性就会微妙地破坏团队的发展。一个有凝聚力的团队的身份包括其共同点：工具，知识和技能水平。相互尊重的程度会扩大到每个成员都将其视为有价值的价值观。团队负责人是榜样，这是不可避免的；不要模仿“任何”态度和期望。

品质之路

• 单元测试

  • 测试驱动开发的关键
    • 无需阅读整本书
    • 这应成为该编码范例
    • 作为领导者，您必须坚持下去，直到每个人都完成“信仰的单元测试飞跃”。范式从“我正在编写两次代码！”转变。拥抱超赞的生产力。
  • 在我们的商店中，必须进行单元测试。但是许多人没有这样做，因为他们不想这样做。管理层缺乏信念，发出了这样的信息，即单元测试实际上并没有起作用。
    • 因此，在代码审查期间经常会忽略单元测试，从而使错误，无效和错误的测试进入代码库。缺乏技巧的单元测试将破坏整个工作。

• 版本控制

  • 我将其放在第一位，但是单元测试更容易上手
  • 不要延迟其他计划，因为版本控制不是那么容易
  • 制定版本控制计划。
    • 您必须写下来。
    • 即使它只是“将所有内容都扔进主干而不分支”那样简单，也可以这样做。

• 代码评论

  • 这具有极大地改善详细代码质量的潜力。
  • 使用2审核过程。
    • 我对第二次审核发现了多少错误感到非常惊讶。
    • 信任但要验证。运行代码。你为什么还要说这个？参见上面。
    • 最初，您将是唯一的审阅者。让团队监视您查看“实时”。他们将永远不会学会如何思考。
    • 很快，您将只是第二位审稿人。作为个人技能的保证，让他们复习；最终都是两位审稿人。您当然会一直在看代码，无一例外。

• 重构

  • 这是一个独特的正规学科。
  • 重构： Martin Fowler 改进了现有代码的设计
    • 编码重构配方，可确保引起无错误的代码更改。
    • 从这本书开始一个专业图书馆。
  • 除了形式，通过代码审查专门介绍它

• 捕捉环境

  • 基准工具配置：版本控制，IDE，CI工具，操作系统等。
  • 源代码，文档，配置应在版本控制中同步。

关于流程的话

敏捷（及其子流派，例如Scrum）：算了。“你很敏捷，你不敏捷。” 请参阅《敏捷宣言》的原始签署人之一戴夫·托马斯（Dave Thomas）的著作。

• 敏捷的腐败 -Dobbs Journal博士专访
• 敏捷已死（敏捷万岁）
• 敏捷已死 -会议主题演讲。

对于没有经验的小型团队，当我看到诸如Visual Studio Team Services之类的团队集成工具时，我的幻想就会消失。我的经验在这里有限，但我感到刻板，多余，刻板的过程强加于人。我知道许多人会使用这些东西产生很大的效果，但是要当心潜在地购买解决方案来寻找问题。

关于工具的一句话

只有我。不是来自那些“现在最好的软件工具...”点击诱饵蜂蜜罐。

詹金斯

CI集成工具。基于Web的，被广泛使用。本质上，通过Web GUI，您可以自定义配置和自动化各种任务和执行顺序，例如编译，运行单元测试，更新版本控制。这是A-La Carte菜单，非常适合您新生的CI环境。

版本控制

与Git相比，我更喜欢Mercurial。这篇博客是我最初选择Mercurial的原因：Git是MacGyver，Mercurial是James Bond

颠覆是好的。Mercurial＆Git具有不同于Subversion的体系结构。

集成开发环境

如果每个人都使用不同的编码工具，那么这是一个很大的考虑因素：没有纯文本这样的东西

关于专业图书馆的一句话

互联网是广阔的，浅薄的和杂乱无章的。

• 史蒂夫·麦康奈尔完成的 代码
  • 让每个人都读中间三分之一。
  • 有建议的专业书籍的附录。
• 重构：改进现有代码的设计
  • 编码重构配方，可确保引起无错误的代码更改。
• 软件故障。没有具体的建议，但应该是关于专着的故事。

我建议使用另一种方法来管理您的流程，因为正如您所说，安排会议是不可能的（这对Scrum来说绝对重要！）。提出一个好的概念仍然没有什么坏处，因此每个人都知道发生了什么事情（可能也使用vert原型）并使用了瀑布模型。无论哪种方式，沟通都是工作的最大部分。

如果您还没有的话，我鼓励您使用源代码管理。这使您可以查看每个开发人员签入的内容，并可以回归引入错误的位置。

我会设置某种测试套件。它可以是测试驱动开发，您可以为要提交的每个功能编写测试，也可以是一种自动方式来运行您的应用程序，并使它们将结果输出到可以与所需结果进行比较的文件中输出。如果此操作在每次提交后运行，或者每晚至少运行一次，则您会很快发现回归。

我要做的最后一件事是实施2个策略：1）所有构建都必须将警告设置为错误，并且打开所有错误2）所有代码都必须通过静态分析器，并且在提交之前不会产生任何错误或警告。我什至将其设为预先提交的操作。这两种方法可以防止代码以多种常见方式迅速变得恐怖。（他们不能抓住一切，但可以抓住很多东西。）

这也将使您的学生为“现实世界”中的工作做好准备，并在其中灌输一些合理的良好习惯。