vsc 搜索特定代碼

by Rina Artstain

通過麗娜·阿斯特斯坦

特定問題的通用解決方案：何時編寫代碼以及何時編寫代碼 (Generic solutions to specific problems: when to write some code and when to just do it)

There is a traditional story that tells of a rabbi who comes upon a guy sitting next to a fork in the road. The rabbi asks the guy which way is best to get to the city, and the guy answers: That one is a short road which is long, and the other is a long road which is short. The rabbi chooses the short road, but soon arrives at a field full of thorns which he can’t get through, and must turn back and take the other road, which actually leads him to the city.

有一個傳統的故事，講述一個拉比碰到一個坐在路邊叉子旁邊的家伙。 拉比問那家伙哪條路最好去城市，那家伙回答：那一條是一條很長的短路，另一條是一條很短的長路。 拉比選擇了一條短路，但很快到達一個布滿荊棘的田野，他無法穿越，必須回頭走另一條路，這實際上將他引向了城市。

The moral of the story, other than wondering if this guy was the first troll in history, is that sometimes trying to take a short cut will end up being longer than just doing it the long way.

除了想知道這個家伙是否是歷史上第一個巨魔之外，這個故事的寓意在于，有時嘗試捷徑最終會比長途跋涉更長。

編碼很長的路(很短) (Coding the Long Way (which is Short))

If you’re specifically writing an API or a library for internal or external use, you know that it should be as generic as possible. You want it to be clear, concise and easy to use, while still giving your users a lot of flexibility. There are trade-offs between those goals, but you’ll figure them out.

如果您專門編寫供內部或外部使用的API或庫，那么您應該知道它應該盡可能通用。 您希望它清晰，簡潔且易于使用，同時仍為您的用戶提供很大的靈活性。 在這些目標之間需要權衡取舍，但是您會找到答案。

But what happens when you’re given a specific task to complete, and you can either just do it, or write some infrastructure which will make just doing it easier in the future?

但是，當您被賦予要完成的特定任務，而您既可以做到這一點，又可以編寫一些基礎架構來簡化將來的工作時，會發生什么？

Should you get the task done as quickly as possible or spend the time to build some infrastructure which will make future tasks easier to complete?

您應該盡快完成任務還是花時間建立一些基礎設施，使將來的任務更容易完成？

Should you choose the short road which might turn out to be long, or the long road which will actually help you hit your target sooner?

您應該選擇一條可能會很長的短路，還是選擇一條實際上會幫助您更快地達到目標的長路？

一個例子(基于真實的故事) (An example (based on a true story))

(Some of the details have been changed or omitted for simplicity, and, well, better story telling. Reality is much too messy.)

(為簡單起見，其中一些細節已更改或省略，并且更好的講故事。現實實在太混亂了。)

One day, my boss comes up to me and asks me to quickly get some data from the DB and send it to him as an excel sheet. It wasn’t too complicated, so I did it right away.

有一天，我的老板來找我，要求我快速從數據庫中獲取一些數據，并將其作為excel表發送給他。 它并不太復雜，所以我馬上就做到了。

The next day he asks for the same data again, with different dates. He thinks for a bit and says, well — maybe you should just put this report up on the web. I’d like to be able to access this data any time and choose the dates myself.

第二天，他再次要求提供相同的數據，但日期不同。 他思考了一會兒，然后說，很好–也許您應該將這份報告發布到網絡上。 我希望能夠隨時訪問此數據并自己選擇日期。

No problem! Here you go, some front-end, some back-end, deploy. Wait. Wait. Wait. Deployment done, and the report is online.

沒問題！ 在這里，您可以進行一些前端，某些后端的部署。 等待。 等待。 等待。 部署完成，報告處于聯機狀態。

A couple of days go by, and I’m asked for another quick report, and “do it with that nice interface and date filters you gave us last time”. OK, sure. No problem. Front-end, back-end, deploy, wait, online.

過了幾天，我被要求提供另一份快速報告，并“使用您上次給我們的漂亮界面和日期過濾器進行操作”。 是當然。 沒問題。 前端，后端，部署，等待，在線。

Next time I got a similar request I said: “Look, it will take me half a day to write this report, but if you give me two days, I can build some infrastructure which will allow me to define a query in the DB, add some configuration, and your report will be live without having to wait for deployment”. My request was approved.

下次收到類似的請求時，我說：“看，我將花半天時間編寫這份報告，但是如果您給我兩天的時間，我可以構建一些基礎結構，使我可以在數據庫中定義查詢，添加一些配置，您的報告將立即生效，而無需等待部署。” 我的請求被批準。

這是我過去兩天的工作： (Here’s what I did with my two days:)

I defined a convention for a “report” stored procedure, which expected to get the following parameters:

我為“報告”存儲過程定義了一個約定，該約定應獲取以下參數：

• From Date
  從日期
• To Date
  至今
• Start At Index (for paging)
  從索引開始(用于分頁)

Each procedure returned a result set for the query, and the Total Result Count (for paging).

每個過程都返回查詢的結果集和總結果計數(用于分頁)。

In addition, I added a Reports table which held:

另外，我添加了一個Reports表，其中包含：

• Stored Procedure Name (to execute)
  存儲過程名稱(執行)
• Title (of the report)
  (報告的)標題
• Description (to be displayed on the report page)
  說明(將顯示在報告頁面上)

I also added an endpoint on the server, UI, and some logic to:

我還在服務器，UI和一些邏輯上添加了一個端點：

• Check the DB for reports and add them to the site navigation.
  檢查數據庫中的報告，并將其添加到站點導航中。
• When a report was accessed, execute the matching stored procedure and return the result to the UI.
  訪問報告后，執行匹配的存儲過程并將結果返回到UI。
• Display two date pickers for selecting From Date and End Date and executing the query.
  顯示兩個日期選擇器，以選擇“從日期”和“結束日期”并執行查詢。
• A generic table to display the results formatted according to the data type of each column. (I already had a generic UI component for paging, yay me!)
  通用表，用于顯示根據每一列的數據類型格式化的結果。 (我已經有一個通用的UI組件用于分頁，是的！)

When I was done, I could add a stored procedure and an entry in the DB and the report would automagically appear on our site.

完成后，我可以在數據庫中添加一個存儲過程和一個條目，該報告將自動顯示在我們的站點上。

唯一不變的是變化 (The Only Constant is Change)

Everyone was happy and super excited about my time saving report feature, but… What about sorting? And could we have the first column link to the customer’s profile? And could we maybe add filtering by the sales rep responsible for that customer?

每個人都對我的省時報告功能感到高興和興奮，但是……排序又如何呢？ 我們能否將第一列鏈接到客戶的個人資料？ 我們是否可以添加負責該客戶的銷售代表進行過濾的功能？

Yeah! Sure. That makes a lot of sense. So I added:

是的 當然。 這很有意義。 所以我補充說：

• Optional Sort By and Sort Direction parameters to the Stored Procedures.
  存儲過程的可選“排序依據”和“排序方向”參數。
• A flag for specifying if the first column should link to the customer’s profile.
  用于指定第一列是否應鏈接到客戶的個人資料的標志。
• Another flag for specifying if the query included filtering by sales rep.
  用于指定查詢是否包括按銷售代表過濾的另一個標志。
• And a few UI/logic changes to support displaying/executing these new requirements.
  以及一些UI /邏輯更改，以支持顯示/執行這些新要求。

Happy happy, joy joy. But… How about grouping the results? And when you click the row could you have an email sent to a group of predefined users? And when a sales rep enters the report, could you have the report displayed in their favorite color? (OK, I made that last one up)

快樂快樂，快樂快樂。 但是……如何將結果分組？ 當您單擊該行時，是否可以將電子郵件發送給一組預定義的用戶？ 當銷售代表輸入報告時，可以用他們喜歡的顏色顯示報告嗎？ (好的，我把最后一個弄了)

稍安毋躁 (Hold your Horses)

At this point, I had to stop and think which features should be implemented as part of my generic solution, and which should be developed as a stand-alone solution.

在這一點上，我不得不停下來想一想，哪些功能應作為通用解決方案的一部分實施，哪些功能應作為獨立的解決方案開發。

It was obvious to me that specific custom actions which don’t depend on the actual data returned from the query (like sending an email to certain predefined users) was out of the question.

對我來說很明顯，不依賴于查詢返回的實際數據的特定自定義操作(例如向某些預定義的用戶發送電子郵件)是不可能的。

I also thought that uncommon actions which depend on the data returned by the query shouldn’t be added to the generic report infrastructure. So, filter by sales rep — sure, why not. Link to customer — OK, common scenario. But other actions which are very specific to a single report — nope.

我還認為，不應將依賴于查詢返回的數據的不常見操作添加到通用報表基礎結構中。 因此，按銷售代表過濾-當然，為什么不呢？ 鏈接到客戶-好的，常見的情況。 但是其他針對單個報告的特定操作-不。

The grouping requirement posed more of a challenge: Grouping is a common and extremely useful scenario. Should I add it to my infrastructure or not?

分組要求帶來了更大的挑戰：分組是一種常見且極為有用的方案。 是否應該將其添加到我的基礎架構中？

Well, what would grouping the results require?

那么，將結果分組需要什么？

• Adding a Group By flag to the report’s DB entry, to let the logic know to expect two distinct result sets — group header and group details.
  在報表的DB條目中添加一個Group By標志，以使邏輯知道期望兩個不同的結果集-組標題和組詳細信息。
• The logic would also have to know how to match the group to the details, and it would have to be done by convention. Extremely risky business.
  邏輯還必須知道如何使組與細節匹配，并且必須按照慣例完成。 極具風險的業務。
• Figuring out how to generically sort results with a group header. I can’t even.
  弄清楚如何使用組頭對結果進行一般排序。 我什至不能
• And probably some other issues I haven’t thought of.
  可能還有其他我沒想到的問題。

代碼未寫 (The Code Not Written)

I didn’t add grouping.

我沒有添加分組。

In retrospect, putting about a week of effort total into this reports feature saved me hundreds of hours developing reports later on. I also managed to avoid the pitfall of trying to be too generic and supporting too much extraneous stuff, which would have hurt the system’s stability in the long run.

回顧一下，在此報告功能中投入了大約一周的時間，使我以后節省了數百小時的報告開發時間。 我還設法避免了過于通用和支持過多無關內容的陷阱，這從長遠來看會損害系統的穩定性。

But really, I shouldn’t have written a single line of code. I should have looked into a reporting tool.

但實際上，我不應該編寫任何代碼。 我應該研究一下報告工具。

However, there are other generic helper systems which I wrote which were a good investment and should have been written. For example, a library of helpers which create HTML elements with predictable ids and classes tailored to our data models and UI requirements.

但是，我編寫了其他通用幫助程序系統，這是不錯的投資， 應該編寫。 例如，一個幫助程序庫可創建HTML元素，這些HTML元素具有針對我們的數據模型和UI要求量身定制的可預測ID和類。

怎么辦？ (Now What?)

So how should you decide whether to write some infrastructure or just do it? Here’s how I decide:

那么，您應該如何決定是編寫某些基礎架構還是僅僅是編寫基礎架構？ 這是我的決定方式：

• Is it a rote task? If it’s boring and recurring, if you find yourself copy-pasting a whole lot of code often — check if you can generalize what you’re doing and build some code to do it for you.
  死記硬背嗎？ 如果這很無聊且經常發生，如果您發現自己經常復制粘貼很多代碼，請檢查您是否可以概括您正在做的事情并構建一些代碼來幫助您。
• How long will building the infrastructure take? If you can build the infrastructure in 5 minutes and each task would have taken you 5 days, it’s an easy answer. If building the infrastructure would take a year and each task would take 5 minutes — don’t build it. But it’s usually not that clear cut. Try to estimate as best you can, try to keep it simple, and be prepared to cut your losses if it takes too long.
  基礎設施建設需要多長時間？ 如果您可以在5分鐘內構建基礎架構，而每個任務將花費您5天的時間，這是一個簡單的答案。 如果構建基礎架構需要花費一年，而每個任務都需要5分鐘-那就不要構建它。 但這通常不是那么明確。 盡力估計盡可能多，盡量簡化，如果準備時間太長，準備減少損失。
• Do not add specific implementations to your generic solution. If it doesn’t fit, don’t try to force it. You’ll end up ruining your infrastructure and getting a mediocre result for the task you were actually trying to complete.
  不要將特定的實現添加到您的通用解決方案。 如果不合適，請不要強行使用。 您最終將破壞基礎架構，并為您實際上要完成的任務獲得平庸的結果。

• But first, please check if there is ready made solution to your problem.

  但是首先， 請檢查是否有針對您問題的現成解決方案。

Like what you read? Share the love by clapping. Have a question or comment? Let me know in the comments section.

喜歡你讀的書嗎？ 通過鼓掌分享愛。 有問題或意見嗎？ 讓我知道在評論部分。

翻譯自: https://www.freecodecamp.org/news/generic-solutions-to-specific-problems-2562fbd37a5a/

vsc 搜索特定代碼

總結

以上是生活随笔為你收集整理的vsc 搜索特定代码_特定问题的通用解决方案：何时编写代码以及何时编写代码...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。