git精心

重点 (Top highlight)

As a programmer, are you guilty of writing hacky code that stinks or pushing code without testsMe too … and everyone else I know.

作为一名程序员，您是否犯了发臭的hacky代码或未经测试就推送代码的罪名我也是……我认识的其他人。

At times, I had to be empathetic toward myself as a developer who, pressed for time, allowed untested code to sneak in. Other times, I thought I was pleasing managers who thought quick wins implied faster delivery at the cost of quality.

有时，我必须对作为一名开发人员的同情，因为他们迫于时间，允许未经测试的代码潜入。有时，我以为我很喜欢管理人员，他们认为快速获胜意味着以质量为代价来加快交付速度。

Whatever be the reason, it’s us developers digging our own grave by adding or approving smelly, untested code. In such environments, it didn’t take too long before technical debt piled up to form a hot spaghetti mess of legacy code. I think I broke a sweat just thinking about it.

不管是什么原因，都是我们开发人员通过添加或批准臭味未测试的代码来挖掘自己的坟墓。 在这样的环境中，不久之后技术债务就堆积成一堆热腾腾的遗留代码。 我想我只是想了一下就大汗淋漓。

I’ve been in development long enough to understand that top-notch code quality and discipline is a sure-shot path leading to sustainable development. So here I am presenting you with my findings about software craftspersonship (no, it isn’t crafts-man-ship!).

我从事开发工作已经足够长的时间了，以了解一流的代码质量和纪律是通往可持续发展的必经之路。 因此，在这里，我向您介绍有关软件手Craft.io的发现(不，这不是手Craft.io人！ )。

关心您的手艺 (Care About Your Craftspersonship)

First and foremost, care about what you do. When you care it reflects in your work. If you don’t care about the quality of the code, nobody else will. Engineers are the owners of the codebase. Day in and day out, all we do is add and remove code. For most onlookers, code is an enigma.

首先，要关心您的工作。 当您关心时，它就会反映在您的工作中。 如果您不关心代码的质量，没有其他人会。 工程师是代码库的所有者。 日复一日，我们要做的就是添加和删除代码。 对于大多数围观者来说，代码是一个谜。

A well-crafted, easily maintainable, clean codebase is every developer’s dream. Many codebases I started with had tons of technical debt left over by predecessors. Some were messed up by freelancers and others by developers who didn’t push hard enough to prioritize technical debt.

精心设计，易于维护，简洁的代码库是每个开发人员的梦想。 我开始使用的许多代码库都有前辈留下的大量技术债务。 一些人被自由职业者弄得一团糟，其他人则被开发者弄得一团糟，他们没有尽全力确定技术债务的优先级。

In most cases, managers didn’t understand the fact that prioritizing technical debt is critical to smooth, uninterrupted development — which saves time and effort in the future. It’s a long-term investment.

在大多数情况下，管理人员并不了解以下事实：优先考虑技术债务对于平稳，不间断的开发至关重要-这可以节省未来的时间和精力。 这是一项长期投资。

成为开发者惯例的朋友 (Befriend Developer Conventions)

I recommend a team with at least two devs (or more) to always write down the standard principles and practices used in a wiki or notion page. It prevents a lot of inconveniences and stepping on toes when you start working together.

我建议至少有两个开发人员(或更多)的团队始终写下Wiki或概念页面中使用的标准原则和实践。 当您开始一起工作时，它可以防止很多不便和踩到脚趾。

I had a gist I converted to blog overtime here. Whenever I worked with new developers, I inherited a few good patterns from my list and accepted new ones that made sense from them. This provides an opportunity to talk about your likes and dislikes and to tailor standard practices to suit the needs of your codebase.

我有一个要点，我在这里加班改成了博客。 每当我与新开发人员一起工作时，我都会从列表中继承一些好的模式，并接受对他们有意义的新模式。 这提供了一个讨论您的喜好和定制标准实践以适合您的代码库需求的机会。

Say, there’s confusion with regard to what needs to be done in a particular scenario with naming tests. You can go back and look it up on your wiki page. If you don’t find that covered, discuss it with the team, and take the liberty to add it.

说，在命名测试的特定情况下需要做什么是令人困惑的。 您可以返回并在Wiki页面上查找它。 如果您没有找到涵盖的内容，请与团队讨论，并随意添加。

Make this document your source of truth so you can point to the team agreement during any conflicts.

使此文档成为您的真理来源，以便您在出现任何冲突时都可以参考团队协议。

Hacky解决方法=滑坡 (Hacky Workarounds = Slippery Slope)

Hacky workarounds will seduce you, engulf you, and leave you high and dry. Like how you wouldn’t put anything toxic into your body, don’t put anything hacky into the codebase.

棘手的解决方法会引诱您，吞噬您，并使您变得高高干燥。 就像您不会在体内放置任何有毒物质一样，也不要在代码库中放置任何骇人听闻的东西。

Hacky solutions on Stack Overflow are fast, shiny, and tempting. But if you don’t understand why it is the way it is, it can be toxic and in worst cases, prove detrimental to your codebase. Resist going down that patht’s a slippery slope. Get to the bottom of things. As much as possible, try not to look at Stack Overflow but to read the docs from credible sources.

Stack Overflow上的Hacky解决方案快速，闪亮且诱人。 但是，如果您不明白为什么会这样，它可能是有毒的，并且在最坏的情况下，证明对您的代码库有害。 拒绝沿着那条路走-这是一个湿滑的斜坡。 深入研究。 尽可能不要看堆栈溢出，而是从可靠的来源阅读文档。

Hacky solutions could be useful at times, but try to modify them to your needs. Absolutely avoid copy-pasting.

hacky解决方案有时可能很有用，但请尝试根据您的需要进行修改。 绝对避免复制粘贴。

Most solutions I encounter on the internet are written by hand and untested. Don’t make the mistake of assuming people answering a question on the internet are experts. Take some time to debug the root cause — the solution will come to you.

我在互联网上遇到的大多数解决方案都是手写的，未经测试。 不要误以为在互联网上回答问题的人都是专家。 花一些时间调试根本原因-解决方案将向您提出。

This is also a good example to determine if you need to pair program. An extra set of eyes can prove beneficial when you encounter such dilemmas.

这也是确定是否需要配对程序的好例子。 当您遇到这样的困境时，多留一双眼睛会很有帮助。

遵守严格的审查政策 (Follow Strict Review Policies)

First things first:

第一件事：

Review your review process.

审核您的审核过程。

Seriously, this isn’t for the sake of a pun. Your peer-review process could be the culprit stopping you from having an awesome development environment.

认真地说，这不是出于双关语。 您的同行评审过程可能是导致您无法拥有令人敬畏的开发环境的罪魁祸首。

Start with taking a hard look at your code-review process. Make a note every time someone doesn’t adhere to the process and provide constructive feedback during code reviews. Don’t be lenient and let it go. Also, avoid the temptation to approve the PR only because the sunk-cost fallacy has kicked in or the developer requested you to.

首先仔细研究您的代码审查过程。 每次有人不遵守该流程时进行记录，并在代码检查期间提供建设性的反馈。 不要宽容，放手。 另外，避免沉迷于成本下降的谬论或开发商要求您批准PR的诱惑。

Your code needs a stellar review process that checks off good coding conventions. Have a PR template reinforcing mandatory and optional checklist items — like a screengrab of features, a self-review before issuing the PR, unit tests with special edge cases, a screengrab of the code coverage from Android Studio, or adding a plugin like Codecov to GitHub. Whatever works for your team.

您的代码需要一个出色的审核过程，以检查良好的编码约定。 有一个PR模板来加强必选和可选的清单项目-例如功能的抓屏，发布PR之前的自检，特殊情况下的单元测试，Android Studio的代码覆盖范围的抓屏，或将Codecov等插件添加到GitHub。 无论对您的团队有什么用。

Make sure it becomes a norm to comment on certain changes without hesitation. Also, be certain to appreciate a good piece of work or proactiveness. This goes a long way in building good team morale.

确保毫不犹豫地评论某些更改已成为一种规范。 另外，一定要欣赏一件好事或积极主动。 这对于建立良好的团队士气很有帮助。

The team owns the codebase, and pointing out typos, mistakes, probable defects, etc. is the job of the reviewer. Have at least two people review the code whenever possible. The first step toward a clean codebase is to ensure as little or no potential technical debt is added at any given point of time. The PR process plays a vital part in achieving this.

团队拥有代码库，指出打字错误，错误，可能的缺陷等是审阅者的工作。 尽可能让至少两个人检查代码。 迈向干净代码库的第一步是确保在任何给定时间点添加尽可能少或没有潜在的技术债务。 公关过程在实现这一目标中起着至关重要的作用。

测试不是可选的 (Testing Isn’t Optional)

Want to hear my two cents on pushing untested code/p>

是否想听我关于推动未经测试的代码的两分钱

Don’t do it.

不要这样

It physically aches me to approve a PR without tests. In my experience, I’ve seen developers with a decade of experience do it, too. Don’t lower your standards and allow bad practices to creep in.

不通过测试就批准PR的举动给我造成了身体上的痛苦。 以我的经验，我已经看到有十年经验的开发人员也这样做。 不要降低您的标准，并允许不良做法蔓延。

Imagine you were asked to just write a few features initially and you thought the project was never going to come back, so you delivered a product without tests. Unfortunately, one day, the project did come back. Now, you have no documentation because it was done in a hurry (happens almost all the time) and can’t rely on your memory to remember what the requirements were, so basically you’re in soup.

想象一下，您最初只是被要求编写一些功能，而您认为该项目永远不会回来，所以您交付了没有测试的产品。 不幸的是，有一天，该项目确实回来了。 现在，您没有文档，因为它是匆忙完成的(几乎总是发生)，并且不能依靠您的记忆来记住要求是什么，所以基本上您的工作量很大。

Tests are the single most effective way of documenting business requirements.

测试是记录业务需求的最有效的单一方法。

Ideally, your code should be ironclad with tests, including tests that verify the business logic, integration with APIs and persistence layers, and UI/acceptance tests.

理想情况下，应该对您的代码进行测试，包括验证业务逻辑的测试，与API和持久层的集成以及UI /接受测试。

You can’t always cover 100% of the codebase with, tests but the least you can do is make sure you add unit tests to cover most of the business logic. When code changes or tests break, you’ll know what changed and be able to rewrite the tests according to new requirements.

您不能始终使用测试覆盖100％的代码库，但是您至少可以做的是确保添加单元测试以覆盖大多数业务逻辑。 当代码更改或测试中断时，您将知道更改的内容，并能够根据新要求重写测试。

Test-driven development is how you can be certain your code is doing what you were asked to do. It can be treated as the official documentation of the codebase. This is also how you save yourself from trouble during long-term maintenance.

测试驱动的开发可以确保您的代码正在执行要求的操作。 可以将其视为代码库的官方文档。 这也是您在长期维护期间免于麻烦的方式。

If your code has no tests. Get it to a state in which you can write some tests for important logic.

如果您的代码没有测试。 使其处于可以编写一些重要逻辑测试的状态。

“Good design is testable, and design that isn’t testable is bad.”

“好的设计是可以测试的，而不能测试的设计是不好的。”

— Michael C. Feathers, “Working Effectively with Legacy Code”

— Michael C. Feathers，“有效地使用旧版代码”

重构旧版代码 (Refactor Legacy Code)

As far as I’ve seen, even the best of the best flip when they hear the word refactoring. It’s the scariest word for managers to hear from developers. I’ve even been penalized before for making the state of the codebase transparent and talking about the major setbacks in the codebase leading to slow development processes.

据我所知，即使他们听到重构这个词，即使是最好的翻转也是如此。 对于管理人员来说，这是最可怕的词。 之前，我甚至因为使代码库的状态透明化并谈论导致开发流程缓慢的代码库的重大挫折而受到惩罚。

Some managers don’t want to hear what’s wrong but want continuous deliverables to be unaffected. It reminds me of this comic I stumbled upon.

一些经理不想听错了，但希望连续交付的产品不受影响。 它使我想起了我偶然发现的这部漫画。

If I were a civil engineer, my life would probably be much simpler. The problem would be simple to explain.

如果我是土木工程师，我的生活可能会简单得多。 这个问题将很容易解释。

Sadly, managers don’t understand code. You can’t point to a piece of code and go, “This part is broken and needs fixing or we can’t build this feature.” When I did, I heard one manager say, “Work around it.” You can’t work around something that’s broken. If you did, it’d only add more technical debt.

可悲的是，经理们不了解代码。 您无法指向一段代码，然后说：“此部分已损坏，需要修复，否则我们将无法构建此功能。” 当我这样做时，我听到一位经理说：“解决它。” 您无法解决已损坏的问题。 如果这样做，只会增加更多的技术债务。

Refactor code pragmatically. Take the time you need to get rid of pressing technical debt whenever necessary. Dealing with legacy code isn’t easy, but it needs to be done. Convince whoever it takes to prioritize technical debt.

实用地重构代码。 花些时间在必要时摆脱紧迫的技术债务。 处理遗留代码并不容易，但是需要做到。 说服优先考虑技术债务的人。

I soon realized keeping quiet wasn’t going to cut it. Having a voice and taking responsibility for one’s craft is paramount to preserving sanity — and it’ll bring you a step closer to beautiful code.

我很快意识到保持安静不会减少它。 保持声音和对自己的Craft.io负责对保持理智至为重要-它将使您更接近美观的代码。

做正确的事 (Do the Right Thing)

The most common response to bad coding practices is to give in. To wait for someone else to do something because it’s easy. But easy isn’t going to make your job any easier.

对不良编码实践的最常见React是屈服。因为这很容易，所以要等待别人做某事。 但是轻松并不会使您的工作变得更轻松。

When you know something shouldn’t be there, get rid of it. When you know something needs fixing, just do it. Communicate and collaborate with concerned people to help you do the right thing. Performing a job effectively requires one to be able to negotiate with others critically.

当您知道不该有的东西时，请摆脱它。 当您知道某些问题需要修复时，请执行此操作。 与相关人员进行沟通和协作，以帮助您做正确的事。 有效地完成一项工作要求一个人能够与他人进行严格的谈判。

Do your research. Read a book. Be present in communities. Talk to other expert developers. Whatever it takes. Broaden your knowledge about things you want to focus on. Analyze all of the tiny and big problems, and come up with a feasible plan that integrates well with your current process.

做你的研究。 读一本书。 出现在社区中。 与其他专家开发人员交谈。 不管付出什么代价。 拓宽您要关注的事物的知识。 分析所有细微的和大的问题，并提出一个可行的计划，该计划与您当前的流程很好地集成在一起。

At the end of the day, by being convincing, collaborative, and communicative you’ll be much closer to achieving your goals. Because … development is a job that can only be done collaboratively. Communication is key.

归根结底，通过说服力，协作性和沟通性，您将更接近实现目标。 因为…开发是一项只能协同完成的工作。 沟通是关键。

Going from a statement like “A user must be able to log in” to the user literally being able to log in on a website or an app requires intense collaborative efforts.

从诸如“用户必须能够登录”之类的陈述到真正能够在网站或应用程序上登录的用户，需要付出大量的协作努力。

Lastly, I want to conclude by saying, I encourage you to do the right thing. Believe me: Doing the right thing is a good thing.

最后，我想说一句，我鼓励您做正确的事。 相信我：做正确的事是一件好事。

最后的想法 (Final Thoughts)

Even the best, well-maintained codebase can start accumulating technical debt if not continually crafted with care. Development is a journey, not a destination.

如果不精心设计，即使是最好的，维护良好的代码库也可以开始积累技术债务。 发展是一段旅程，而不是终点。

A good codebase is easy to read, understand, and modify. The responsibility lies with a developer to care about the codebase and wellness of your peers and successors. We all know how annoying it is to read bad code.

良好的代码库易于阅读，理解和修改。 开发人员有责任关心您的同行和后继者的代码库和健康状况。 我们都知道阅读错误代码是多么烦人。

Devs who care about writing clean code are truly one of a kind. They’re obsessed with continuous learning and improvement. Though this seems basic, when it comes to engineering, it’s an extraordinarily difficult feat. My sincere respect for such caring souls.

关心编写简洁代码的开发人员确实是其中一种。 他们一直在不断学习和改进。 尽管这看起来很基础，但在工程方面，却是一项异常艰巨的壮举。 我真诚地尊重这样的爱心者。

There’s something special about engineers who genuinely care about their craft — they simply make everyone’s lives better.

真正关心自己Craft.io的工程师有一些特别之处–他们只是使每个人的生活变得更好。

翻译自: https://medium.com/better-programming/crafting-software-with-care-7fde33c85ab3

git精心

文章知识点与官方知识档案匹配，可进一步学习相关知识Python入门技能树首页概览208564 人正在系统学习中 相关资源：iZotope Ozone VST (臭氧) V4.0.3.274 绿色汉化版.zip-制造工具类…

来源：一二三是五六十