프로그래밍에서 해로운 유혹

궁금한 점은, 프로젝트에서 어떤 종류의 프로그래밍 유혹이 실제로 해로운 것으로 판명 되었습니까?

실제로 무언가를하고 싶은 충동을 느끼고 그것이 프로젝트에 도움이 될 것이라고 생각하거나 또는 자신을 속여서 그것을 믿는다 고 생각할 때와 같이, 일주일 후에는 실제 문제를 해결하지 않고 대신 새로운 문제를 만들었 음을 깨닫게 됩니다. 최선의 경우, 눈에 띄는 영향이없는 내면의 짐승을 기쁘게합니다.

개인적으로 나쁜 코드를 리팩터링하지 않는 것이 매우 어렵다는 것을 알았습니다. 나는 많은 나쁜 레거시 코드로 작업하고 있으며 리팩토링이 아무 것도 깨지지 않는다는 것을 테스트 할 테스트가 없을 때 그것을 만지지 않기 위해 약간의 숨을 쉬어야합니다.

사용자 인터페이스의 또 다른 악마는 말 그대로 UI 레이아웃을 변경하는 데 시간을 할애 할 수 있다는 것입니다. 때때로 나는 유용성에 노력하고 있다고 말하지만 사실은 버튼을 움직이는 것을 좋아합니다.

프로그래밍 악마는 무엇이며 어떻게 피합니까?

조기 일반화는 나의 큰 bugaboo입니다. 문제를 먼저 해결하고 일반적인 경우에 실제로 해결해야 할 때까지 기다리지 않고 항상 일반적인 경우를 먼저 수행하고 필요한 것보다 복잡한 코드를 작성합니다.

최신 정보:

자세한 설명은 " 죄 # 1-조기 일반화 "를 참조하십시오 .

"우리는이 문제로 돌아와서 나중에 고칠 것입니다. 지금 작동해야합니다!"

마감일이 먼 곳에 있습니다. 시간이 충분하기 때문에 웹 서핑에 약간의 시간을 보내지 않겠습니까?

"이것은 단지 획기적인 개념 증명 코드입니다. 일단 그들이 그것을 좋아하면, 나는 그것을 정말로 좋게 만들 것입니다."

1. 릴리스 며칠 전에 코드 일부를 리팩토링했습니다 .
2. 인터넷 : 모두 의 가장 큰 방해.
3. 새로운 기술 : 새로운 기술에 손을 댈 수 없습니다.
4. 최적화 : 최적화, 최적화 .. 그리고 더 많은 최적화
5. 완벽 : 코드에 결코 만족하지 않았습니다.
6. 해야할 일 : 결코 할 수없는 할일 부족.
7. 시간 추정 : 많은 PM이 이것을 "추정"으로 간주하지 않습니다. 그들은 사실로 받아들입니다.
8. 약속 : 약속이 너무 많습니다.

기존의 프레임 워크와 라이브러리가있을 때 사내에서 모든 것을 구축하려고 노력합니다.

반복되는 악마 : 조기 최적화 및 과도 엔지니어링.

그리고 나는 여전히 그들을 100 % 피할 수 없습니다 ...

지나치게 낙관적 인 추정

당신의 관리자가 당신을 쳐다보고 있고, 당신의 직감이 말하는 것보다 더 낮은 추정치를주는 불타는 느낌을 느끼면 ... 하지 마십시오!

결국, 당신의 내장은 이미 너무 낮을 것입니다!

방금 배운 것이기 때문에 프로젝트에서 기술 / 도구 / 언어를 순수하게 사용하는 것.

개발자가 얼마나 좋은지 증명하려고 노력합니다.

자신이 작성한 코드를 고려하십시오.

방금 휴식을 취하고 stackoverflow.com을 살펴 보겠습니다.)

최악의 유혹 :

오, 음 .. 더러운 작은 속임수 / 해킹 / 수정이 다 치지 않을 것 같아요.

무슨 일인지 아프게 해 :)

코드 작성을 잊어 버리는 것은 문제를 해결하기위한 최후의 수단입니다 .

기능 크리프

계획을 세우고이를 지키고 배포하십시오. 그런 다음 돌아가서 사람들이 요구하는 것을 추가하십시오.

나는 이것을 반복해서 보았다. 앉아서 디자인 작업을하고 코딩을 시작합니다. 사용자는 자신이 좋아하는 기능이 "누락"되었다는 혼란스러운 말을 듣고 로비를 시작합니다. 상사는 11 시간 째에 추가를 요구하고, 배치를 파기하고, 모든 곳에서 버그를 발생 시키며, 3 개월 후에 모든 사람이 정산되면 제거하라는 메시지가 표시됩니다. 처음에는 그 끔찍한 복고풍 기능! 나머지 디자인이 무의미하다는 말을 할 수 없습니까?

1. 더 많은 기능 추가

2. 경쟁에는이 기능이 있습니다. 따라서 이것은 전략, 위치 결정 등을 분석하는 것보다 많은 프로그래밍 기능을 가지고 있어야합니다.

3. 대회에는이 기능이 없습니다. 따라서 이것은 차별화 된 기능이므로 분석 전략, 위치 결정 등보다 더 많은 프로그래밍이 가능합니다.

4. 더 많은 프로그래밍으로 비즈니스 문제를 해결합니다. 예를 들어, 더 많은 기능을 프로그래밍하면 웹 사이트가 호스팅되는 Linux 서버 관리에 대한 전문 지식을 향상시킬 수 없습니다. 때로는 모든 것을 C # .Net으로 다시 코딩하는 대신 문제를 해결하는 방법을 배워야합니다.

5. 더 많은 프로그래밍으로 마케팅 문제를 해결합니다. 예를 들어, Seth Godin의 자주색 암소 개념을 남용하면 제품에 더 많은 기능을 프로그래밍하여 "보라색 암소"로 만드는 마케팅 문제를 간접적으로 해결하고 있습니다. 때로는 돌연변이 괴물 일 수도 있습니다.

6. 이 스크립트를 작성하는 데 소요되는 시간이 실제로 중요한 것을 실제로 프로그래밍하는 대신 몇 시간 안에 다시 저장 될 것이라고 주장하는 더 많은 프로그래밍으로 생산성 문제 해결

7. "올바르게"원하기 때문에 코딩 계획 중이지만 아직 코딩하지 않은 계획

8. 더티 버전을 코딩하고 "나중에 더 나아질 것"이라고 약속하지만 "더 나아질 것"으로 돌아 가지 않을 것

9. "매우 번거롭기 때문에"목업이나 사이트 맵을 수행하지 않습니다. 나는 경쟁 업체의 페이지를 스크린 샷하고 절대 손으로 그리는 사이트 맵 "나중"을 그릴 수 있습니다. 그런 다음 내가 생각하는 첫 페이지를 바로 프로그래밍하십시오.

고백 : 나는 개인적으로 실수 1, 3, 7, 8을했습니다. 또한 2, 4, 5, 6을 만들었지 만 종종 내가하지 않았다는 사실을 저 자신에게 회피했습니다.

나는 현재 9를 고치고 있습니다.

편집 문제가 우리가 해결책을 제시해야한다는 것을 깨닫지 못했습니다.

1) 더 많은 기능 추가 하지 마십시오. 비즈니스, 마케팅, 창립자, 고문 등과 함께 작업하고 응용 프로그램을 단 하나만 제거하십시오.

트위터, Groupon 등에 대해 읽으면 성공으로 이어진 단 1 가지로 사물을 제거하는 방법 에 대해 읽 습니다.

대기업을 건설하려는 경우에만 효과가 있다고 생각되면 다시 생각하십시오. 이 라인에 대한 Ctrl 키 + F "나는이 소프트웨어에 추가하는 더 많은 기능은 더는 판매하고있다. (이것은 대부분의 소프트웨어 개발자, 말, 매우 직관적 필요도 없다.)"에 이 링크

2) 대회에는이 기능이 있습니다. 이 기능이 있어야합니다

해결책 1 참조

3) 대회에는이 기능이 없습니다. 이것은 차별화 된 기능입니다

해결책 1 참조

4) 더 많은 프로그래밍으로 비즈니스 문제 해결.

당신을 가르치기 위해 누군가를 고용해야하거나, 상담을하거나, 당신을 위해 그것을하고 어떻게 그 일을했는지 ​​문서화하여 다음에 스스로 할 수있게하십시오. 그냥 해!! 코드를 다시 쓰지 말고 GO를 통과하지 말고 $ 200를 모으지 마십시오.

5) 더 많은 프로그래밍으로 마케팅 문제 해결.

사람들이 당신이 판매하는 것을 이해하지 못하면 마케팅 문제입니다. 솔루션 1로 돌아가서 피벗하십시오.

6) 더 많은 프로그래밍으로 생산성 문제 해결

기다림.

생산성에 2 주 이상의 기간 동안 특정 생산성 문제가 발생하여 2 주 동안 합리적으로 발생한다고 느낄 때까지 기다리십시오.

이제이 문제를 해결하기 위해 스크립트를 프로그래밍하는 데 소요 된 시간을 평가하십시오. 최악의 추정치를 취하고 2를 곱하십시오.

예상 시간에 시간당 요금을 곱하십시오.

이제 대체 솔루션 검토 : 아웃소싱, 상용 솔루션 구매, 관련 조치 없음 등

가장 비용 효율적인 솔루션을 선택하십시오.

그것에 충실하십시오.

7) "올바르게"얻기를 원하기 때문에 코딩 계획 중이지만 아직 코딩하지 않은 경우

운동을하세요. 엉덩이에 동기를 부여하고 행동 계획을 세우는 엔돌핀이 급증합니다. 방금 5x5 벤치 프레스와 5x5 스쿼트를했기 때문에 이것을 알고 있습니다.

8) 더티 버전을 코딩하고 "나중에 더 나아질 것"이라고 약속하지만 "더 나아질 것"으로 돌아 가지 않을 것

GTD에서 티 클러 파일 시스템을 설정하십시오. 적극적으로 후속 조치를 취합니다. 자신과 다른 사람들에게 모든 약속을 따르십시오.

9) 모형 또는 사이트 맵은 "매우 번거롭기 때문에"하지 않습니다.

balsamiq 모형 데스크탑 에디션에 75 달러를 지출하십시오. 3 주 전에 샀기 때문에 이것을 알고 있습니다. 현실 세계에서 내 그림이 짜증이 나더라도 아티스트, 건축가 및 공상가처럼 느껴지기 때문에 실물 모형을 다시 만들었습니다. balsamiq에 사용 된 글꼴은 무의식적으로 RAD에서 도움이되는 석재가 아닌 모형이라는 것을 상기시킵니다.

편집 종료

두 잔의 맥주가 더 좋고 더 오래 일하는 데 도움이 될 것입니다.

"그래, 하루에 2000 줄 스파게티의 거대한 혼란을 리팩터링 할 수있다 ..."

"나는 그것을 테스트하지 않고 얻을 수 있습니다. 테스트하기가 너무 어렵습니다."

그리고 그것은 사악한 형제입니다

"시험을 작성하거나 이해하는 것이 아무리 어려운 경우에도 시험을 받아야합니다."

지연 과 낙관적 과제 추정 은 나의 가장 큰 죄입니다.

첫 번째 운동에 대한 스트레칭, 팔 굽혀 펴기 또는 풀업 (또는 기타 운동) 및 두 번째 운동에 대한 추정을하기 전에 비관적 인 분위기.

"훨씬 '입니다 쉽게 하는' 스크래치에서 기능을 구현할 기존의 코드를 이해하는 것보다."

내가 겪고있는 프로젝트가 겪었던 엄청난 해로운 유혹은 '내부 플랫폼 효과'입니다. 이것은 오래 전부터 사라 온 건축가들이 매년 약 2 천만 달러를 생성하지만 업데이트하고 유지하는 데 6 천만 달러의 프로젝트를 만들어 낸 무한한 지혜로 설정 한 접근법입니다. 문제의).

NIH - 여기를 발명하지 않음

타사 솔루션에 공정한 기회를 제공하는 데 어려움을 겪고 있습니다. 모든 사람들은 자신을 위해 맞춤 제작되지 않은 타사 솔루션에 대해 회의적인 태도를 취해야하지만 100 % 객관적으로 어려움을 겪고 있습니다.

시간 절약은 타사 솔루션은 피해야한다 10 명 중하더라도 9 번, 나는 실현 충분히 객관적 일 필요가 이렇게 거대 할 수있는 한 작동합니다.

고객의 실제 데이터베이스 사본을 분석하는 대신 제공된 "샘플 데이터"에 대한 설계, 코딩 및 / 또는 단위 테스트. 마감일이 짧았으며 계속오고 있다고 말했지만 결코 그렇지 않았습니다. 그것이 배치되었을 때 폭발은 훌륭했다. 실제로 고객에게 3 명의 부모 고객이있을 것으로 예상 한 사람.

실제 데이터 의 사본이있을 때까지 프로젝트를 다시 시작하지 않습니다 .

가 꼭 어딘가를 수행하는 라이브러리가 될 증후군.

밀접한 관련

플러그인 페티쉬

완벽주의는 죽인다. 아마도 프로젝트가 성공하지 못한 가장 큰 이유 일 것입니다.

글쎄, 때로는 프로그래밍으로 병에 빠지게됩니다.

리팩토링 대신에 재 작성.

더 좋은 방법이 있다고 생각하면됩니다. 나는 "충분히 좋은"것에 대해 정착하지 않을 것입니다. 나는 완벽 함 이상을 취하고 있습니다! 일반적으로 문제에 대해 다른 관점을 가지고 있거나 다른 각도에서 해결책을 볼 수있는 다른 사람들과 이야기하면 피할 수 있습니다.

실제 작업보다 도구를 유지 관리하는 데 더 많은 시간이 소요될 수 있습니다.

솔루션 : 코드 최적화와 마찬가지로 먼저 생산성 병목 현상을 발견하고 발견 된 후에 만 ​​자동화를 통해 치료하십시오 .

프로그래밍 악마는 무엇입니까?

다른 사람들이 언급 한 것 외에.

우선 순위 : 프로젝트와 관련하여 우선 순위가 높은 작업을 무시하고 프로젝트에서 다른 작업을 먼저 수행하면 더 흥미로워집니다!

어떻게 피할 수 있습니까?

좀 더 자기 규율로. 진지하게, 옳은 일을하려는 자기 훈련과 자기 동기 부여는 이러한“악마”를 피하는 데 도움이됩니다.

아직 고객의 승인을받지 못했지만 마감일이 다가오고 있습니다. 여기에 시작할 수있는 예비 구성 요소가 있습니다.

나중에, 당신은 comp와 일치하는 프로젝트를 완성한 후에 ...

아, 여기 고객의 수정본이 있습니다. 몇 가지 사소한 것들만 바꾸고 싶습니다 *

(* 주요 기능은 완전히 다릅니다)

그런 다음 짧은 기한의 압력을 받고 마지막 개정판이라고 가정하기 때문에 처음부터 시작하는 대신 원래 결함이있는 모델을 기반으로 원래 코드를 리팩토링합니다.

나는 이것에 항상 조금씩 얻는다. 웹 개발자로서 피하기는 어렵습니다. 최선의 조언은 더 많은 시간을 투자하여 올바른 방법으로 변경 사항을 적용하는 것입니다.