Einstellung 효과의 결합 [닫기]

Einstellung 효과는 더 나은 "비록 거기에 특정 방식으로 주어진 문제를 해결하기 위해 사람의 경향 '을 말한다"문제를 해결하는 이상 적절한 방법이. "

어느 정도의 경험이있는 프로그래머라면 어떻게 과거의 경험에서 나온 "시도하고 진실한"경로에서 항상 문제를 해결하는 경향에 대처할 수 있습니까?

두 가지 매우 구체적인 예제를 제공하기 위해 오랫동안 자바 애플리케이션 프레임 워크 (예 : jQuery)와 더 나은 웹 애플리케이션 프레임 워크 (예 : ASP.NET MVC)를 사용할 수있을 정도로 오랫동안 웹 애플리케이션을 구축해 왔습니다. 문제 영역 또는 비즈니스 규칙에서 시간이 부족하거나 긴급한 문제가 발생하는 클라이언트 작업이있는 경우 솔루션을 달성하기 위해 알고있는 것을 사용하는 경향이 있습니다. 이것은 매우 추한 것들과 관련이 있습니다.

document.getElementById 

또는 ASP.NET MVC 접근 방식으로 항목을 재구성하는 방법을 파악하는 대신 템플릿 바인딩 컨트롤 (DataList / Repeater)과 함께 ASP.NET을 사용합니다.

과거에 사용했던 기술 중 하나는 이러한 새로운 기술을 탐색하기 위해 존재하는 개인 프로젝트를 보유하는 것이지만 유지하기는 어렵습니다. 다른 어떤 접근법이 권장 될 수 있습니까?

이것은 좋은 질문입니다. 그리고이 문제에 부딪 치는 것은 선임 프로그래머 만이 아니라고 생각합니다. 조기에 해결하는 것은 학습자가 기술 개발을 가속화하는 좋은 방법이 될 수 있습니다.

이 문제에는 두 가지 측면이 있습니다. 하나는 나쁘고 다른 하나는 실제로 좋습니다 .

나쁜-잘못된 솔루션을 선택

다음은 예입니다. 경험이 부족한 개발자는 A 와 B 라는 두 가지 문제 만 해결했을 것 입니다. 이 시점에서, 당신은 당신이 모르는 문제가 있다는 것을 알고 있지만, 당신 자신의 경험의 렌즈를 감안할 때, 당신이 보는 많은 것들이 A 또는 B 일 것 같습니다 .

함께 새로운 문제가 발생합니다. 이 새로운 문제는 문제 A 처럼 보이 므로 일반적으로 A를 해결 하는 방식으로 문제를 해결 합니다. 무언가가 옳지 않다고 느끼는 데 시간이 더 걸리며, 작업을하면 새로운 문제인 C 라는 사실을 깨닫게 됩니다. 그것은 당신이 존재하지 않은 A 의 변형입니다 .

다시이 실수를하지 않으려면 어떻게해야합니까? 두가지:

1. 이 새로운 문제와 다른 점을 파악하십시오. 어떤 접근 방식이 다르게 작동했으며 그 이유를 파악하십시오.
2. 이 문제점을 분류하고 더 많은 새로운 문제점을 해결하십시오.

이 문제 를 자연스럽게 해결하는 데 도움 이됩니다. 10 년의 경험이 있으면 A 부터 Z 까지의 문제에 익숙하며 솔루션 레퍼토리가 광범위합니다.

좋은 효율성

현실에서 마감일과 제한된 자원으로, 아는 것을 사용하는 것이 항상 나쁘지는 않습니다.

1. 문제 해결 프로세스가 시작되면 새로운 문제를 아는 모든 문제와 비교합니다.
2. 표시를 인식하고 어떤 문제가 다음과 같이 보일지 결정하려고 시도합니다.
3. 100 % 일치 할 수없는 경우 숙련 된 개발자는 결함이있는 실행의 위험과 비교하여 발견에 더 많은 시간을 소비 할 위험이 있습니다. 시간 낭비의 위험이 너무 높으면 알고있는 것을 계속 진행하십시오.

그것은 나쁜 일이 아닙니다-위험 분석을 사용하여 100 % 정확도 이상의 효율성 을 선택합니다 . 그것은 매일 이루어지며 우리가하지 않으면 우리를 어디로도 데려 가지 않는 것들에 묶여있을 것입니다.

따라서 귀하의 질문에 대답하십시오 :

어느 정도의 경험이있는 프로그래머라면 어떻게 과거의 경험에서 나온 "시도하고 진실한"경로에서 항상 문제를 해결하는 경향에 대처할 수 있습니까?

1. 새로운 문제 를 계속 찾고
2. 문제에 대한 올바른 솔루션 을 선택하는 것이 더 좋습니다 . 어떤 솔루션을 아는 것이 아니라 왜 올바른지 아 십시오.
3. 의사 결정 기술을 연습하고 연마하십시오 . 때로는 효율성이 올바른 선택이며, 그 시간을 더 잘 인식하면 실제 이점을 측정 할 수 있습니다.

작업 시간의 20 %를 따로 설정하여 기술을 향상 시키거나 금식 대신 일을하십시오. 그렇지 않으면 천천히 뒤로 떨어지기 시작합니다. 이는 단기적으로는 더 적은 작업을 수행 할 수 있지만 장기적으로는 투자 수익을 창출한다는 의미입니다.

어려운 부분은 모서리를 자르는 압력에 저항합니다. 습관이 심해질 때까지 그 코너를 자르지 마십시오. 기술에 대한 이러한 투자가 "정상"이라고 생각하는 시점에 이르면 가끔 프로젝트를 진행하도록 선택할 수 있습니다. 그 동안이 시간은 선택 사항으로 간주하지 말고 그에 따라 견적을 작성하십시오.

소프트웨어 개발, 내보기에서 찾는 것에 대해 항상 아닙니다 절대 일을 * 최고의 * 솔루션을하지만, 점점. 따라서 항상 최선의 방법으로 문제를 해결하지 않는다면 세상의 끝이 아닙니다.

그러나 최선의 방법으로 일을하는 것이 중요하다고 생각한다면, 가장 좋은 방법은 팀의 일환으로 개발 될 것이라고 생각합니다. 동료들과 설계 및 코드 검토를 논의하십시오. 사람들은 일반적으로 배경과 선호도가 다르기 때문에 두 사람 또는 세 사람 사이에 문제와 해결책에 대한 몇 가지 다른 요구 사항이 있어야합니다.

어느 정도의 경험이있는 프로그래머라면 어떻게 과거의 경험에서 나온 "시도하고 진실한"경로에서 항상 문제를 해결하는 경향에 대처할 수 있습니까?

정기적으로 리 팩터하십시오. 리팩토링을 위해서는 과거에 작성한 코드를 면밀히 조사해야합니다. 이번에는 새로운 관점에서 오래된 코드를 볼 수 있습니다. 주요 기술 변경 사항을 준수하는 한 필요에 따라 업데이트를 수행 할 수 있습니다.

문제 영역 또는 비즈니스 규칙에서 시간이 부족하거나 긴급한 문제가 발생하는 클라이언트 작업이있는 경우 솔루션을 달성하기 위해 알고있는 것을 사용하는 경향이 있습니다.

좋은. 자신의 목표보다는 고객의 요구에 집중하고 있습니다. 잘 했어.

이것은 매우 추한 것들과 관련이 있습니다.

document.getElementById

또는 ASP.NET MVC 접근 방식으로 항목을 재구성하는 방법을 파악하는 대신 템플릿 바인딩 컨트롤 (DataList / Repeater)과 함께 ASP.NET을 사용합니다.

Webforms에는 아무런 문제가 없습니다. MVC는 Webform을 대체하기위한 것이 아닙니다. 새로운 기술을 배울 때가 아닙니다. 삼각형을 기억하십시오 . 시간이 있으면 리팩터링하십시오. 또한 첫 번째 진술을 참조하십시오.

과거에 사용했던 기술 중 하나는 이러한 새로운 기술을 탐색하기 위해 존재하는 개인 프로젝트를 보유하는 것이지만 유지하기는 어렵습니다. 다른 어떤 접근법이 권장 될 수 있습니까?

유지하기 어려운 것은 무엇입니까? 바라건대 당신이 배우기 위해 설계된 프로젝트를 유지하지 않기를 바랍니다. 그렇다면 샘플 프로젝트를 버립니다. 학습 목적으로 하나의 프로젝트를 만드는 데 아무런 문제가 없습니다. 이것은 매우 좋은 것입니다. 첫 번째 진술을 참조하십시오.

시도하고 참! = 나쁘다. 여기서 "Einstellung Effect"는 문맥에서 약간 벗어납니다. 테스트는 "병 열기"를 최적화하는 사람들을 말합니다. "병을 여는"사람들의 방법은 제한적이며 시간이 지나도 향상되지 않습니다 (Sci-Fi 항목 제외). 소프트웨어에서 "태스크 X를 달성하는 가장 좋은 방법은 시간이 지남에 따라 변경됩니다.

상자 밖에서 생각하는 데 도움이되는 것은 실제로 연습하는 것입니다. Edward De Bono 는 측면 사고 와 관련 주제에 관한 많은 책을 저술했습니다 .

그러나 어떤 결정 시점에서 가장 중요한 것은 위험을 평가하고 포용하는 것입니다. De Marco와 Lister의 Bears with Wals는 소프트웨어 개발에 적용될 때이 주제에 관한 최고의 책 중 하나입니다.

익스트림 프로그래밍 및 기타 민첩한 방법론을 통해 일상적인 문제로 새로운 (스파이크) 솔루션을 실험 해 볼 것을 제안합니다. 나는 프로젝트를 시작하는 동안 다른 기술로 실험을 해왔으며, 그로 인해 진정한 시도와 찬성에 찬성하여 때로는 새로운 기술 보석을 발견하기 위해 여러 번 절약했습니다.

팀으로서 패턴을 뛰어 넘는 경이를 인식하여 그룹을 변경할 수 있습니다. 나는 종종 이것을 위해 새로운 사람들을 사용합니다. 왜냐하면 그들이 정상적인 일을하는 방식으로 나뉘 지 않기 때문입니다. 이것은 다소 관리적인 답변이지만 숙련 된 엔지니어라도 다른 사람의 견해가 덜 편향적 일 수 있으며 적어도 자신의 의견보다 더 많은 순위로 고려할 수 있다고 생각합니다.

document.getElementById 대신 문서에 넣는 내용이 아무리 수용되어 있어도 시간 낭비라는 것이 확실하지 않습니까?

편집 : 방금 두 예제 모두 도구에 관한 것임을 깨달았습니다. 도구를 기술 개발의 가장 큰 이정표로 변경하는 것을 고려했기 때문일 수 있습니다. 훌륭한 코더는 툴링이 중요하지 않다는 것을 의미하는 것이 아니라 이미 사용하고있는 것이 툴 바텀 툴셋이 아니라는 놀라운 일을하기 위해 튜링의 완벽한 언어 이상을 필요로합니다. 한 도구에서 다른 도구로 이동하는 것이 생각할 수있는 가장 큰 진전 인 경우 기본적으로 정량화 할 수없는 영역에 멈췄을 수 있습니다.

어느 정도의 경험이있는 프로그래머라면 어떻게 과거의 경험에서 나온 "시도하고 진실한"경로에서 항상 문제를 해결하는 경향에 대처할 수 있습니까?

자기 인식

경향, 약점 및 강점을 알고 있어야합니다.

의식적인 결정

당신의 결정을 명백하고 의식적으로 만드십시오. 어떻게 할 것인지에 대해 의식적으로 생각하지 않고 무언가를하기 위해 뛰어 내리지 마십시오.

배우고 적용

새로운 기술을 계속 배우고 적용 할 수있는 곳을 고려하십시오. 적용 가능한 상황이 발생하면 비용-이익 분석을 수행하십시오. 때로는 새로운 것을 시도 할 때의 이점이 알려진 솔루션의 이점보다 큽니다.