임시 솔루션이 영원히 지속되는 것을 어떻게 막습니까?

임시 솔루션이 영원히 지속되는 것을 어떻게 막습니까?

---

문제에 대한 두 가지 가능한 해결책이 있다고 가정 해 봅시다. 첫 번째는 빠르지 만 해키입니다. 두 번째가 바람직하지만 구현하는 데 더 오래 걸립니다. 문제를 신속하게 해결해야하므로 가능한 한 빨리 해킹을 설치하고 나중에 더 나은 솔루션에 대한 작업을 시작할 계획입니다. 문제는 문제가 해결 되 자마자 할 일 목록이 급락한다는 것입니다. 어느 시점에서 더 나은 솔루션을 넣을 계획이지만 지금 구현하는 것을 정당화하기는 어렵습니다. 갑자기 완벽하지 않은 솔루션을 사용하여 5 년을 보냈고 그동안 저주를 받았습니다.

익숙한 것 같습니까? 내가 일하는 곳에서 한 번 이상 일어났다는 것을 알고 있습니다. 한 동료는 의도적으로 잘못된 GUI를 만들어 실수로 장기적으로 채택되지 않도록 설명합니다. 더 나은 전략이 있습니까?

---

해킹이 실패한 테스트 케이스를 작성하십시오.

해킹이 실패한 테스트를 작성할 수 없다면 결국 해킹에 문제가없는 것입니다. 그렇지 않으면 테스트 프레임 워크가 부적절합니다. 전자의 경우 불필요한 최적화에 인생을 낭비하기 전에 빨리 달아나십시오. 후자의 경우 다른 접근 방식을 찾으십시오 (핵 신고 또는 테스트 ...)

---

전략 1 (거의 선택되지 않음) : kluge를 구현하지 마십시오. 사람들에게 가능성을 알리지 마십시오. 처음에는 올바른 방식으로 수행하십시오. 내가 말했듯이 이것은 시간 제약으로 인해 거의 선택되지 않았습니다.

전략 2 (부정직) : 거짓말과 속임수. 경영진에게 해킹에 버그가 있으며 나중에 큰 문제를 일으킬 수 있다고 말합니다. 불행히도 대부분의 경우 관리자는 버그가 문제가 될 때까지 기다린 다음 버그를 수정하라고 말합니다.

전략 2a : 실제로 버그가 있다는 점을 제외하면 전략 2와 동일합니다. 그래도 같은 문제입니다.

전략 3 (그리고 개인적으로 가장 좋아하는) : 가능할 때마다 솔루션을 설계하고 인턴이나 코드 원숭이가 할 수있을만큼 충분히 잘 수행하십시오. 자신의 급여를 정당화하는 것보다 적은 양의 코드 원숭이 돈을 지출하는 것을 정당화하는 것이 더 쉽기 때문에 그냥 끝낼 수도 있습니다.

전략 4 : 재 작성을 기다립니다. 계속 기다리십시오. 조만간 (아마 나중에) 누군가가 그 일을 다시 작성해야 할 것입니다. 그때 바로 할 수있을 것입니다.

---

다음은 기술적 부채 에 대한 훌륭한 관련 기사입니다 .

기본적으로 그것은 당신이 내리는 모든 기술적 결정과 부채의 비유입니다. 좋은 부채와 나쁜 부채가 있습니다. 그리고 최소한의 장기적인 비용으로 원하는 목표를 달성 할 부채를 선택해야합니다.

최악의 빚은 신용 카드 빚과 유사한 작은 누적 지름길입니다. 각각은 다 치지 않지만 곧 가난한 집에있게됩니다.

---

이것은 마감일 중심의 작업을 할 때 중요한 문제입니다. 이 방법을 선택한 이유에 대한 자세한 설명과 코드 작성 방법에 대한 힌트를 추가하면 도움이됩니다. 이렇게하면 코드를 보는 사람들이 코드를보고 최신 상태로 유지할 수 있습니다.

작동 할 또 다른 옵션은 재 작업을 자세히 설명하는 추적 프레임 워크에 bug.feature를 추가하는 것입니다. 그렇게하면 볼 수 있고 어느 시점에서 문제가 발생할 수 있습니다.

---

이러한 문제를 수정하는 것을 정당화 할 수있는 유일한 경우 (실제로 손상되지 않았기 때문에 추악하기 때문)는 동일한 코드 섹션에 영향을주는 또 다른 기능이나 버그 수정이 있고이를 다시 작성하는 것이 좋습니다.

개발자의 시간 비용에 대해 계산해야합니다. 소프트웨어 요구 사항이 충족되고 있고 유일한 잘못된 것은 코드가 내부적으로 부끄럽다는 것입니다. 실제로 수정할 가치가 없습니다.

열성적인 엔지니어가 불안 해지면 매년 재건축을 고집하기 때문에 기업 전체가 사업을 중단 할 수 있습니다.

버그가없고 요구 사항을 충족하면 완료된 것입니다. 그것을 발송하십시오. 움직여.

[편집하다]

물론 모든 것이 항상 해킹 당한다고 주장하는 것은 아닙니다. 개발 과정의 정상적인 과정에서 신중하게 코드를 설계하고 작성해야합니다. 그러나 신속하게 처리해야하는 해킹이 발생하면 코드를 정리할 가치가 있는지 여부에 대한 비용-편익 분석을 수행해야합니다. 응용 프로그램의 수명 동안 문제를 해결하는 것보다 복잡한 해킹을 코딩하는 데 더 많은 시간을 할애한다면 당연히 고쳐야합니다. 그러나 그렇지 않은 경우 소스를 보면 질병이 발생하기 때문에 버그가없는 작동하는 애플리케이션 을 다시 코딩하는 것은 너무 비싸고 위험합니다 .

---

중간 솔루션을 수행하지 마십시오.

가끔은 프로그래머에게이 말만하면된다고 생각합니다.

죄송하지만 심각하게 해키 솔루션은 쓸모가 없으며 첫 번째 반복에서도 솔루션의 일부를 올바르게 수행하는 것보다 더 오래 걸릴 수 있습니다.

유지 관리를 위해 쓰레기 코드를 남기지 마십시오. 항상 올바르게 코딩하십시오. 얼마나 오래 걸리고 누가 당신에게 소리를 지르 든 상관 없습니다.

다른 사람들이 어리석은 해킹을 디버깅하는 동안 일찍 배달 한 후 엄지 손가락을 빙빙 돌리면서 거기 앉아 있으면 나에게 감사 할 것입니다.

자신이 훌륭한 프로그래머라고 생각하지 않더라도 항상 최선을 다하기 위해 노력하고 지름길을 사용하지 마십시오. 올바르게 수행하는 데 시간이 걸리지 않습니다. 당신이 나를 믿지 않는다면이 진술을 정당화 할 수 있습니다.

---

갑자기 완벽하지 않은 솔루션을 사용하여 5 년을 보냈고 그동안 저주를 받았습니다.

저주하는 경우 TODO 목록 맨 아래에있는 이유는 무엇입니까?

• 당신에게 영향을주지 않는다면 왜 저주를하는 거죠?
• 그것이 당신에게 영향을 미치고 있다면, 지금 해결해야 할 문제입니다.

---

• 나는 단기 수정이 들어간 후에 특히 장기 수정의 우선 순위에 대해 목소리를 낸다.
• 나는 그것이 해킹이고 장기적인 해결책이 아닌 이유를 자세히 설명하고 이해 관계자 (관리자, 클라이언트 등)가 왜 수정해야하는지 이해하도록하는 데 사용합니다.
• 경우에 따라 최악의 시나리오에 대한 두려움을 약간 주입 할 수도 있습니다. "안전하게 선이 끊어지면 다리 전체가 무너질 수 있습니다!"
• 나는 장기적인 솔루션을 내놓을 책임을지고 그것이 배포되었는지 확인합니다.

---

힘든 전화입니다. 가끔 당신이 완료 해킹 개인적 원인이 가질 문 밖으로 고객의 손에 해당 제품을 얻을 수 있습니다. 하지만 내가 처리하는 방법은 그냥하는 것입니다.

프로젝트 책임자 나 상사 또는 고객에게 다음과 같이 말합니다. 정리하고 더 잘 코딩해야 할 부분이 있습니다. 나는 그것을하기 위해 일주일이 필요하고 지금 그것을하기 위해 더 적은 비용이들 것이다. 그러면 우리가 서브 시스템에 확장을 구현해야 할 때 지금부터 6 개월 후에 그것을 할 것이다.

---

일반적으로 이와 같은 문제는 경영진 또는 고객과의 잘못된 의사 소통으로 인해 발생합니다. 솔루션이 고객에게 효과가있는 경우 변경을 요청할 이유가 없습니다. 따라서 빠른 솔루션을 구현 한 후 문제를 해결하기 위해 추가 시간을 계획 할 수 있도록 미리 만든 트레이드 오프에 대해 알려야합니다.

그것을 해결하는 방법은 그것이 왜 나쁜 해결책인지에 달려 있습니다. 변경 또는 유지 관리가 어렵 기 때문에 솔루션이 나쁘면 처음에 유지 관리를 수행하고 시간이 조금 더 있으면 더 나은 솔루션으로 업그레이드 할 수있는 적절한시기입니다. 이 경우 고객이나 상사에게 처음부터 지름길을 택했다고 말하면 도움이됩니다. 그렇게하면 다음 번에 빠른 솔루션을 기대할 수 없다는 것을 알 수 있습니다. UI를 깨우는 것은 고객이 문제를 해결하기 위해 다시 방문하도록하는 좋은 방법입니다.

위험하거나 불안정하여 해결책이 나쁘면 계획을 수행하는 사람과 이야기하고 최대한 빨리 문제를 해결할 수있는 시간을 마련해야합니다.

---

행운을 빕니다. 내 경험상 이것은 거의 불가능합니다.

압박을 받고 있기 때문에 해킹을 구현하는 미끄러운 슬로프를 내려 가면 항상 그것에 익숙해 질 수 있습니다. 내부적으로 아무리 나쁘게 구현 되더라도 이미 작동하는 것을 재 작업 할 시간은 거의 없습니다. "나중에"해킹을 고칠 시간이 마법처럼 더 많을 것이라고 생각하는 이유는 무엇입니까?

이 규칙에 대해 제가 생각할 수있는 유일한 예외는 해킹으로 인해 고객이 필요로하는 다른 기능을 구현하지 못하는 경우입니다. 그러면 재 작업을 할 수밖에 없습니다.

---

저는 해키 솔루션을 구축하여 가능한 한 고통없이 장기적으로 마이그레이션 할 수 있도록 노력합니다. 가장 강력한 DB 인 SQL Server에서 데이터베이스를 구축하는 사람이 있지만 기업 표준은 Oracle입니다. 전송 불가능한 기능 (예 : Bit 데이터 유형)을 가능한 한 적게 사용하여 db를 빌드하십시오. 이 예에서는 비트 유형을 피하는 것이 어렵지 않지만 나중에 전환하는 것이 더 쉬워집니다.

---

장기적으로 해키 방식이 나쁜 이유를 최종 결정을 담당하는 사람에게 교육하십시오.

• 관련 될 수있는 용어로 문제를 설명하십시오.
• 비용, 생산성 및 수익 곡선의 그래프를 포함합니다.
• 그들에게 기술적 부채 에 대해 가르쳐주십시오 .
• 앞으로 나아갈 경우 정기적으로 리팩토링하십시오.
• 비 기술적 인 사람들 앞에서 "리팩토링"또는 "돌아가서 정리"라고 부르지 마십시오. 대신 "새로운 기능"을 처리하도록 시스템을 "적응"이라고합니다.

기본적으로 소프트웨어를 이해하지 못하는 사람들은 이미 작동하는 것을 다시 살펴 보는 개념을 이해하지 못합니다. 그들이 보는 방식에서 개발자는 누군가가 기능을 추가하고 싶을 때마다 전체 자동차를 분해하고 재 조립하려는 기계공과 같습니다.

일상적인 것들을 비유하는 데 도움이됩니다. 중간 해결책을 만들었을 때 어떻게 안정적이고 유지 보수가 용이 한 것이 아니라 신속하게 건축하는 데 적합한 선택을했는지 설명하십시오. 목재는 절단하기 쉽기 때문에 강철 대신 목재로 건축하는 것과 같습니다. 임시 솔루션을 더 빨리 구축 할 수 있습니다. 그러나 나무는 단순히 20 층 건물의 기초를 지탱할 수 없습니다.

---

지속적인 통합을 위해 Java와 Hudson을 사용합니다. '임시 솔루션'에는 다음과 같이 주석을 달아야합니다.

// TODO: Better solution required.

Hudson이 빌드를 실행할 때마다 각 TODO 항목에 대한 보고서를 제공 하므로 개선이 필요한 모든 미해결 항목에 대한 최신 기록을 확인할 수 있습니다.

---

좋은 질문입니다. 이것도 저를 많이 괴롭 힙니다. 대부분의 경우 제 프로젝트 (예, 소규모 기업)에서 문제의 우선 순위를 정하는 유일한 사람입니다.

수정해야하는 문제는 일반적으로 문제의 일부에 불과하다는 것을 알았습니다. 긴급 수정이 필요한 고객 인 IOW는 전체 문제를 해결하는 데 필요한 것이 아니라 그 일부만 해결할 필요가 있습니다. 이를 통해 전체 문제에 대한 해결책이 아니라 고객의 하위 집합에 대한 해결 방법을 만들 수 있으며 더 큰 문제를 문제 추적기에서 열어 둘 수 있습니다.

물론 작업 환경에 전혀 적용되지 않을 수도 있습니다.

---

This reminds me of the story of "CTool". In the beginning CTool was put forward by one of our devs, I'll call him Don, as one possible way to solve the problem we were having. Being an earnest hard-working type, Don plugged away and delivered a working prototype. You know where I am going with this. Overnight, CTool became a part of the company work flow with an entire department depending on it. By the second or third day, bitter complaints started streaming in about CTool's shortcomings. Users questioned Don's competence, commitment and IQ. Don's protests that this was never supposed to be a production app fell on deaf ears. This went on for years. Finally, someone got around to re-writing the app, well after Don had departed. By this time, so much loathing had become attached to the name CTool that naming it CTool version 2 was out of the question. There was even a formal funeral for CTool, somewhat reminiscent of the copier (or was it a printer?) execution scene in Office Space.

Some might say Don deserved the slings and arrows for not making it go right to fix CTool. My only point is that saying you should never hack out a solution is probably unjustifiable in the Real World. But if you are the one to do it, tread cautiously.

---

• Get it in writing (an email). So when it becomes a problem later management doesn't "forget" that it was supposed to be temporary.

• Make it visible to the users. The more visible it is the less likely people are going to forget to go back and do it the right way when the crisis is over.

• Negotiate before the temp solution is in place for a project, resources, and time lines to get the real fix in. Work for the real solution should probably begin as soon as the temp solution is finished.

---

You file a second very descriptive bug against your own "fix" and put a to-do comment right in the affected areas that says, "This area needs a lot of work. See defect #555" (use the right number of course). People who say "don't put in a hack" don't seem to understand the question. Assume you have a system that needs to be up and running now, your non-hack solution is 8 days of work, your hack is 38 minutes of work, the hack is there to buy you time to do the work and not lose money while you're doing it.

Now you still have to get your customer or management agree to schedule the N*100 minutes of time required to do the real fix in addition to the N minutes needed now to fix it. If you must refuse to implement the hack until you get such agreement, then maybe that's what you have to do, but I've worked with some understanding people in that regard.

---

The real price of introducing a quick-fix is that when someone else needs to introduce a 2nd quick fix, they will introduce it based on your own quick-fix. So, the longer a quick-fix is in place, the more entrenched it will become. Quite often, a hack takes only a little bit longer than doing things right, until you encounter a 2nd hack which builds on the first.

So, obviously it is (or seems to be) sometimes necessary to introduce a quick fix.

One possible solution, assuming your version control supports it, is to introduce a fork from the source whenever you make such a hack. If people are encouraged to avoid coding new features within these special "get it done" forks, then it will eventually be more work to integrate the new features with the fork than it will be to get rid of the hack. More likely, though, the "good" fork will get discarded. And if you are far enough away from release that making such a fork will not be practical (because it is not worth doing the dual integration mentioned above), then you probably shouldn't even be using a hack anyways.

A very idealistic approach.

A more realistic solution is to keep your program segmented into as many orthogonal components as possible and to occasionally do a complete rewrite of some of the components.

A better question is why the hacky solution is bad. If it is bad because it reduces flexibility, ignore it until you need flexibility. If it is bad because it impacts the programs behavior, ignore it and eventually it will become a bug fix and WILL be addressed. If it is bad because it looks ugly, ignore it, as long as the hack is localized.

---

Some solutions I've seen in the past:

• Mark it with a comment HACK in the code (or similar scheme such as XXX)
• Have an automatic report run and emailed weekly to those that care which counts how many times the HACK comments appear
• Add a new entry in your bug tracking system with the line number and description of the right solution (so the knowledge gained from the research before writing the hack isn't lost)
• write a test case that demonstrates how the hack fails (if possible) and check it into the appropriate test suite (i.e. so that it throws errors that someone will eventually want to cleanup)
• once the hack is installed and the pressure is off, immediately start on the right solution

This is an excellent question. One thing I've noticed as I get more experience: hacks buy you a very short amount of time, and often cost you a huge amount more. Closely related is the 'quick fix' that solves what you think is the problem -- only to find when it blows up that that it wasn't the problem at all.

---

Setting aside the debate about whether you should do it, let's assume that you have to do it. The trick now is to do it in a way that minimizes long range affects, it easily ripped out later, and makes itself a nuisance so you remember to fix it.

The nuisance part is easy: make it issue a warning every time you execute the kludge.

The ripped out part can be easy: I like to do this be putting the kludge behind a subroutine name. That makes it easier to update since you compartmentalize the code. When you get your permanent solution, you're subroutine can either implement it or be a no-op. Sometimes a subclass can work nicely for this too. Don't let other people depend on whatever your quick fix is, though. It's difficult to recommend any particular technique without seeing the situation.

Minimizing long range effects should be easy if the rest of the code is nice. Always go through the published interface, and so on.

---

Try to make the cost of the hack clear to the business folks. Then they can make an informed decision either way.

---

You could intentionally write it in way that is overly restrictive and singe purposed and would require a re-write to be modified.

---

We had to do this once - make a short term demo version that we knew we did not want to keep. The customer wanted it on a winTel box, so we developed the prototype in SGI/XWindows. (We were fluent in both, so it wasn't a problem).

---

Confession:

I have used '#define private public' in C++ in order to read data from some other code layer. It went in as a hack but works well and fixing it has never become a priority. It is now 3 years later...

One of the main reasons hacks do not get removed is the risk that one introduces new bugs while fixing the hack. (Especially when dealing with pre-TDD code bases.)

---

My answer is a bit different from the others. My experience is that the following practices help you stay agile and move from hackey first iteration/alpha solutions to beta/production ready:

1. Test Driven Development

2. Small units of refactoring

3. Continous Integration
4. Good Configuration management
5. Agile database techniques/database refactoring

And it should go without saying you have to have stakeholder support to do any of these correctly. But with these products in place you have the right tools and processes to quickly change a product in major ways with confidence. Sometimes your ability to change is your ability to manage the risk of the changes and from the development perspective these tools/techniques give you surer footing.

참고URL : https://stackoverflow.com/questions/167904/how-do-you-stop-interim-solutions-from-lasting-forever