github注册不成功
Back in 2012 I witnessed a talk from a developer at GitHub, the topic: “Using GitHub: You’re not doing it right”. Developers in the room seemed perplexed. They’d studied how to use both Git and GitHub, in detail. They watched videos from early-adopter-programming-evangelists. By the time it was introduced at the company I was working for, we’d “mastered it”. So how could we be using it incorrectly?
早在2012年，我见证了GitHub开发人员的一次演讲，主题为：“使用GitHub：您做得不正确”。 房间里的开发商似乎很困惑。 他们详细研究了如何同时使用Git和GitHub。 他们观看了来自早期采用者编程讲师的视频。 当它在我所工作的公司推出时，我们已经“掌握了”。 那么我们怎么可能不正确地使用它呢？
GitHub is all about collaborative working in order to improve the way in which we develop systems.
GitHub就是为了改善我们开发系统的方式而进行的协作。
His talk went like this (and I must stress that I’m paraphrasing here, it was a long time ago): “So, I’ve looked at your pull requests, I’ve spoken to your line managers and as far as I can see, you’re writing lots of code on your own without making any commits. Eventually, once you’ve decided you’re done, then you create a pull request asking people to approve your work which seems to mean highlighting coding standard violations and errors, without any real evaluation of the purpose, approach taken and so on. Somewhat understandable given the 4000 lines you’re committing with a one paragraph rationale….
他的讲话是这样的(我必须强调，很久以前我在这里是这样解释的)：“所以，我已经查看了您的请求，我已经与您的部门经理进行了交流，就我而言可以看到，您自己编写了许多代码而没有进行任何提交。 最终，一旦您确定要完成，就创建一个请求请求，要求人们批准您的工作，这似乎意味着突出编码标准冲突和错误，而未真正评估其目的和所采用的方法等。 鉴于您要提交的4000行带有一个段落的基本原理，这有些理解……。
He went on. So that’s not the idea, you’re missing out on a heap of potential…Before you fork the project…
他接着说。 所以这不是个主意，您会错失一堆潜在的机会……在分叉项目之前……
Explanation required: Devs had collectively decided that we should be branching not forking the master branch because why would we care about other people’s branches? For those of you unfamiliar with this terminology, what I’m saying is that people were only interested in developing the master code repository, the code used in production, using what’s called a branch, a copy of the core/ master branch. Forking the core/ master branch would include copying the branches other developers were creating to develop whatever improvements/fixes to the core/master branch they were tasked with working on, onto their own systems so that they could see other people’s commit history and track how their changes would affect those changes. If people were seeking to truly “collaborate” on the project, they would have been forking not branching. So the point is, devs weren’t even seeking to collaborate with other devs, let alone non-devs.
需要说明：开发人员集体决定我们应该分支而不是分支master分支，因为我们为什么要关心其他人的分支？ 对于那些不熟悉该术语的人来说，我的意思是人们只对开发主代码存储库，生产中使用的代码，使用所谓的分支，核心/主分支的副本感兴趣。 分支核心/主分支将包括将其他开发人员正在创建的分支复制到他们自己的系统上，以开发他们对任务/核心/主分支所做的任何改进/修复，以便他们可以查看其他人的提交历史并跟踪其工作方式。他们的更改会影响这些更改。 如果人们想要真正地“协作”该项目，那么他们本来应该不分支。 因此，重点是，开发人员甚至没有寻求与其他开发人员合作，更不用说非开发人员了。
…and start looking at each others commits, you should have looked at the origins of tasks. Non-development/ in-direct development staff such as project managers, testers, sales people etc. should be involved in creating pull requests (palpable intake of breath from audience followed by registered look of disbelief) and raising issues, then they should be involved and kept up-to-date throughout the development you carry out. Developers should be tracking and commenting on each others branches during development, suggesting different approaches, helping out, identifying issues as they go... Once code is merged into the main branch, people that interact with end users should be commenting on issues reported by users, you can use this to identify room for personal development…It’s a philosophy change not just a new version control system, GitHub is all about collaborative working in order to improve the way in which we develop systems.” That was the general gist of the talk.
…并开始查看彼此的提交，您应该已经查看了任务的起源。 非开发/间接开发人员，例如项目经理，测试人员，销售人员等，应参与创建拉动请求(听众可吸入的呼吸声，然后以怀疑的眼神看待)并提出问题，然后他们应参与进来并在您进行的整个开发过程中保持最新状态。 开发人员应该在开发过程中互相跟踪和评论彼此的分支，提出不同的方法，提供帮助，并在问题发生时确定问题。将代码合并到主分支后，与最终用户进行交互的人员应该对由以下人员报告的问题进行评论用户，您可以使用它来确定个人发展的空间……这是一种哲学上的改变，而不仅仅是新的版本控制系统，GitHub的全部目的是为了改进我们开发系统的方式而进行的协同工作。” 那是谈话的总要旨。
Personally, I felt quite smug. I did remember thinking when the switch to GitHub from SVN was announced that the whole point was to shift from individuals submitting code to a more collaborative working practise that would involve taking other systems such as issue tracking, project management etc. and migrating it all to GitHub, so that we would all be interacting and managing the software development process using one platform. That was my instinctive feeling, but nobody else at the company I was working for at the time seemed remotely alive to this opportunity, and therefore I didn’t voice this out loud, and now here’s a guy, from GitHub, telling me I’m right!
就个人而言，我感到很自鸣得意。 我确实记得我曾想过，当宣布从SVN转到GitHub时，重点是要从个人提交代码转变为更具协作性的工作实践，这将涉及采用其他系统(例如问题跟踪，项目管理等)并将其全部迁移到GitHub，这样我们所有人都可以使用一个平台来交互和管理软件开发过程。 那是我的本能，但是当时我所工作的公司中没有其他人似乎对这个机会还活着，因此我没有大声说出来，现在有一个来自GitHub的家伙告诉我：我是对的！
Unfortunately, as you know, whether the guy from GitHub and myself were right mattered not a jot! Why? Because the customer is always right. GitHub’s customers are developers. Developers don’t want this. They’re developers for a reason. They’re happy with their existing job description and don’t want to entertain having to liaise with different people across the company to reach a consensus on how they should develop.
不幸的是，正如您所知，来自GitHub的家伙和我本人是否正确并不重要！ 为什么？ 因为客户永远是对的。 GitHub的客户是开发人员。 开发人员不希望这样。 他们是开发人员是有原因的。 他们对他们现有的职位描述感到满意，并且不想招待必须与公司中不同人员保持联系以达成关于他们应该如何发展的共识。
If that resistance to change alone wasn’t enough to lead GitHub away from the idea of insisting upon a collaborative approach, then the threat of some other company coming along and giving developers exactly what they want, essentially stealing their core idea, was a risk they would never flirt with given what was at stake. So there it was and still is, GitHub: Built for developers that want to work alongside (not with) 50 million other developers (that feel exactly the same way).
如果仅靠变革的抵制还不足以使GitHub摆脱坚持采用协作方法的想法，那么其他公司的威胁就会出现，并向开发人员提供他们真正想要的东西，这实际上是在窃取他们的核心思想，这是一个风险。他们绝不会嘲笑要害的东西。 GitHub曾经存在，现在仍然存在：专为希望与 5000万其他开发人员(而 不是与之合作)的开发人员(感觉完全相同 )而构建。
Later in time I thought to myself, what if GitHub didn’t stand to lose the title of the world’s leading software development platform and enough investment that it would make your eyes water? What if they stood firm and said “no, for the sake of development and progression in this industry, we insist you must change and incorporate everyone into the process of creating software”? So I set myself the task of uniting all the stakeholders involved in the process of developing a system by creating a platform that facilitates controlled, process driven collaboration.
后来我对自己想，如果GitHub不能不失去世界领先的软件开发平台的头衔以及足够的投资以至于让您眼前一亮？ 如果他们站稳脚跟并说：“不，为了这个行业的发展和进步，我们坚持您必须更改并将所有人纳入软件开发过程中”？ 因此，我为自己设定了一个任务，即通过创建一个促进受控的，流程驱动的协作的平台，将开发系统过程中涉及的所有利益相关者团结在一起。
I initially devised a rough process whereby Stakeholders, in fact let’s switch to calling them actors, actors would collaborate using an agile/ scrum like approach to create the tasks that define a system. A designated person (I believe they’re known as a Product Manager in Scrum) would organise the tasks based upon their agreed priority and ensuring “blocks” are avoided where possible i.e. One task needing to be finished before another begins. And this would be the same for all the actors contributing to the system. I’m sure many companies operate like this using GitHub (and similar), although they do so out of choice rather than necessity. With the system I’m envisaging, it’s the latter. Visually speaking, the platform I had in mind would resemble Codepen, without the code editor, which I would replace with tools that allow actors to alter the appearance and functionality of interfaces, bring to light issues that require attention and indicate how the elements making up the interface should function.
我最初设计了一个粗略的过程，在这个过程中，利益相关者(实际上)让我们切换到称呼他们为参与者，参与者将使用类似敏捷/ scrum的方法进行协作来创建定义系统的任务。 指定人员(我相信他们在Scrum中被称为产品经理)将根据他们商定的优先级来组织任务，并确保在可能的情况下避免“障碍”，即一个任务需要在另一个任务开始之前完成。 对于为系统做出贡献的所有参与者，这都是相同的。 我敢肯定，许多公司都是使用GitHub(及类似工具)进行此类操作的，尽管它们并非出于选择，而是出于选择。 我所设想的系统就是后者。 从视觉上讲，我想到的平台类似于Codepen ，但没有代码编辑器，我将用允许参与者改变界面的外观和功能，发现需要注意的问题并指出组成元素的工具来代替它。接口应该起作用。
You can see my approach in action at Yakety.co.uk. That’s the platform I’ve developed in its current and I must stress, unfinished, form. There is a central codebase that follows, a simple, standard flow, a flow that anyone tech or non-tech, can feasibly understand and use to collaborate on any given project. And despite the fact that the interface of the platform resembles a “web builder” and could easily be mistaken for a Wix, Squarespace, Webflow [enter no code platform of choice] competitor, it is in fact only meant to serve as a means of graphically depicting the development of a system to the actors involved in the development process. Instead of assigning an action to a button, you assign a task to a button, then a developer would pick that task up and make the button function a particular way, and a marketing expert might have an opinion about that and log a request to change the button, and a front-end developer may do the same and recommend applying some animation etc. The product manager would mediate (amongst all the actors) and establish a consensus (or call the shots depending on how democratic he/she feels like being).
您可以在Yakety.co.uk上看到我的方法在起作用。 那就是我目前所开发的平台，我必须强调未完成的形式。 接下来是一个中央代码库，一个简单，标准的流程，任何技术人员或非技术人员都可以切实理解并使用该流程在任何给定项目上进行协作。 尽管该平台的界面类似于“ Web构建器”，并且很容易被误认为是Wix，Squarespace，Webflow [没有选择任何代码平台]的竞争对手，但实际上，它仅是为了作为一种手段。以图形化方式向参与开发过程的参与者描述系统的开发。 无需将操作分配给按钮，而是将任务分配给按钮，然后开发人员将接管该任务并使按钮发挥特定作用，营销专家可能对此有意见并记录更改请求按钮，前端开发人员可能会做同样的事情，并建议应用一些动画等。产品经理会进行调解(在所有演员之间)并达成共识(或根据他/她的民主程度做出决定) )。
As I see it, Yakety just acts as an extension of GitHub. Behind the scenes the platform still uses GitHub (Well, Lab actually) for code storage, review and deployment. So the only sacrifice and I accept that it’s potentially a game changing sacrifice for some, is that Yakety (for now) depends on developers working with a single codebase and following this strict agile methodology I’ve touched upon. I’m not sure at this stage exactly how that sits with developers en masse (I will possibly find out when they read this!) but it’s impossible for me to envisage doing this any other way without the platform becoming so complex and developer orientated that we’re back to having a platform that is “built for developers”.
如我所见，Yakety只是GitHub的扩展。 在后台，该平台仍然使用GitHub(实际上是Well，Lab)进行代码存储，查看和部署。 因此，唯一的牺牲是我(对于某些人而言，这可能是改变游戏规则的牺牲)，因为Yakety(目前而言)取决于使用单个代码库并遵循我所接触的这种严格敏捷方法的开发人员。 在此阶段，我不确定开发人员是否会与之相处 (我可能会发现他们何时阅读！)，但我无法设想以其他方式进行此操作，而不会使平台变得如此复杂且面向开发人员我们又回到了“为开发人员构建”的平台。
It’s important to stress that nothing I’ve done with Yakety is concrete, it’s all conceptual and it will require enormous amounts of work and collaboration itself in order to get it where it needs to be in order to be taken seriously as a means to develop systems, particularly complex systems. But if you like what you’ve read, then be sure to comment, drop me an email (matt@yakety.co.uk) or better still, register and collaborate with me on the platform itself. Just don’t tell me to make it all about developers!
需要强调的是，我对Yakety所做的任何事情都不是具体的，都是概念性的，它本身就需要大量的工作和协作，以便将其放置到需要的位置，以便被认真地视为发展的手段。系统，特别是复杂的系统。 但是，如果您喜欢阅读的内容，请务必发表评论，给我发送电子邮件(matt@yakety.co.uk)或更好，在平台本身上注册并与我合作。 只是不要告诉我关于开发人员的一切！
I should add that all views expressed here, including that of my recollection of the conversation with the guy from GitHub are my own of course. I accept that working practices differ greatly from one company to another and that my generalisation simplifies certain scenarios to the point where some people may see no truth in my claims and to that end, I understand that Yakety will not be for everyone. I personally see Yakety as being a useful way for smaller companies that rely on subcontracting development work, to run their businesses on better quality systems, more cost effectively. I hope the people that I’m building it for agree because, as GitHub exposed, it will make all the difference!
我应该补充一点，这里表达的所有观点，包括我与来自GitHub的那个家伙的对话的回忆，当然都是我自己的观点。 我接受不同公司之间的工作惯例存在很大差异，并且我的概括简化了某些情况，以至于有些人可能看不到我的主张，为此，我明白，Yakety并不适合所有人。 我个人认为Yakety对于依赖转包开发工作的小型公司来说是一种有用的方式，可以在质量更高，成本效益更高的系统上开展业务。 我希望构建它的人都同意，因为，正如GitHub所公开的那样，它将带来一切改变！
Thanks for reading.
谢谢阅读。
github注册不成功
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
