开发经验和工作经验
Quick note: This is my first article, aiming to warn new developers in the industry and giving a small refresh to all developers! I wrote this one using my experience and some other sources that I will link at the end. Enjoy reading!
快速说明：这是我的第一篇文章，旨在警告行业中的新开发人员，并为所有开发人员提供一些小小的更新！ 我使用我的经验和最后将链接的一些其他资料来撰写此文章。 享受阅读！
“No product is an island. A product is more than the product. It is a cohesive, integrated set of experiences. Think through all of the stages of a product or service-from initial intentions through final reflections, from first usage to help, service, and maintenance. Make them all work together seamlessly.” — Donald Norman
“没有产品是孤岛。 产品胜于产品。 它是一组内聚的，整合的经验。 从最初的意图到最终的思考，从首次使用到帮助，服务和维护，对产品或服务的所有阶段进行思考。 让他们无缝地一起工作。” —唐纳德·诺曼(Donald Norman)
“Make them all work together seamlessly”, said Donald Norman, inventor of the term “User Experience” and professor in cognitive science in the ’90s at the University of California in San Diego. We should know, as developers of any kind, that our mission is to deliver a decent user experience. No matter what (and we will talk later of this “no matter what” again), we have to deliver something solid, something fast and something that can be easily understood and used. This is primarily the job of UX Designer to ensure that our app/website got a good UX but we, as developers, are also responsible for it and we need to make sure it works well.
“让他们无缝地协同工作” ， “用户体验”一词的发明者和90年代加州圣地亚哥大学的认知科学教授Donald Norman说。 作为任何类型的开发人员，我们应该知道我们的使命是提供体面的用户体验。 不管是什么 (稍后我们将再次讨论“无论如何”)，我们都必须提供可靠，快速且易于理解和使用的功能。 UX Designer的主要工作是确保我们的应用程序/网站具有良好的UX，但作为开发人员，我们也要对此负责，并且我们需要确保它运行良好。
用户体验(UX)和开发人员体验(DX) (User Experience (UX) and Developer Experience (DX))
Okay, okay slow down… Let’s defines both of them before diving into the real subject. We often hear about user experience and we should all be aware of this term.
好的，好的，放慢速度……让我们先定义两个对象，然后再讨论真正的主题。 我们经常听到有关用户体验的信息，我们都应该知道这个术语。
用户体验 (User Experience)
User Experience (UX) is really hard to explain… Simply because it means A LOT, and regroup A LOT of things. User Experience is a middle between “User Interface Design” and “Usability”. UX design, like I said cover a vast array of areas. UX design is a long, long process than even begins before the app is in the user’s hand.
用户体验(UX)真的很难解释……仅仅是因为这意味着很多，并且重新组合了很多东西。 用户体验介于“用户界面设计”和“可用性”之间。 就像我说的那样，UX设计涵盖了很多领域。 UX设计是一个漫长而漫长的过程，甚至比在将应用程序掌握在用户手中之前就已经开始。
开发人员经验 (Developer Experience)
Developer Experience (DX) is quite a new term in the industry. It is greatly related to UX in a sense, and clearly self-explanatory — “The experience lived by developers.” On the other hand, DX is related to some services especially made FOR developers (the targeted audience).
开发人员体验(DX)在行业中是一个新名词。 从某种意义上讲，它与UX密切相关，并且很明显是不言而喻的- “开发人员所经历的体验。” 另一方面，DX与某些服务有关，特别是针对FOR开发人员(目标受众)的服务。
Let’s take Stripe for example (an online payment platform), its usability is quite interesting. How can you know that this service respond to a DX and not an UX? So … you create an account, you log in, you go on the dashboard and BOOM, WOO, Stripe gives you a secret token, Webhooks, a DEVELOPER TAB in the navigation and an API Key?
让我们以Stripe为例(在线支付平台)，其可用性非常有趣。 您怎么知道该服务响应DX而不响应UX？ 所以……您创建一个帐户，登录，然后进入仪表板，BOOM，WOO，Stripe为您提供了一个秘密令牌，Webhooks，导航中的DEVELOPER TAB和API Key？
Stripe gives you directly “developers-only” information and doesn’t hide these options and settings in a subdomain like api.stripe.com. It’s why a “non-developer” person will be scared by this weird information and will be less tempted to use this online payment service, while a developer would be in paradise.
Stripe直接为您提供“仅供开发人员使用”的信息，并且不会在api.stripe.com之类的子域中隐藏这些选项和设置。 这就是为什么“非开发人员”会被这些怪异的信息吓倒，并且不那么愿意使用此在线支付服务的原因，而开发人员却会陷入天堂。
A good counterexample is Mailchimp (a marketing platform used to manage mailing list, newsletters and campaigns.) Unlike Stripe, Mailchimp hides the “developers-only” information in a different page. Mailchimp isn’t MADE FOR developers (even if developers can use it easily), their main target audience is marketers, which will not have trouble using it and will not be scared by weird developers stuff.
一个很好的反例是Mailchimp (用于管理邮件列表，新闻通讯和活动的营销平台。) 与Stripe不同，Mailchimp在另一个页面中隐藏了“仅供开发人员使用”的信息。 Mailchimp并不是面向开发人员的产品(即使开发人员可以轻松使用它)，他们的主要目标受众是营销人员，他们将不会遇到麻烦，也不会被奇怪的开发人员所吓倒。
Have you already seen a random guy using Codepen or AWS? Seriously? Hope you understand the difference now. :)
您是否已经看到使用Codepen或AWS的随机家伙？ 认真吗 希望您现在了解其中的区别。 :)
内部开发人员经验？ (Internal Developer Experience?)
In the previous section, we define the experience that our products as developers should provide. These experiences remains, in a way, totally external, we provide an experience (UX or DX) for a specific external target. We should not forget that we are using the product too (yes, really!) We are touching the internal code of these future applications, so we are using them also, it is logical, right? For me, it’s a complete different branch of the experience that I like to call the Internal Developer Experience. They may sound complicated to understand by now, so l will take an example.
在上一节中，我们定义了开发人员应提供的产品体验。 这些经验在某种程度上完全是外部的， 我们为特定的外部目标提供了经验(UX或DX)。 我们不要忘记我们也在使用该产品(是的，真的！)我们正在接触这些未来应用程序的内部代码，因此我们也在使用它们，这是合乎逻辑的，对吗？ 对我而言，这是我喜欢称之为Internal Developer Experience的体验的一个完全不同的分支。 到目前为止，它们听起来似乎很复杂，所以我举一个例子。
营救约翰 (John to the Rescue)
John is graduated from a marketing school, he was always a smart person and, as the tech industry arise, think that he should learn how to code. So he spent like 5 months taking courses over and over about HTML CSS and JS stuff to get his first job at “Lorem ipsum Agency” as a Front-End Developer. John never worked in a team before, he was just taking these courses online on “How to build a TO-DO list in HTML” (Please stop building to-do list guys, please…). John’s first mission was to build a website for a future industry with a navigation bar, a video player and a gallery. No problem for John, he made it successfully without any issue. He finished his website in time and the website is working, has a great User Experience and good performance for a new and fresh developer in the company.
John毕业于市场营销学院，他一直是一个聪明人，并且随着科技行业的兴起，他认为他应该学习编码。 因此，他花了大约5个月的时间反复学习有关HTML CSS和JS的课程，以便在“ Lorem ipsum Agency”担任前端开发人员的第一份工作。 John之前从未在团队中工作过 ，他只是在线上这些课程，内容是“如何用HTML 构建待办事项清单 ” (请停止构建待办事项清单人员，……) 。 John的首要任务是建立一个带有导航栏，视频播放器和画廊的面向未来行业的网站。 对约翰来说没问题，他成功地做到了没有任何问题。 他及时完成了自己的网站，该网站正在运行，对于公司中的新开发人员而言，它具有出色的用户体验和良好的性能。
(Until then, no worries, we agree?)
(在那之前，不用担心，我们同意吗？)
……然后莎拉来了 (… then Sarah came)
Next week, Sarah, another developer of “Lorem ipsum Company” had to develop a contact module on john’s website. So, Sarah opened his favorite code editor, cloned the repository of John’s website and, and…… She was completely lost, she didn’t understand any lines of code of john’s website, and the folder structure of this project was completely a mess! So, john had to take 5 hours to explain each file and function to Sarah, they lost a total of 10 hours of work (2 * 5 hours) and made “Lorem Ipsum Company” lose money and time.
下周，“ Lorem ipsum Company”的另一位开发商Sarah必须在john的网站上开发联系模块。 因此，莎拉(Sarah)打开了他最喜欢的代码编辑器，克隆了约翰(John)网站的存储库，然后……她完全迷路了，她不了解约翰(John)网站的任何代码行，并且该项目的文件夹结构完全是一团糟！ 因此，约翰不得不花5个小时向莎拉解释每个文件和功能，他们总共损失了10个小时的工作时间(2 * 5个小时)，并使“ Lorem Ipsum Company”损失了金钱和时间。
真正的问题是：为什么约翰以及如何通过一个不好的项目给莎拉？ (The real question is: Why and How John passed a bad project to Sarah?)
(Do you begin to understand where I’m going with the “Internal Developer Experience”, wait a minute, I will explain it in detail.)
(您是否开始了解“内部开发人员体验”的发展方向，请稍等一下，我将对其进行详细说明。)
This is a schema representing the time spent by John working on his website.
这是一个表示John在其网站上花费的时间的架构。
But … something in this schema is missing, something crucial is missing in John’s website. John does not understand why Sarah can’t work on it. John forgets about the “Internal Developer Experience”, he forgets about the best practices in terms of “working in a team” and that his code should not JUST be readable by himself but by ANY developers.
但是……这种模式中的某些东西丢失了，约翰的网站中缺少了一些关键的东西。 约翰不明白莎拉为什么不能为此工作。 John忘记了“内部开发人员的经验”，他忘记了“团队合作”方面的最佳实践，并且他的代码不应该被任何开发人员自己理解。
So let’s take a look at John’s timeline and let’s correct this. Here is what john should have done with his project.
因此，让我们看一下约翰的时间表，并进行更正。 这是约翰应该为他的项目做的事情。
What a complicated timeline? Isn’t it? How can John do two things at the same time? And firstly, what’s documentation and refactoring?
时间表多么复杂？ 是不是 约翰如何同时做两件事？ 首先，什么是文档和重构？
Let’s start with the beginning, definitions.
让我们从定义开始。
Code refactoring is the process of restructuring existing code into a more “readable” and often more “performant” of this code while preserving its functionality. Refactoring is intended to improve the design, structure, maintainability of an existing code source while creating a much cleaner, less complex and a more architectural version of it.
代码重构是在保留其功能的同时，将现有代码重组为该代码更“易读”且通常更“高性能”的过程。 重构旨在改善现有代码源的设计，结构，可维护性，同时为其创建更简洁，更简单和更具体系结构的版本。
With some little refactoring session, John would have delivered a better experience to Sarah, right?Can he do better than that? (Answer: always!)
只需进行一些重构会议，John就会为Sarah提供更好的体验，对吗？他能做得更好吗？ (答案：总是！)
Documentation is documentation, seems pretty obvious, but what does it mean for a developer?
文档是文档，看起来很明显，但是对开发人员意味着什么呢？
It sounds simple? Written good comments is hard, it takes time, sometimes you know what you are doing, but you have difficulties to explain it, or to be sure to be understood (myself included). You have to be explicit about WHAT the code does and HOW it does it.
听起来很简单？ 书面好的评论很难 ，需要时间，有时您知道自己在做什么，但是很难解释它，或者一定要被别人理解(包括我自己)。 您必须明确说明代码的作用以及如何执行。
Last advice:
最后建议：
Your documentation needs to be ready at any time, be sure not to do it the last day. Example: you get sick Monday and the delivery is Tuesday, I hope someone in your company can work on your project!
您的文档需要随时准备就绪 ，请确保不要在最后一天做。 示例：您周一生病，交货时间为周二，希望您公司中的某人可以从事您的项目！
Don’t over-document: The code may be self-explanatory sometimes. You should have good quality and minimal documentation in your source code.
不要过度编写文档：有时代码可能是不言自明的。 您的源代码中应具有良好的质量和最少的文档。
Documentation has to be part of our job as developers, you have mainly two cases where you NEED to document it:
作为开发人员 ，文档编制是我们工作的一部分，主要有两种情况需要记录文档：
The first one: The case of John and Sarah, you have to pass a project to a colleague, your code needs to be enough documented to be understood by others than yours. It seems logical, since the other developer is not in your head and not behind you when you are working in your company (I hope), he can’t completely understand the “way” you developed the project.
第一个：以John和Sarah为例， 您必须将一个项目传递给一位同事，您的代码需要有足够的文档记录才能被您的他人理解。 这似乎是合乎逻辑的，因为当您在公司工作时，另一个开发人员不在您的头脑中，也不在您身后(我希望)，因此他无法完全理解您开发项目的“方式”。
The second one: Imagine working on a website, everything is fine again (like John’s case). One year pass, and you have to get back on this project and make adjustments on a module that you made 1 YEAR before… And you know what? You don’t understand any lines of codes! Good luck … and document it this time!
第二个：想象在网站上工作，一切都很好(就像约翰的情况一样)。 一年过去了， 您必须回到这个项目上，并对在1年之前制作的模块进行调整 ……您知道吗？ 您不懂任何代码行！ 祝您好运…并记录下来！
I could have made a full article on just “refactoring” and “documentation” (maybe one day), I let you google these terms if you are looking for more information.
我本可以写一篇关于“重构”和“文档”的完整文章(也许有一天)，如果您需要更多信息，我可以用google搜索这些术语。
Even if these two methods sounds like an obligation, we often tend to forget the cons that comes with the pros:
即使这两种方法听起来像是一种义务，我们也往往会忘记优点带来的弊端：
PROS:
优点：
- The code is more readable, simpler and cleaner. 该代码更易读，更简单，更简洁。
- We ensure that we are going in the right direction when we are coding and adding comments at the same time (to know what we are doing). 我们确保在编码和添加注释的同时朝正确的方向前进(以了解我们在做什么)。
- Passing the project to another developer is not a pain (on both sides). 将项目传递给另一位开发人员并不难(双方)。
- You could save money, time and headaches ! 您可以节省金钱，时间和头痛！
CONS:
缺点：
- If the code changes, you have to changes and correct the comments (nearly ever done). 如果代码更改，则必须更改并更正注释(几乎完成了)。
- It takes times, refactoring and documenting your code isn’t free. It cost you time and so money. 这需要时间，重构和记录代码不是免费的。 它花费了您时间和金钱。
- If you have a short deadline, you would sometimes have to neglect the ‘refactor’. Deadlines come before UX / DX and Internal Developer Experience unfortunately. 如果您的截止日期很短，有时您可能会忽略“重构”。 不幸的是，截止日期早于UX / DX和内部开发人员经验。
摘要 (Summary)
Did you remember ?
你是否记得 ？
“…Think through all of the stages of a product or service — from initial intentions through final reflections, from first usage to help, service, and maintenance. Make them all work together seamlessly.” — Donald Norman
“……仔细研究产品或服务的所有阶段-从最初的意图到最终的思考，从首次使用到帮助，服务和维护。 让他们无缝地一起工作。” —唐纳德·诺曼(Donald Norman)
“From first usage to help, service, and maintenance.” “Maintenance” here refers directly to what we talked about (Internal Developer Experience).
“从首次使用到帮助，服务和维护。” 这里的“维护”直接指的是我们所说的(内部开发人员体验)。
Today, I wanted to separate these three topics (UX/DX/Internal Developer Experience) but they are in a way all linked together. I hope you understood the importance of them and you will apply them in your future projects. Again, documenting a project is hard, it takes times, but the benefits are worth it.
今天，我想将这三个主题(UX / DX /内部开发人员经验)分开，但是它们以某种方式链接在一起。 希望您了解它们的重要性，并将其应用于未来的项目中。 同样，记录一个项目很困难，需要时间，但是好处是值得的。
They are all made to ensure the future of an application/website.UX and DX for growing and keeping the users base and the Internal Developer Experience to ensure the maintainability and the evolution of it.
它们都是为了确保应用程序/网站的未来而发展。UX和DX用于增长和保持用户基础，并具有内部开发人员体验以确保其可维护性和发展性。
Sources: My experiencehttps://developerexperience.io/practices/good-developer-experiencehttps://css-tricks.com/what-is-developer-experience-dx/https://en.wikipedia.org/wiki/Code_refactoringhttps://blog.submain.com/how-to-document-code/
资料来源：我的经验 https://developerexperience.io/practices/good-developer-experience https://css-tricks.com/what-is-developer-experience-dx/ https://zh.wikipedia.org/wiki/Code_refactoring https://blog.submain.com/how-to-document-code/
翻译自: https://uxdesign.cc/delivering-a-good-experience-as-a-developer-128c27491943
开发经验和工作经验
扫一扫
8265
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
