公司的前端开发:它是什么以及如何使其有效



十多年来,我们在KORUS Consulting CIS上为客户组织了Web服务的开发。我们在银行业已经有几十个严肃的项目,其中一些已经获得国际认可。

在过去的两年中,我们公司的团队和项目数量增加了数倍,而前端开发的有效性也增加了许多倍。我们学习了如何在几周而不是几个月内创建应用程序。

我们一直在努力开发前端开发的基础结构,今天,我将分享一些有关前端部门组织的开发,这可能对那些在公司中组织前端的人很有用。

在本文中,您将了解我们回答以下问题的途径:

  • , ;
  • , ;
  • ;
  • ;
  • ;
  • .


站点或应用程序的前端部分就是您在浏览器中看到的内容,该部分与位于任何服务器上的服务器(后端)部分进行主动交互,并不断与之交换数据。

从技术角度来看,应用程序的前端是一组文件,其中包括HTML,CSS和JavaScript文件,图片等。使用CSS和HTML与排版,JavaScript和编程有关。这两个领域都提供大量的工作工具和技术,正在积极开发并需要大量知识。对于JavaScript来说尤其如此,它已经编写了许多框架和库来“越来越高效”地创建Web应用程序。

不知何故,有人问我现在需要提出什么申请,以便几年后它们不会过时?

作为程序员,我可以给出一个完全准确且完全无用的答案:HTML,CSS和JavaScript。确切选择的是jQuery,Angular还是React-这些都是细节。

如果您深入研究这些细节,则可以给出另一个同样正确且无用的答案:任何事情。是的,这是真的。该应用程序可以用任何东西编写,可以使用,可以更改和开发。

有什么区别?

为了找到答案,让我们从前端看业务需要什么。我认为,如果我说公司希望快速而廉价地获得高质量的结果,我不会感到惊讶。

那么,您现在需要做什么应用程序,这样开发才能快速,有效地进行并且不会破坏客户?

发展速度


具有React丰富经验的程序员将能够在React中快速编写应用程序,具有Angular的经验可以加快Angular的使用速度,等等。一切都很明显。框架本身通过为常见问题和任务提供解决方案来节省开发时间。从本质上讲,这些解决方案可能非常接近,并且它们之间的差异可能在于语法或编程范例。

使用特定框架的开发速度取决于编写该框架的程序员的经验和资格,框架本身是次要的。

产品质量


这里是一样的:您可以在任何框架上编写代码,好与坏。您可以在任何地方放置对与错的体系结构。

这完全取决于开发人员的经验和知识。

成本


所有主要的现代框架都是免费的,因此,如果省略细节,开发成本就是开发人员花费在研究需求,技术,详细架构和编写代码上的时间成本。加上寻找/培训这些开发人员的成本。

因此得出结论:您不需要过多地依赖技术,而只需依赖开发人员及其工作组织。

几乎任何现代流行的框架都足以在其上创建现代企业可能需要的几乎任何应用程序。

因此,在开发组织方面,前端的有效性将进一步提高。

我们怎么样


到2017年,我们几乎所有在JavaScript领域中都值得关注的应用程序都已投入使用:从jQuery到不同版本的Angular和Typescript和Flow上的React。布局和后端/全栈开发人员在我们的应用程序的客户端上工作。每个开发人员都根据对前端技术的了解来选择用于其任务的工具。

现在我只能推测,但是在我看来,全栈/后端开发人员对框架和库的选择是这样的:

“让我们看看他们在Internet上写的是什么。”










好吧,您明白了。

在选择框架/库时,开发人员时间有限,大多数情况下,他没有时间为他自己独立部署新框架并创建测试应用程序。因此,他以某种方式做出了或多或少合理的选择,然后沿所选方向前进。

在不同的时间点,即使对于同一开发人员,此选择也可能有所不同(请参见上图)。同时,他也不会变得缺乏理智。那么对具有不同经验的不同开发人员会有什么期望?

在2017年鲜为人知,我们变成了一个真正的前端技术动物园。

前端作为独立单元


公司中大量不同的技术是一种风险来源。具有必要知识的开发人员可以忙于另一个项目,他可以完全离开公司。聘请在各个领域具有丰富经验的专家也不是一件容易的事。

高质量的文档可以减轻这种多样性带来的负面影响,但是学习和沉浸于陌生的技术通常需要很长时间。

2017年,我们公司出现了一个前端部门,这是对我们项目前端部分质量及其数量不断增长的需求的回应,也是为了稳定技术的多样性并提高开发效率。

这是公司发展的重要阶段:我们现在正在做的事情,如果不专门从事前端,在开发人员的帮助下是不可能的。

动物园怎么治?


不受控制的各种技术使总体上难以预测开发的速度和质量,而商业开发则仅需如此。

因此,我们的下一步是在新部门的专家的帮助下统一公司的堆栈。



统一堆栈是一组严格受限的库和工具,开发人员可以使用它们来解决业务问题。它还包括有关不同编程方法的策略,例如,使用主要是功能性方法,反之亦然,即拒绝该方法。

单个堆栈使开发人员能够快速从一个项目切换到另一个项目,进行跨团队审核,并与同事有效地共享经验和最佳实践。

这里的主要任务不是确定我们在React或Angular上编写的内容,而是确保开发人员使用相同的工具来创建应用程序和相同的方法来解决常见问题。

供参考:我们的主要工具是React,但我们也在开发Angular的专业知识。

这就是乐趣的开始。在编程领域中,强制执行的效果非常差。



因此,您需要确保开发人员本身要遵循某些开发规则,而不是强制执行。

为此,您需要:

  1. 以某种方式修复,形式化开发需求;
  2. 鼓励开发人员遵循这些准则。

使堆栈形式化是一项需要保持平衡的活动。不必为所有内容制定详细的法规,以将基本思想传达给开发人员。另外,创建和维护详细规范会消耗大量资源。

我们解决了激励问题,如下所示:比任何文档更好的方法是给开发人员一个半成品的应用程序(模板)。

这使开发人员可以更快地解决任务,并给他们的同事留下深刻的印象,同时鼓励他们遵守已经在代码中保护的基本规则。

一方面,由于经验的积累,现成的解决方案,更深入的审查以及从一个项目切换到另一个项目的能力,最终类似的应用程序可以显着提高开发速度。另一方面,每个项目都有其自身的特点,因此在此处不要过度标准化也很重要。

您需要放置在应用程序模板中的内容


在开始新项目时,开发人员通常解决以下典型任务:

  • 架构定义,技术/工具选择;
  • 应用程序框架的创建,组装;
  • 创建和配置通用机制:错误处理,模式窗口,通知,路由,服务器请求;
  • 定义一组接口元素;
  • 搜索/创建,定制,使用必要功能的界面组件样式化;
  • 表格处理,验证;
  • 布局;
  • 按客户顺序执行功能(业务逻辑);
  • 代码审查;
  • 记录管理。

您的开发人员可以在几分钟内解决以下哪些任务?

我们开发的应用程序模板关闭了该列表的前三项。在此模板中,我们不仅表达了对单一堆栈进行开发的愿望,而且表达了应用程序体系结构的基本规则。
与公共领域中的流行解决方案(例如create-react-app)相比,我们的模板已经包含:

  • 现成的文件夹结构;
  • 配置的路由器(路由);
  • 配置的Redux存储
  • 服务器请求模块;
  • 现成的机制,用于通过redux显示各种类型的加载程序,通知和模式窗口; 
  • 错误处理模块(服务器和用户),向用户输出消息;
  • 模板页面;

  • 错误,加载程序和通知处理程序连接到的业务逻辑模板模块。

从本质上讲,这是一个生产就绪的应用程序,其中有一个页面告诉您世界。从早上喝咖啡开始,到午餐时间,开发人员可以显示工作项目的首页。

但是随后,其他许多有趣的(并非如此)任务正在等待开发人员。



元件库选择


关于布局,界面组件(下拉列表,日历等),表单和验证的所有内容,我们决定使用自己的库。这是最难的部分。

在2017年,该公司的主要库是付费的Kendo组件库,该库从jQuery开始为各种技术提供UI解决方案。由于各种原因,它不适合我们,因此我们决定考虑使用其他库,包括创建自己的库的选项。

这是非常重要的一点,您需要做出正确的选择:找到另一个对我们更好的库,或者创建您自己的库。开发资源的进一步分配以及团队花费在创建和完成接口元素上的时间取决于此选择。在选择时,我们从以下考虑出发。


:

  • ;
  • ;
  • .

:

  • ( , , );
  • ;
  • , . ;
  • , . .



:

  • ;
  • ;
  • .

:

  • ;
  • , / ( ..);
  • ( , , , ).

实际上,现成的解决方案还不是现成的。几乎每个图书馆都需要准备一个或另一个学位。如果您需要制作一个小项目,那么您可能不会遇到这样的需求,但是如果您正在做某种大型项目,或者是许多小型且不同的项目,那么改进的成本最终可能会高于创建自己的库的成本。完全满足您的需求。

事实证明,您必须在立即安装具有很多限制的现成功能和选择开发自己的解决方案之间进行选择,而这些解决方案需要等待并花更多的资源进行开发。 

没有一个选项完全适合我们,我们找到了另一个解决方案。

我们决定为完成的库添加附件。



让我提醒您,当时我们已经以纯格式使用了Kendo库,这是我们想要找到的替代库。这就是我们决定作为React上应用程序的主要组件库的基础。我们的新图书馆本身就是剑道的立面。我将省略技术细节,我只想说这样的解决方案使我们能够立即获得Kendo的所有功能,并且我们在库的客户端API和Kendo之间的层中做了我们所缺少的,包括错误的快速修复。 

这种架构使我们可以通过将其他库和模块嵌入到我们的层中来快速扩展其组件数量。对于库客户端(对于应用程序开发人员),这似乎是一个库功能的快速增加(我将在另一篇文章中对此进行详细讨论)。

随着时间的流逝,我们用自己的实现替换了所有组件,并发布了库的第二版,其中考虑了所有以前的经验,修改了API并编写了自己的文档。 

我们决定将我们的成就放到公共领域,尽快按照公告发布并在我们的项目中使用它们。

我们到底得到了什么?


现在,我们有多个团队的十多个前端开发人员,他们在同一堆栈上使用一套技术。在一个堆栈中,我们已经创建了大约二十个项目。

统计数据表明,两年来工作效率提高了两倍多。我们过去花了4到6个月的项目,现在我们需要1-2个月的时间(我们在谈论前端部分)。

我们开始通过更改程序员任务的结构来减少开发时间。让我们看看它们是如何变化的。

我已经列出了两年前开发人员解决的任务:

  • 架构定义,技术/工具选择;
  • 应用程序框架的创建,组装;
  • 创建和配置通用机制:错误处理,模式窗口,通知,路由,服务器请求;
  • 定义一组接口元素;
  • 搜索/创建,定制,使用必要功能的界面组件样式化;
  • 表格处理,验证;
  • 布局;
  • 按客户顺序执行功能(业务逻辑);
  • 代码审查;
  • 记录管理。

其中,在我们今天的公司中,开发人员仅参与最后三个:

  • 按客户顺序执行功能(业务逻辑);
  • 代码审查;
  • 维护项目文档。

其余的已在应用程序模板和组件库中确定。

这不仅影响了工作速度,而且总体上影响了开发人员的心情。无论如何,业务逻辑的实现比设置下拉列表更有趣。对于项目经理来说,向客户解释要花费一个星期的工作时间来开发重要的业务功能也很容易,而不是因为它需要完成一个小的界面元素这一事实,尽管这在人工成本方面可能相当。

我们将继续朝着选定的方向努力,并且在不久的将来的主要任务之一是增强开发人员加深他们在选定堆栈中的能力并寻找新的有效解决方案的动力。有了通用的库和应用程序模板,现在可以轻松地在整个公司范围内扩展此类解决方案。

希望能有效率,很快见到你!

Source: https://habr.com/ru/post/undefined/


All Articles