Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

我理解的阿里无线前端“架构”(半鸡汤,少干货) #3

Open
hongru opened this issue Jul 27, 2015 · 46 comments
Open

Comments

@hongru
Copy link
Contributor

hongru commented Jul 27, 2015

写在前面的话:

对于文中涉及“脱敏”的内容,链接经常一环套一环,无法输出,很抱歉...
怀着一个酝酿了蛮长时间的念头,打开电脑,想对一些思考做一点记录。关于标题,关于“前端”,关于“架构” 。
其实是有蛮多话想说的,但是前面这几个字却打上去了又删掉。想为下面的内容找一个合适的开始。但是似乎总是不那么如意。
回到这个话题,或许应该从以前的认知慢慢说起。

过往的认知

不可否认的说,曾经很长的一段时间,当我大部分时间还集中在业务上的时候,对“架构”这个词有点嗤之以鼻。尤其是“前端架构”。觉得说“前端”这个软件工程化都相对薄弱,还在拼死拼活的往成熟的语言领域,往已有的软件工程慢慢靠近的的方向,真的需要所谓的“架构”么。
dbf_contempt500
总觉得在这个阶段,

  • 所谓的前端架构更多的是在纸上谈兵,拿以往的软件工程的思想和概念硬往自己身上套。
  • 所谓的做架构的同学更多的是在炫耀自己的技术深度和视野,看到前沿的技术不管合不合适就拿来做方案,硬往业务上推,来成全自己的KPI
  • 总觉的所谓的“技术架构”无非就是一些个人主观化的思路和概念,形成一些看起来成体系的代码组织方式,以便完成业务后可以说:看,基于我的架构有多好的通用性,扩展性,代码看起来多优雅...

回到我现在的立场,我看到的当前团队中不同的同学对于“架构”这个词的认识和看法,无非有两种:

  • 要么和之前的我一样,嗤之以鼻,做架构的有什么了不起,无非是老板给你安排个“轻松点的活”,做做方案,不用受业务的压迫。还得逼着一线每天认真辛苦的码代码的同学接受你一时想出来的Idea。
  • 要么是另一个极端,觉得做架构的同学就NB,觉得比做业务的同学从概念上就高一个等级。然后死命的想要往“架构”这个方向靠。

可是当有一天我自己需要站在团队的角度去思考基础建设的缺失,思考怎么才能帮助到团队的时候。才发现“架构”这个词既没有想象中那么“不堪”,当然也没有想象中那么“容易”。同时,也没有别人眼里那么NB,高人一等。
反而是越来越多的谦卑甚至恐慌,当沉下心来想想,确实,我们可能误会“架构”本身了。我们自己往他身上加了很多的主管臆想。

我理解的架构:是团队的,不是架构师的

第一条我就想说这个,因为TA的确应该是大前提,如果做架构的同学不是站在团队的角度来思考问题,思考解决方案,而是以自己过往的经验,自我的判断说应该怎么怎么样。那必然是会沦落到被人嗤之以鼻,甚至拖业务和效率的后腿。

  • 架构一定不应该成为只是你想要的样子,也不能只是老板想要的样子,一定应该是团队想要的样子。

在我正式接下为团队基础建设方向做规划和思考这件事情之前。去年在团队内做了一段时间的“SWAT”,也就是真正意义的上的“灵活资源”,做团队任意方向的支持。在做“团队支持”这个期间,参与了不同形态的业务项目,产品化的,运营化的,长线的,短线的,消费者端的,商家端的,前台重视内容和体验的,后台重视效率和结构化的,等等一系列不同的项目,包括一些不直接透明到业务的专项。当前参与程度深浅不一,但总体这个过程让我感受到了一件事情:

  • 不能凭想象和自我经验判断说团队需要什么?你要的答案一定要去和团队对话,和团队成员对话,或者参与到不同形态的“他们”当中去,去发掘他们想要什么。

收集信息和问题是做决策和方案的第一步,这个观点说出来大家都知道,但是实际做的过程中可能不一定能想得到了。举个例子:

  • 你要做工具,做给新人的,就要站在新人的角度来使用它,发现它是不是真的有用。做给流程规范的就必须站在项目实践的角度去实践TA,而且不是你自己觉得好用就乐呵呵,因为你自己并不是“架构”这个方向的真正用户
  • 更典型的例子,前端的自动化测试。做之前第一件事情是弄清楚在当前时间节点下,当前团队状况下,团队是否需要TA。进而才是怎么在团队的层面上去落地这件事情。而不是自己想当然的做一套方案。当前的团队并不需要这个东西,那么方案再完善又有什么用?

“架构是属于团队的”,这个观点一个方面是上面所说的,TA的需求和解决方案应该来源于当前团队。另一个方面是架构的进展和设计一定也是对团队透明和公开的。
如果进展和方案不能随时保持对于团队的公开和透明,也很难保证当到了最终产出的时候,还能保持最开始的方向一致性。

今年上半年开始,我们的周会内容有了小小的变动,把以往的单纯的团队内分享的例会转变为一个始终围绕团队基础建设,团队发展,和个人发展的交流会。植入了一个每周固定的环节,就是“基础建设进展和问题一周汇总”。
保持公开和透明,也可以随时就问题进行讨论。给自己和团队一个面对面的机会。
确保是大家想要的,同时也希望能潜移默化的形成大家对于团队建设的方向感和全局观。

我理解的架构:是横向全局的

这应该是做“架构”最基础的要求。也就是需要对整个团队,结合整个行业的发展保持全局的观望和了解。并且可以在此基础上基于团队现状做出对未来的基本判断。
“做出判断”这件事情,说简单也简单,说难也难。简单的是无非就是做几个选择题,选出今年,或者近期内要做的事情。难得是怎么来保证你的选择在当前的团队来看,是正确的。什么阶段做什么事情。

我记得今年上半年开始,我开始尝试担起前端团队的基础建设收敛相关的事情的时候。结合去年和今年的现状,整理过一个简单的框架图。在 "手淘前端在工程化道路上的“匍匐”" 文章里面有Po过。后来有过一些更新和小调整。大致如下:
_
归结起来是

  • 两个中心 (端和效率)
  • 八个方向
    • 基础库+功能组件+UI框架 (对应“效率”)
    • “端”的延伸 (对应“端”)
    • 规范和工程流程
    • 工具链路
    • 数据和性能
    • 自动化测试+持续集成
    • 前端安全
    • 服务和周边

八个方向中,落实到两个中心的必然是今年的重点。工具和性能是去年的重点,今年在已有基础上升级。其他的子方向在今年会开始探索。
这其中由于团队历史和现状的原因,其实有一些点是大家都在火热在抓的,但在我们团队中并没有放到今年的重点。比如

  • 前后端分离

也有在当前团队现状还不到时候做的(并不紧迫)的事情,比如

  • 前端基础服务(包括构建和工程的服务化,新人系统,内部项目域名和服务资源申请和部署自动化.. 等等)

以上的信息可以理解为“架构是横向全局” 这个观点的一个表现。
个人觉得做出判断的前提确实是需要了解别的优秀的团队在做什么,行业在做什么。再结合团队的现状才有可能知道我们需要做什么。
然而,了解别人的过程,其实反而也是让人“谦卑”的过程。

有时候知道的越多,会让人觉得越渺小。

你觉得自己在某方面做的还不错了,但是一定有人有团队有更优秀的方案和实践。

所以,“全局”,不仅是对于自己团队现状的全局认知和判断,也是在其他团队放到一起的“全局”评估。

  • 全局意味着 - 清楚的知道团队在当前阶段应该做什么事情
  • 全局意味着 - 清楚的知道团队的现状,优势和问题
    • 不至于高傲的迷失了方向
    • 也不至于卑微的找不到出路

我理解的架构:也是垂直深入的

在我的理解里,所谓“做架构”的同学们,不应该只是单纯的有“全局观”。同时也需要对每个垂直的领域保持一定的“绝对深度”。

就拿上面关于“全局”的几个子方向来说,我希望在当前定下的细分领域,想要做“架构”的同学在任何一个细分领域上都能保持一定的绝对深度。可能对于一个人的精力和资源会有一些挑战,但是我觉得在一定程度上是应该的。

在精力允许的范围内,每一个子领域里应该都需要尽可能的参与方案的探讨,制定,代码的实现,团队的落地整个过程。

拿我们自己团队的情况来说,至少应该知道:

  • 基础库和组件库,UI框架
    • 未来形态的发展应该是什么样?
    • CommonJS模块范式的迁移的自动化实现方案是什么?代码实现思路是什么?
    • 模块依赖关系弱关系到强关系的包装需要做哪些事情?
    • 控件的规范是否需要迁移到WebComponents?
    • 如果迁移,规范是什么,怎么定最小Feature的polyfill集合?
    • polyfill代码应该怎么来实现?
    • UI部分的组件复用应该怎么来做?可视化还是命令化?
    • UI库的mixin部分的style-lib和组件层面的view-lib怎么更好的管理?
    • ...
  • 端的部分
    • ReactNative的现状和痛点是什么?解决方案是什么?代码实现的难点在哪里?
    • RN的组件库怎么来组织构建?一个RN的组件应该怎么来写?
    • RN在性能和稳定性上的解法有哪些?现状是什么?
    • 业务层面的数据上报方案是什么?代码上的思路该怎么做?
    • 是否能明晰的判断未来,知道什么时候该坚持?什么时候该寻找别的出路?
    • GDOS的目标和意义是什么?为什么要做GDOS?
    • 对接通用算法和选品的难点是什么?怎么样定商品化的json schema?
    • 甚至java的部分,hsf的对接是否也能够参与?
    • ...

以上举例,提出每个子方向细化的问题,在心里对重要的细节有认知,有答案,也是我认为做“架构”的同学所必须要明白的事情。

同理,
工具层面,规范层面,工程流程,性能,单元测试,前端安全等等,期望尽可能深的参与到具体的实践和落地上去。(包括代码的具体实现...)
tool1 tool2 vue img2 img3

做架构不是只有idea,然后全部推动别人去做,更重要的是自己需要深度的参与,才能保持清醒的认知。

这是我个人的认知,不一定对,当然

  • “在保持广度的情况下还要保持一定的深度”

也会对于个人的时间精力有一定的挑战。

反过来说,如果“架构”已经大到需要5个人以上的团队才能支撑,那时再做合理的分工也不迟。

我理解的架构:是海纳百川,是透明开放的

在之前的表述中,提到“架构”至少是需要对团队透明的,来源于团队,尊重团队,也服务于团队。而这里说的海纳百川,开放透明更是侧指我们以公司单位,那么理应在公司内也是透明和开放的。

  • 对外不用多说,公司自有公司的壁垒,但至少对内,我们应该共享一片蓝天。

shot_1296383136
当你不关注,不闻不问的时候,或许还不觉得,但是当有心想去了解一些事情的时候,却发现似乎并没有想象中那么透明。

我在 上周的周报:不聊技术,聊感受 中其实提到了一些关于“技术栈”和“技术栈”之前的壁垒问题,也包含“前端”本身团队壁垒的问题。

我的观点是:

  • 团队技术壁垒不是问题,毕竟每个团队的业务形态,抓的方向并不一致。但是不透明是问题,想发掘其他团队的好东西却要费点功夫。

其实回过头来想想,集团内其实有不少的方式似乎想解决这个问题,比如淘宝的“懒懒”,支付宝的“芝士会” 等等,从定期主题分享的方式尝试抹平BU间不透明的问题。也有属于集团层面的技术博 ATA, 包括前端也有自己的 委员会,本质上也是希望打通BU间的信息。

我们看起来有这些途径,理应可以解决不少壁垒不透明的问题才对,可是到我真实的感受却是还有好多有价值的信息,方案,项目等,我从上面的渠道获取不到的。

可能是“粒度”的问题,可能是“传达”的问题。咋们暂时先不去细究。说实话,我个人觉得比较直接打破我觉得有壁垒的苦恼的事情是 @拔赤 公开的周报。

我近期了解到很多航旅有价值的信息,他们近期着重发力的方向,不可置否的说,基本都是从 @拔赤 每周的周报中觅得的。当然,这和他向来高质量的周报内容有直接关系。

所以,我做的第一件事也是把无线前端从今年上半年开始的每周基础建设,架构的方向和进展以周报的形式公开来。一方面从我们自己开始做到“透明化”,同时也愿意以谦卑的心态和大家进行讨论和交流。

阿里内外的周报系统我觉得是个好的开始。既然有选择“公开”的选项,我觉得也应该加上“周报关注”的功能,只要我关注的人某一周的周报内容是“公开”的,不管他的周报有没有直接抄送我,我都可以收到。

话题有点扯远了,我要表达的意思是,我期望寻得一种途径,可以让我短平快,高效的知道优秀的大家们都在做什么事情。

最近在团队内开始推动一个叫做 “取经之路” 的计划,其实也就是希望团队的同学都能保持有心思去发掘其他团队的优秀的东西,以取经的形式主动去了解,再带回来传道授业解惑。
希望团队本身能从中开拓视野和思路,同时对于做“唐僧”的同学来说,本身也是一种成长。

我理解的架构:关键词不是“高精尖”,而是“合适”

最近越发的觉得“合适”这个词的精妙与深意。站在外人的角度,去评判一件事情的好坏,一个技术方案的优劣,不应该从你的角度去看,连行业的普适标准甚至都不一定受用。因为可能在你看来有失偏颇的方案在他的团队的当下就是“合适”的。

换句话说:

  • 在我看来,技术方案优和劣或许没有绝对之分,只是因为团队的历史原因,团队现状,发展出了不同的样子。只要它对于当前的团队是合适的,我就认为它是好的。

说到这里,我不免又想到了“恋爱”这件事。如果这么说来的话,不觉得和“恋爱”的情况略像么。通俗点说:

  • 爱美之心,人皆有之;漂亮的女孩子,谁都喜欢,你费劲心思去追一个大家公认的女神,这件事情能不能成,最终是变成“金童玉女”的千古流传段子还是变成“癞蛤蟆想吃天鹅肉”的恶俗剧情,前提是要认清自己。当前的自己如果如果就是配不上女神,那何必自讨苦吃,还不如努力锤炼自己,到有一天走上人生巅峰再去赢取白富美也不迟不是么 ;)

比方不一定恰当,但是道理是通的。我想说的是,技术的方案和设计是不是好的,对的,不是看你用的技术,选的方案是不是够高精尖,够前沿。而是看TA是不是适合你当前的团队现状。

举个例子:

  • ES6 当下被好多团队在实践,吵得火热。可以理解为ES6的产品化,包括周边polyfill的完善,以及一整套方案的打通,在当下看起来是靠前沿的,面向未来的,高精尖的。 如果我们的团队就那么几个人,如果团队负责的业务就那么两三个,形态也相对单一,那么我觉得快速的拥抱ES6,尝鲜,玩新技术没有任何问题。而反过来,如果当前团队的体量,现状,团队组成不允许一个步子迈这么大,那么这件事如果硬按“拔苗助长”的方式推进,有可能会产生很大的副作用,开发效率,质量保障可能都会收到影响。

所以,架构和方向不应该朝着“高精尖”的方向走,那不应该是目标,“合适”的,才是最好的。

在适当的时候,用适当的方案去做对应适当的事情,
就好比,
在适当的时候,遇上对的人。

@hongru hongru changed the title 我理解的阿里无线前端“架构”(半鸡汤) 我理解的阿里无线前端“架构”(半鸡汤,少干货) Jul 27, 2015
@skimki
Copy link

skimki commented Jul 28, 2015

说得好!

@paddingme
Copy link

paddingme commented Jul 28, 2015

赞!

@JeasonSun
Copy link

JeasonSun commented Jul 28, 2015

@springuper
Copy link

springuper commented Jul 28, 2015

全局意识,抓精抓细,接地气,是“架构”团队最应该注意的三点。

@ksky521
Copy link

ksky521 commented Jul 28, 2015

点赞~我一直都在强调:不在于什么新技术,适合团队的才是好的架构

@q545244819
Copy link

q545244819 commented Jul 28, 2015

赞!

所以,架构和方向不应该朝着“高精尖”的方向走,那不应该是目标,“合适”的,才是最好的。

很赞同上面那句话。

@dabanlee
Copy link

dabanlee commented Jul 28, 2015

@sunbf1987
Copy link

sunbf1987 commented Jul 28, 2015

“在适当的时候,遇上对的人。”我喜欢这句话

@Horve
Copy link

Horve commented Jul 28, 2015

赞一个

@fkysly
Copy link

fkysly commented Jul 28, 2015

赞赞赞!

@yunguo
Copy link

yunguo commented Jul 28, 2015

这才是踏踏实实做事的人说得话

@nunnly
Copy link

nunnly commented Jul 29, 2015

po🐷的心里话

@itbeihe
Copy link

itbeihe commented Jul 29, 2015

很赞,在适当的时候,用适当的方案去做对应适当的事情。
最近换了公司,从一个小的全端团队,再次回到前后端分离的前端团队中。
真是不同的团队推不同的事情。

@hero76
Copy link

hero76 commented Jul 30, 2015

架构的本来目的就是为了解决当下存在以及未来可能出现的各种问题,如何做到架构需求的实时回归(从一线反馈的需求)这个是个问题

@StuPig
Copy link

StuPig commented Jul 30, 2015

  • 全局意味着 - 清楚的知道团队在当前阶段应该做什么事情
  • 全局意味着 - 清楚的知道团队的现状,优势和问题
    • 不至于高傲的迷失了方向
    • 也不至于卑微的找不到出路

@wssgcg1213
Copy link

wssgcg1213 commented Jul 31, 2015


沉下心来

@amio
Copy link

amio commented Jul 31, 2015

很赞

补充一点个人理解。
架构组还有一个相对隐性的职责,是面向未来。业务关注的是未来三个月的表现,架构至少要看到未来一年的可能,看到进化的方向,制定计划推动进步。现在火热的 ES6 实践应该大都是基于这个动机,至于是否恰当,还要看团队和业务现状以及信心。

在未来技术上的投入可以看成是微型的风险投资,收益和失败几率成正比,选择一部分余力来做还是倾囊而出,有时候还真分不出孰优孰劣,但是看到身边有大胆的人勇猛地冲怎么说都是件值得高兴的事情。前端这些年的迅猛进化,离不开这些冲动的高手们。

@amio
Copy link

amio commented Jul 31, 2015

BTW,
有时候架构工作可能会碰到个问题:如何证明这些架构工作的意义,它给公司带来多少好处,多大价值?发问可能来自于兄弟部门,也可能来自上级老板。

业务部门的指标都很明确简单,对于架构而言性能提升和基础库搭建的作用比较明显,其他工作内容的价值就不容易衡量了。在某些糟糕的情况下,甚至衡量的重要性要超过内容本身,这也算是团队的生存现状,也是架构组需要考虑的内容。

这个问题放在前面的论述里来说,属于横向全局的考虑,也有点类似开放透明所要解决的问题。

@hongru
Copy link
Contributor Author

hongru commented Jul 31, 2015

@amio 我其实蛮钦佩勇敢往前迈进的决策者和团队的

@FrankFan
Copy link

FrankFan commented Aug 28, 2015

说的不错,赞一个

@tomieric
Copy link

tomieric commented Aug 29, 2015

我们小团队前后端分离好痛苦,环境构建确实带来酸爽,架构方面只能慢慢摸索,需借鉴你们的经验:)

@slogeor
Copy link

slogeor commented Aug 30, 2015

赞!喜欢这句话:在适当的时候,遇上对的人

@lixuejiang
Copy link

lixuejiang commented Aug 31, 2015

@Raincal
Copy link

Raincal commented Aug 31, 2015

赞~

@Bob-LongXiaoKun
Copy link

Bob-LongXiaoKun commented Sep 10, 2015

能看出来 是用心在写文章 很有意识 有机会请你喝酒哈

@CircleSmall
Copy link

CircleSmall commented Sep 23, 2015

写的真好!

@eijil
Copy link

eijil commented Nov 17, 2015

个人理解架构解决主要问题就是规范 效率 质量

@willian12345
Copy link

willian12345 commented Nov 18, 2015

不求高精尖,但求合适
说的好!

@yipengmu
Copy link

yipengmu commented Nov 19, 2015

合适:合得来 ,适配的又好。。。 赞

@riskers
Copy link

riskers commented Nov 19, 2015

终究还是造了个轮子。。。

@blue68
Copy link

blue68 commented Nov 19, 2015

在适当的时候,选择适当的架构,随着业务的扩展不断进化。

@yang66
Copy link

yang66 commented Nov 25, 2015

不是前端,以后慢慢看

@FangB
Copy link

FangB commented Dec 14, 2015

看到前言就赞,同感的前端人

@banditsmile
Copy link

banditsmile commented Dec 24, 2015

里面几个链接都挂了,能修复一下么?

@mingelz
Copy link

mingelz commented Dec 25, 2015

@banditsmile 文章中的几个链接是指向公司内部网络的链接,所以使用「脱敏」指代,无法打开。

@dancon
Copy link

dancon commented Dec 25, 2015

‘架构和方向不应该朝着“高精尖”的方向走,那不应该是目标,“合适”的,才是最好的’

其实这句话说的不够准确,“合适”确实是比较精深的词,我们也应该明白“高精尖” 和 “合适” 是不矛盾的,其实,在技术选型期间,我更优先考虑这些高精尖的东西是不是符合目前的场景,当然这也是一个权衡利弊的过程,毕竟新的东西有TA的优势,也有TA的弊端,如果要弥补弊端的代价大于优势带来的好处,那就可以定位这个“高精尖”不符合目前的需求,也就是所谓的不“合适”!

@loganjing
Copy link

loganjing commented Jan 10, 2016

赞一个,合适才是最好的,而不是使用什么高深的技术。

@strengthsong
Copy link

strengthsong commented Feb 2, 2016

用心在写文章,赞

@dksai414
Copy link

dksai414 commented Apr 12, 2016

good!
thanks

@leijianning
Copy link

leijianning commented Apr 22, 2016

gooddddddddd

@xiaxiazhu
Copy link

xiaxiazhu commented Aug 22, 2016

赞。。

@0xbillw
Copy link

0xbillw commented Oct 28, 2016

赞!发人深省,自叹不如~~

@wat2012
Copy link

wat2012 commented Nov 1, 2016

看来,架构师和全栈比较接近了

@yangnuowei88
Copy link

yangnuowei88 commented Dec 27, 2016

踏实做人!

@76765357
Copy link

76765357 commented Feb 16, 2017

说的话,说到点子上了

@xboy2012
Copy link

xboy2012 commented Apr 15, 2018

个人不完全赞同这句话

架构和方向不应该朝着“高精尖”的方向走,那不应该是目标,“合适”的,才是最好的

这句话很容易被一些不思进取的程序员甚至架构师利用来做偷懒的借口

举个例子吧,
就说Windows系统的发展,
最开始大家坚持用98
XP刚出来的时候被喷,最后大家还不是都开始用XP了。
后来Vista出来了,微软不给力,系统差强人意,还是很多人不用Vista。
再后来Win7出来了,前XP党们又转投Win7了。
而现在Win10出来了,Win7党(前XP党)们又开始“坚守阵地”了。。。

这其中值得思考的点是:
有人在喷新系统,但最后又不得不被push去接纳新系统。

还有个问题留给大家:
Windows Vista真的不如XP么?

那么既然要接纳新事物,为何非要被动接受,而不抱有主动地心态呢?

如果仅仅是固守在“合适”的舒适地,那么,用现在流行的一句话,“时代抛弃你,从来不说再见”

  • 最开始寥寥几个JS和静态资源就可以直接完成项目,老板觉得你干活又快又好
  • 后来出了grunt/gulp/webpack,你可以说项目不需要,扯出一堆不想改动的理由。
  • 再后来ES6/Babel出来了,你依然说项目不需要,配置巨复杂,还要额外配置webpack。。。
  • 再后来Vue/React出来了,你依然说迁移成本太大,还要用webpack/ES6/Babel,不适合现在项目。

那么问题来了,从现在来看,那个最开始到现在都一直没改动过的项目架构,
现在看来是合理的么?那还改不改?什么时候改?
你要招一堆新人过来给你写jQuery?

任何改动和升级必然是有风险和成本的。你不能因为这些就停滞不前了。
至于成本和风险,是优秀的架构师和开发者应该去宏观思考和解决的。
关于风险,没人逼着你带着一堆BUG去切换新技术,
再退一万步讲,任何方案和风险都是提前要评估的,
如果真的有无法解决的问题,那时再终止迁移方案,也是可行的。而不是什么都没做,就开始否定新技术。

面向未来,也是架构师最基本的素质吧,不然不就是鼠目寸光了么?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests