當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

跟随器反馈回路电阻_如何将短反馈回路设置为单独编码器

發布時間：2023/11/29 编程问答 66 豆豆

生活随笔收集整理的這篇文章主要介紹了跟随器反馈回路电阻_如何将短反馈回路设置为单独编码器小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

跟隨器反饋回路電阻

I’ve spent the last couple years as a solo freelance developer. Comparing this experience to previously working in companies, I’ve noticed that those of us who work alone can have fewer iterative opportunities for improvement than developers who work on teams.

在過去的幾年中，我以自由開發者的身份工作。與以前在公司工作過的經驗相比，我注意到與團隊工作的開發人員相比，我們一個人工作的迭代機會更少。

In order to to have opportunity to improve, we need to embrace the concept of a short feedback loop. This is a process of incorporating new learning from observation and previous experience continuously over a short period of time. This process has to be manufactured by people working mostly alone, instead of, as is often the case, adopted when you join a team.

為了有機會進行改進，我們需要采用短反饋循環的概念。這是一個在短時間內連續從觀察和以前的經驗中學到新知識的過程。這個過程必須由人大多是獨自工作，而不是進行制造，這是常有的情況下，當你加入一個團隊采用。

In this post, I hope to share what I’ve learned about setting yourself up to improve quickly and continuously as a solo coder.

在這篇文章中，我希望分享我所學到的關于如何設置自己的知識，以便快速，連續地提高自己作為獨立編碼員的能力。

關于反饋循環 (About feedback loops)

United States Air Force Colonel John Boyd developed the concept of the OODA loop, OODA being an acronym for observe, orient, decide, act. In military operations, this illustrates a process of decision-making based on the constant ingestion of new information:

美國空軍上校約翰·博伊德(John Boyd)提出了OODA循環的概念，OODA是觀察，定向，決定和行動的首字母縮寫。在軍事行動中，這說明了基于不斷吸收新信息的決策過程：

Observe: Obtain raw information about unfolding circumstances and the current environment.

觀察：獲取有關進展情況和當前環境的原始信息。

Orient: Put raw observations in context. Consider such things as relevancy to the current situation and previously gained knowledge and expertise.

方向：將原始觀察結果放在上下文中。考慮與當前狀況和先前獲得的知識和專長相關的事物。

Decide: Make a plan for moving towards your goal.

決定：制定實現目標的計劃。

Act: Execute the plan.

行動：執行計劃。

Since it’s a loop, the act stage leads directly back into the observe stage. This is the critical “feed back” concept that enables increasingly successful iterations. It’s widely applicable beyond military operations — you may recognize it as the origin of the PDCA (plan-do-check-act) method.

由于是循環，因此動作階段直接回到觀察階段。這是至關重要的“反饋”概念，可以使迭代越來越成功。它廣泛應用于軍事行動之外-您可能會認為它是PDCA (計劃執行檢查行動)方法的起源。

I like the OODA loop, as it’s a succinct illustration of a general feedback loop. Many concepts and working methods build on the idea of feedback loops, including DevOps and agile software development methods.

我喜歡OODA循環，因為它是一般反饋循環的簡潔說明。許多概念和工作方法都基于反饋循環的思想，包括DevOps和敏捷軟件開發方法。

開發團隊反饋循環 (Development team feedback loop)

Let’s look at what some components of a feedback loop for a developer on a team might look like:

讓我們看一下團隊??中開發人員的反饋循環的某些部分可能是什么樣的：

Direction from product owners or reviews from users

產品負責人的指示或用戶的評論

Daily scrum/standup with whole team

每天與整個團隊一起狂歡/站立

Prioritization with developer team

與開發團隊優先

Individual coding and testing

個別編碼和測試

Peer code review

對等代碼審查

Deployment and performance monitoring

部署和性能監控

Implicit in these steps is the support of co-workers and management — in other words, someone to answer to. How can a solo freelance developer create a similar environment of accountability?

這些步驟中隱含的是同事和管理層的支持-換句話說，是要回答的人。一位自由職業開發人員如何創建類似的問責環境？

開發人員反饋循環 (Solo developer feedback loop)

Here are some possible steps that an individual freelance developer can implement to create a short feedback loop:

自由職業者開發人員可以執行以下一些步驟來創建簡短的反饋循環：

Build discipline

建立紀律

Clarify concrete top-level goals

明確具體的最高目標

Prioritize and plan mid-level and low-level goals

優先安排和計劃中級和低級目標

Automate your work

自動化您的工作

Block out time for code review

抽出時間進行代碼審查

Block out time for process review

抽出時間進行流程審查

Update your goals and processes with the results of your reviews

用評論結果更新您的目標和流程

I’ll cover each of these stages in detail below.

我將在下面詳細介紹每個階段。

建立紀律 (Build discipline)

More of a prerequisite than a stage in itself, building discipline is what enables our short feedback loop to work. Nothing else in this article will be helpful unless we have the skill to do something we don’t want to do. Discipline is most certainly a skill. It can be learned, trained, and improved just like any other.

建立紀律本身比階段本身更重要，但前提是要使我們的簡短反饋回路能夠正常工作。除非我們有技巧去做我們不想做的事，否則本文中的其他內容將無濟于事。紀律無疑是一種技能。可以像其他任何方法一樣學習，培訓和改進它。

Why is discipline so important? Because when we’re crunching to get a project completed this Friday evening, we’re not going to want to write a good commit message. We’re not going to want to clean up the code comments. We just want to see the darn thing go, Hello, git push -f.

為什么紀律如此重要？因為當我們努力在這個星期五晚上完成一個項目時，我們不想寫一個好的提交信息。我們不想清理代碼注釋。我們只想看看該死的東西，嗨，git push -f 。

It’s in those moments that discipline enables us to not miss an opportunity to practice, learn, and improve our work process. Discipline helps us avoid Friday night commits that turn into Monday morning git reset --hards.

正是在這些時刻，紀律使我們不能錯過實踐，學習和改善工作流程的機會。紀律幫助我們避免周五晚上的提交變成星期一早上的git reset --hard 。

明確具體的最高目標 (Clarify concrete top-level goals)

Whether working for a client or bootstrapping our own best-new-app-ever, we won’t be able to measure any progress or improvements without something to measure them against.

無論是為客戶工作還是引導我們自己有史以來最好的新應用程序，如果沒有針對它們的衡量標準，我們將無法衡量任何進度或改進。

When I’m discussing a new project with a client, I always speak in terms of concrete achievements. This could take the form of accomplishing a specific feature by a certain date, or deciding what the MVP looks like to a user. This is as much for my benefit as my client’s. By agreeing, in writing, what will be achieved and when, my client and I have clearly defined top-level goals and can both assess how the project is progressing.

當我與客戶討論新項目時，我總是會說具體的成就。這可以采取在某個日期之前完成特定功能的形式，也可以決定MVP對用戶的外觀。這對我和我的客戶都一樣有利。通過書面協議，將實現什么目標以及何時達成協議，我和我的客戶已經明確定義了最高目標，并且都可以評估項目的進展情況。

When I’m working for myself, I treat myself as I would a client. I make a commitment, in writing, describing what will be achieved, and when. This can be something as simple as a goals list for the week, or as detailed as a kanban board.

當我為自己工作時，我會像對待客戶一樣對待自己。我以書面形式做出承諾，描述將要實現的目標以及何時實現。這可以像一周的目標列表一樣簡單，也可以像看板一樣詳細。

The point of having a concrete goal, however, is not to stick to it at all costs. It’s important to set an expectation, with ourselves and with our clients, that the goals will be revisited at mutually-agreeable dates over the course of the project. This enables the all-important “feed back” part of the loop.

但是，有一個具體目標的目的不是要不惜一切代價堅持下去。與我們自己和我們的客戶一起設定期望是很重要的，在整個項目過程中將在雙方同意的日期重新確定目標。這樣可以實現循環中最重要的“反饋”部分。

優先安排和計劃中級和低級目標 (Prioritize and plan mid-level and low-level goals)

Few goals are achieved all in one step. Even the simple process of making a peanut butter and jelly sandwich (a favourite computer programming teaching example) can be broken down into successively smaller, more precise instructions. While we humans may not require the granularity that a computer program does, goals that are chunked into time-boxed, achievable steps are much more easily digested. ?

幾乎沒有一個目標可以全部實現。甚至制作花生醬和果凍三明治的簡單過程(最喜歡的計算機編程教學示例 )也可以分解為依次更小的更精確的說明。雖然我們人類可能不需要計算機程序所需要的粒度，但將目標分解為時間限制，可實現的步驟變得更加容易了。？

Start with the mid-level goals, and make each step concrete. If the goal is to release a new open source web app, for example, the steps might look like this:

從中級目標開始，然后將每個步驟具體化。例如，如果目標是發布新的開源Web應用程序，則步驟可能如下所示：

Complete app JavaScript

完整的應用JavaScript

Create front end and stylesheet

創建前端和樣式表

Do local tests

做本地測試

Set up cloud server

設置云服務器

Deploy app to cloud

將應用程序部署到云

Do tests

做測試

Add repository to GitHub

將存儲庫添加到GitHub

Post on Hacker News

在黑客新聞上發布

Profit!!!

利潤！！！

Each of the above examples encapsulates many smaller, low-level goals — we can think of these as our to-do list items. For example, “Set up cloud server” might involve:

上面的每個示例都封裝了許多較小的低級目標-我們可以將它們視為待辦事項。例如，“設置云服務器”可能涉及：

Research cloud providers

研究云提供商

Decide on service and sign up

確定服務并注冊

Set up server/instance

設置服務器/實例

Add integrations

添加集成

Test deployment

測試部署

Our parameters for chunk sizes and what constitutes a “step” may be different from one another, and will likely change from project to project. If your mid-level and low-level steps clearly define a concrete path for achieving the top-level goals you set, then you’re in good shape. Later on, evaluating the decision process that brought us to these mid-level and low-level goals enables us to bring our feedback loop full circle.

我們關于塊大小和構成“步驟”的參數可能彼此不同，并且可能因項目而異。如果您的中級和低級步驟明確定義了實現您設定的最高目標的具體路徑，那么您就處于良好狀態。稍后，評估將我們帶到這些中級和低級目標的決策過程，使我們能夠將反饋循環帶入一個完整的圈子。

自動化您的工作 (Automate your work)

I recently read a great article entitled Manual Work is a Bug. It discusses a process by which successful developers document and eventually automate their work. The beauty of this idea is in its simplicity. By writing down the things we do manually, we’re able to correct and refine our processes. By refining our processes, we can more easily translate them into code snippets and scripts. With a collection of scripts that we can string together, we can automate our work.

我最近讀了一篇很棒的文章，標題為“ 手工工作是一個錯誤” 。它討論了成功的開發人員記錄并最終使他們的工作自動化的過程。這個想法的優點在于其簡單性。通過寫下我們手動執行的操作，我們可以糾正和完善我們的流程。通過完善我們的流程，我們可以更輕松地將它們轉換為代碼段和腳本。有了我們可以串在一起的腳本集合，我們可以使我們的工作自動化。

Automating work isn’t only about saving time. It reduces haven’t-had-my-coffee-yet errors, minimizes cognitive load allowing more room for creativity, and allows our processes to be repeatable across collaborators and projects. It help shorten our feedback loop by ensuring we aren’t doing the same thing three times in three different ways.

自動化工作不僅僅是節省時間。它可以減少尚未發生的咖啡錯誤，最大程度地減少認知負擔，為創造力留出更多空間，并使我們的流程在合作者和項目之間可重復。通過確保我們不會以三種不同的方式進行三次相同的操作，這有助于縮短反饋循環。

We can begin to automate by starting our own personal wiki. If we build a habit of writing down every manual thing we do, no matter how basic it may seem at the time, we give ourselves more opportunities to spot patterns, and thus possible integrations and improvements.

我們可以通過啟動自己的個人Wiki開始自動化。如果我們養成寫下我們所做的每項手動操作的習慣，無論當時看起來多么基礎，我們都會給自己更多的機會來發現模式，從而可能進行集成和改進。

The first time we do something manually, we write out the steps. The second time, we follow the steps. This gives us the opportunity to correct and refine them based on what we’ve learned since the first time.

第一次手動執行操作時，我們會寫出步驟。第二次，我們按照步驟進行。這使我們有機會根據自第一次以來所學到的知識對它們進行校正和改進。

Over successive iterations, we might replace parts of manual commands with variables. We might find handy snippets of bash scripts that automate just a part of our task. As long as we keep revising and improving our personal wiki, we’re moving towards automation.

在連續的迭代中，我們可能會用變量替換部分手動命令。我們可能會發現一些方便的bash腳本片段，這些片段可以使我們的任務自動化。只要我們不斷修訂和改進我們的個人Wiki，我們就會朝著自動化邁進。

抽出時間進行代碼審查 (Block out time for code review)

It’s all too easy to commit messy code when we work alone. We think, who’s going to see it? I’ll fix it later. Each time that happens, though, we’re building a habit. It’s a bad one.

當我們獨自工作時，提交凌亂的代碼太容易了。我們認為，誰會看到它？稍后再解決。但是，每次發生這種情況時，我們都會養成一種習慣。真不好

Working alone means there’s no one likely to give feedback on our commits when we’re doing something that doesn’t make sense, or that could be improved. Instead, we have to actively seek out opportunities to improve. Open source communities are amazing for this. There’s a wealth of information available to us in terms of coding styles, examples of refactored code, and a smorgasbord of snippets that achieve that-thing-we-were-trying-to-do but in fewer lines. We can learn all we please, if we just block out the time to do it.

獨自工作意味著當我們做的事情沒有意義或可以改善時，就不可能有人就我們的承諾提供反饋。相反，我們必須積極尋找改善的機會。開源社區對此非常了不起。就編碼樣式，重構代碼示例以及一小段代碼片段而言，我們可以獲得大量信息，這些代碼片段可以實現我們想要嘗試的事情，但是行數卻更少。如果我們花時間去做，我們可以學到所有我們喜歡的東西。

Schedule your own code review at a time that makes sense for you and the project you’re working on. This might be each time you finish a fix or feature, or at regular intervals daily or weekly. If you have someone who can help, book them. There are also chatrooms full of people happy to lend a hand.

在您和您正在從事的項目有意義的時間安排您自己的代碼審查。這可能是您每次完成修復或功能時，或者是每天或每周定期進行。如果您有可以幫助的人，請給他們預訂。也有很多人樂于助人的聊天室。

Do some research on basic best practices for what you’re working on. Set yourself a time limit though, and take what you read with a grain of salt. There’s a lot of rabbit holes in that field. As a starting point, I’d recommend learning about DRY code, and watching Uncle Bob demand professionalism in software development.

對您正在研究的基本最佳實踐進行一些研究。但是給自己設定一個時間限制，并帶著一丁點鹽來閱讀。這個領域有很多兔子洞。首先，我建議您學習DRY代碼，并觀看Bob叔叔要求軟件開發方面的專業知識。

代碼審查清單 (Code review checklist)

Here’s my personal code review checklist, based off some general best practices. Feel free to use it as a starting point for your own!

這是基于一些常規最佳實踐的個人代碼檢查清單。隨意使用它作為您自己的起點！

Victoria’s Code Review Extravaganza!

維多利亞州的代碼審查盛會！

- [ ] This solves a high-priority item.

-[]解決高優先級項目。

- [ ] This solves a high-priority item. - [ ] This is a complete implementation that follows the specification.

-[]解決高優先級項目。 -[]這是遵循規范的完整實現。

- [ ] This solves a high-priority item. - [ ] This is a complete implementation that follows the specification. - [ ] Off-topic changes were not included and have been added to backlog.

-[]解決高優先級項目。 -[]這是遵循規范的完整實現。 -[]主題外的更改未包括在內，已添加到積壓中。

-[]解決高優先級項目。 -[]這是遵循規范的完整實現。 -[]主題外的更改未包括在內，已添加到積壓中。 -[]變量名有意義，沒有幻數。

-[]解決高優先級項目。 -[]這是遵循規范的完整實現。 -[]主題外的更改未包括在內，已添加到積壓中。 -[]變量名有意義，沒有幻數。 -[]每次機會都會返回正確且有用的錯誤消息。

-[]解決高優先級項目。 -[]這是遵循規范的完整實現。 -[]主題外的更改未包括在內，已添加到積壓中。 -[]變量名有意義，沒有幻數。 -[]每次機會都會返回正確且有用的錯誤消息。 -[]沒有留下任何調試打印語句。

-[]解決高優先級項目。 -[]這是遵循規范的完整實現。 -[]主題外的更改未包括在內，已添加到積壓中。 -[]變量名有意義，沒有幻數。 -[]每次機會都會返回正確且有用的錯誤消息。 -[]沒有留下任何調試打印語句。-[]該代碼是DRY且模塊化的。

-[]解決高優先級項目。 -[]這是遵循規范的完整實現。 -[]主題外的更改未包括在內，已添加到積壓中。 -[]變量名有意義，沒有幻數。 -[]每次機會都會返回正確且有用的錯誤消息。 -[]沒有留下任何調試打印語句。-[]該代碼是DRY且模塊化的。 -[]此代碼是安全的。私人代碼和公共代碼分開很好。

- [ ] This solves a high-priority item. - [ ] This is a complete implementation that follows the specification. - [ ] Off-topic changes were not included and have been added to backlog. - [ ] Variable names are meaningful and there are no magic numbers. - [ ] Correct and useful error messages are returned at every opportunity. - [ ] No debugging print statements were left in. - [ ] This code is DRY and modular. - [ ] This code is secure. Private and public code are well separated. - [ ] This code is its own documentation, or the documentation is up to date. - [ ] A five-year-old could follow this, seriously it’s that readable. - [ ] Unit tests successfully pass. - [ ] Master was merged into the branch and tested.

-[]解決高優先級項目。 -[]這是遵循規范的完整實現。 -[]主題外的更改未包括在內，已添加到積壓中。 -[]變量名有意義，沒有幻數。 -[]每次機會都會返回正確且有用的錯誤消息。 -[]沒有留下任何調試打印語句。-[]該代碼是DRY且模塊化的。 -[]此代碼是安全的。私人代碼和公共代碼分開很好。 -[]該代碼是其自己的文檔，或者該文檔是最新的。 -[] 5歲的孩子可以遵循此規則，這很容易閱讀。 -[]單元測試成功通過。 -[]母版合并到分支中并進行了測試。

- [ ] I actually verified that it actually does what I said it does.

- []我實際上驗證了它確實按照我說的做。

Here is an excellent example of cleaning up code with some of the above points in mind.

考慮到上述幾點，這是清理代碼的一個很好的例子。

浪費時間進行流程審查 (Block out time for process review)

Just as we learn from reviewing our code, we refine our processes by reviewing them as well. Process review is most beneficial when visited at regular intervals throughout the project, not just after the project’s completion.

正如我們從檢查代碼中學到的一樣，我們也通過檢查代碼來完善流程。在整個項目中(而不是在項目完成之后)定期進行過程檢查時，過程審核最為有益。

For short-term projects, a good starting point for scheduling process reviews is at each half-mark — once midway through, and again after completion. Long-term projects may have reviews at each quarter-mark.

對于短期項目，安排流程審查的一個好的起點是在每個半關處-一次進行到中途，然后在完成后再一次。長期項目可能在每個季度標記都有審核。

處理復習題 (Process review questions)

Process review can be as simple as a short list of questions:

流程審查可以像一小段問題一樣簡單：

What were my top-level goals for this period? Did I meet them?

在此期間，我的最高目標是什么？我見過他們嗎？

What were my mid-level and low-level goals for this period? Did I meet them?

在此期間，我的中級和低級目標是什么？我見過他們嗎？

Would I have been better served with different or more specific goals? Why?

在不同的或更具體的目標上我能得到更好的服務嗎？為什么？

Did I successfully remove or automate obstacles?

我是否成功消除或自動化障礙？

Did I stick to my code review schedule? Why or why not?

我遵守代碼審查時間表了嗎？為什么或者為什么不？

How might I remove obstacles next time?

下次如何清除障礙物？

Setting aside dedicated time for our process review can help us to answer questions like these thoughtfully and honestly. This allows us to squeeze out every bit of learning we can from our review, helping to shorten our feedback loop.

留出時間進行流程審查可以幫助我們周到而誠實地回答諸如此類的問題。這樣一來，我們就可以從審查中吸取教訓，從而縮短反饋周期。

用評論結果更新您的目標和流程 (Update your goals and processes with the results of your reviews)

All the performance data in the world is no good to us if we don’t put it into practice. With each successive code review, we can refine and add to our checklist. With what we learn from each process review, we can fine tune and improve our processes. The more we can invent concrete and observable ways to implement our learning, the more success we’ll have.

如果我們不付諸實踐，世界上所有的性能數據對我們都是不利的。每次進行后續代碼審查時，我們都可以優化并添加到清單中。借助從每次流程審核中學到的知識，我們可以調整和改進流程。我們越能發明出具體且可觀察的方法來實施我們的學習，我們就會獲得更大的成功。

Making a conscious effort to utilize and practice the things we’ve learned is the final, vital, component of our feedback loop. The more often we incorporate new learning, the shorter our loop becomes, allowing us to improve that much faster.

做出有意識的努力來利用和實踐我們所學到的東西是反饋循環的最后，至關重要的組成部分。我們學習新知識的次數越多，循環就越短，從而使我們可以更快地改進它。

翻譯自: https://www.freecodecamp.org/news/how-to-set-up-a-short-feedback-loop-as-a-solo-coder-67709cba21e0/