무엇이 잘못 될 수 있는지에 대한 지식 증가로 인한 느린 문제 해결 극복 [폐쇄]

이것은 한동안 나를 괴롭 히고 있었고 다른 전문가들의 의견에 진심으로 감사드립니다.

짧은 배경 : 1988 년 부모님이 저의 첫 컴퓨터를 구입했을 때 프로그래밍을 시작했습니다 (14 세에 39 세). 1997 년에 전문 프로그래머가되기 전에 다른 두 가지 진로를 따라갔습니다. 늦은 블룸 머, 아마도 그랬습니다. 나는 여전히 내 선택에 만족하고, 프로그래밍을 좋아하며, 내가하는 일에 능숙하다고 생각합니다.

최근에 경험을 쌓을수록 프로젝트를 완료하는 데 시간이 오래 걸리거나 프로젝트의 특정 작업을 수행하는 데 시간이 오래 걸린다는 사실에 주목했습니다. 나는 아직 노인하지 않습니다. 그것은 내가 일이 잘못 될 수있는 많은 다른 방법들을 보았습니다. 그리고 내가 알고 기억하는 잠재적 인 함정과 문제는 점점 더 커지고 있습니다.

사소한 예 : 그냥 "알겠습니다, 여기에 파일을 작성하십시오". 이제 권한, 잠금, 동시성, 원 자성 작업, 간접 / 프레임 워크, 다른 파일 시스템, 디렉토리의 파일 수, 예측 가능한 임시 파일 이름, PRNG의 임의성 품질, 중간에 전원 부족에 대해 걱정하고 있습니다. 작업, 내가하는 일에 대한 이해할 수있는 API, 적절한 문서 등

요컨대, 문제는 "어떻게해야합니까?"에서 "가장 좋은 / 안전한 방법"으로 옮겨 왔습니다.

결론은 초보자보다 프로젝트를 완료하는 데 시간이 더 걸린다는 것입니다. 내 버전은 견고 할 수 있으며 만드는 방법을 알면 뚫을 수 없지만 시간이 오래 걸립니다.

위의 "파일 만들기"예제는 바로 그 예입니다. 실제 작업은 분명히 더 복잡하지만 이와 같은 일반적인 질문에는 적합하지 않습니다. 내가 어디로 가고 있는지 이해하기를 바랍니다. 나는 효율적인 알고리즘을내는 데 아무런 문제가 없으며, 수학을 좋아하고, 복잡한 과목을 즐기고, 집중에 어려움이 없습니다. 나는 경험에 문제가 있으며 결과적으로 오류에 대한 두려움 (내재적 또는 외 재적)에 문제가 있다고 생각합니다.

새로운 개발, 새로운 기술, 언어, 플랫폼, 보안 취약성 등에 대해 하루에 거의 2 시간 씩 읽습니다. 수수께끼는 지식이 많을수록 프로젝트 완료 속도가 느려진다는 것입니다.

이것을 어떻게 처리합니까?

프로젝트 완료 속도가 느려지지 않습니다. 이전에는 초보 프로젝트가 실제로 수행되지 않았을 때 수행되었다고 생각했습니다. 이 품질을 고객에게 판매해야합니다.

"이 회사는 더 빠르고 저렴하게 처리 할 수 ​​있지만 실제로 완료 되었습니까? 아니면 몇 년 동안 버그를 사냥하겠습니까?"

그 외에도 오래된 관용구를 알고 받아 들여야합니다. "완벽한 사람은 선의 적입니다."

당신이 어두운면에 합류 할 때인 것 같습니다 : 관리.

프로그래밍을 포기하고 관리자가 되라는 제안은 아닙니다. 그러나 지금까지 인용 한 모든 경험은 사실상 기술적 인 것으로 보입니다. 파일을 작성하는 간단한 조작으로 덜 성숙한 개발자는 결코 고려하지 않을 10 가지 다른 측면을 생각할 수 있습니다. 반드시 나쁜 것은 아니지만 ...

어두운면은 현재 가치에 관한 것입니다. 최대 이익을 위해 최소한의 투자를하는 것입니다 (비용-편익 분석). 사업에서 모든 것이 비용이 얼마나 들지, 성공 확률, 실패 확률, 장엄한 실패 확률 및 잠재적 이익으로 귀결됩니다. 수학을하십시오; 그에 따라 행동하십시오.

이것은 개발자 인 경우에도 잘 작동합니다. 권한 및 이름 충돌을 무시하고 임시 파일을 생성합니다 (5 분). 순이익, 팀의 나머지 부분은 해당 파일의 존재 여부에 따라 어떤 코드로 작업을 시작할 수 있습니다. 완벽한 솔루션입니까? 절대적으로하지. 99 %, 95 %, 90 %를 얻을 수 있습니까? 네, 아마 그럴 것입니다.

또 다른 질문 : 기술 부채에 대해 어떻게 생각하십니까? 어떤 사람들은 그것이 제거되어야한다고 생각합니다. 나는 그 사람들이 잘못 생각합니다. 비즈니스에서와 마찬가지로 기술 부채를 통해 "현금"또는 "시간"을 빌려 더 빨리 물건을 배달 할 수 있습니다. 더 좋은 점 : 2 년 만에 완벽한 솔루션 또는 고객이 4 개월 안에 사용하고 구매할 수있는 완벽한 해킹? 모든 상황은 다르지만 어떤 상황에서는 2 년을 기다리면 고객은 이미 경쟁 업체에 가입하게됩니다.

핵심은 잘 운영되는 비즈니스가 재무 부채를 관리하는 것과 같은 방식으로 기술 부채를 관리하는 것입니다. 충분하지 않으면 최적의 투자 수익을 얻지 못합니다. 너무 많이 복용하면 관심이 당신을 죽일 것입니다.

조언 : 철저 성을 극대화하는 대신 가치를 극대화하고 있는지에 따라 업무 평가를 시작하십시오. 그리고 이것을 연습하면 기술 영역에서 이미 개발 한 것과 동일한 직관을 개발하게됩니다.

부수적으로 최근에 나는 포모 도로 기술을 시작했으며 많은 도움이되었습니다. 접선의 접선 대신에 작은 시간 간격으로 초점을 맞춘 다음 향후 작업 / 연구를 위해 포모 도로를 할당하십시오. 주제를 연구하기 위해 몇 번이나 메모를한지 몇 번이나 놀랍지 만, 1 시간 후, 시간이 다가 오자 나는 "오늘 내 시간으로 할 수있는 다른 것들이 적어도 3 가지 더 중요하다"고 생각했습니다.

나는 몇 년 전에 (아마도) 같은 문제가 있었으며 몇 년 동안 지속되어 극복했습니다. 내 방법이 당신에게도 적용되는지 확실하지 않더라도 내가 어떻게 그것을 달성했는지 아는 것이 당신에게 관심이 될 것입니다.

: 당신은 또한 여기에보고해야한다 소프트웨어 공학 전문의 7 단계 그것은 생산성이 큰 부분에서 기술 수준의 부작용 있음을 보여줍니다. 현재 사용중인 기술에 대해 3 단계에서 4 단계 사이의 어느 시점에있을 수도 있습니다 (기술 숙련도는 기술에 따라 다르지만 다른 기술을 배우면서도 일부 기술의 마스터가 될 수 있음).

이제 나는 전기 증언으로 시작합니다.

약간의 맥락. 저는 47 세입니다. 80 년대 12시에 프로그래밍을 시작했습니다. 고등학교에있는 동안 나는 또한 시간제 전문 게임 프로그래머로 일했습니다. 기본적으로 하드웨어를 구입하기에 충분한 돈을 얻지 못했지만 그것을 즐기고 많은 것을 배웠습니다. 18 세에 나는 컴퓨터 과학에 대한 정식 학습을 시작했습니다.

결과적으로 20 세가되었을 때 프로그래밍 작업을 시작할 때마다 주어진 문제를 해결하기위한 많은 방법을 알고 있었고 많은 매개 변수와 함정, 방법의 단점과 한계를 매우 의식했습니다.

어떤 시점에서 (약 26 세) 어떤 프로그램도 전혀 작성하기가 정말로 어려워졌습니다. 가능성이 너무 많아서 더 이상 선택할 수 없었습니다. 몇 년 동안 (6으로 만들) 나는 심지어 프로그래밍을 중단하고 기술 뉴스 작성자가되었습니다.

그럼에도 불구하고 나는 프로그래밍을 완전히 멈추지 않았다. 그리고 어느 시점에서 돌아 왔습니다. 나를위한 열쇠는 극단적 인 프로그래밍, 더 구체적으로는 단순성 원칙 : "아마도 작동 할 수있는 가장 간단한 것을 작성하십시오"였습니다.

기본적으로 나는 코드 효율성 (내 주요 장애물, 비효율적 인 디자인 피하기)에 신경 쓰지 말고 가장 쉬운 길을 가야했습니다. 또한 오류를 일으키는 테스트를 작성한 후 (실제로 TDD입니다) 오류에 대해 신경 쓰지 않고 나중에 오류 처리를 지연시켜야했습니다.

내가 글을 쓸 때 배운 것입니다. 내가 무엇을 쓸지 모를 때, 또는 내가 쓰고있는 것이 나쁘다 는 것을 알 때 . 그냥 계속 해. 실제로 나쁜 것을 쓰십시오. 나중에 수정하겠습니다. 또는 정말 나쁜 경우 지우고 다시 쓰십시오.하지만 처음으로 완벽한 것을 쓰는 두 번 쓰는 것이 더 빠릅니다.

실제로 처음 작성하는 것이 좋다고 생각하는 코드는 실제로 나쁜 코드만큼 많은 개선이 필요할 것입니다.

단순성 경로를 따르면 추가 보너스도 얻습니다. 초기 설계 / 코딩 제거 / 변경을 쉽게 수락 할 수 있습니다. 당신은 더 유연한 마음을 얻습니다.

또한 코드에 임시 주석을 달아서 지금하지 않는 일을 설명하고 일반적인 사용 사례에서 코드가 작동 할 때 나중에 수행 할 방법을 설명했습니다.

또한 XP Dojo에 참여하여 XP 프로그래머를 내면화하기 위해 다른 프로그래머와 함께 연습 한 코드 카타를 진행했습니다. 도움이되었습니다. 위의 공식적인 방법을 본능적으로 만들었습니다. 페어 프로그래밍도 도움이되었습니다. 젊은 프로그래머와 함께 일하면 약간의 추진력이 있지만 경험이 있으면 그렇지 않은 것을 볼 수 있습니다. 예를 들어 제 경우에는 종종 그들이 지나치게 복잡한 디자인에 관여하는 것으로 보이며 이로 인해 발생할 수있는 디자인 악몽을 알고 있습니다. 그런 식으로 갔다. 그거 했어. 문제가있었습니다.

나를 위해 가장 중요한 점은 흐름을 유지하는 것입니다. 빠른 속도는 흐름을 유지하는 데 실제로 성공합니다.

이제 나는 전문 프로그래머로 돌아 왔고 내가하고있는 일에 대한 더 깊은 이해를 통해 더 좋고 나아 졌다고 생각합니다. TDD 연습 나는 어린 황소 때보 다 약간 느릴 수 있지만 (아무것도 테스트하지 않았지만) 리팩토링을 두려워하지 않으며 디버깅에 훨씬 적은 시간을 소비합니다 (거의 시간이 거의 없어 시간의 10 % 미만으로 만듭니다) ).

요약하자면, 민첩한 방법 (XP)을 사용하여 코드 블록을 극복하고 단순성을 유지 한 다음 리팩토링하고 본능적으로 만드는 연습을했습니다. 그것은 나를 위해 일했다. 다른 사람에게 일반화 될 수 있는지 확실하지 않습니다.

기술 습득 수준의 측면에서 저는 기술을 바꿀 때마다 (새로운 언어, 새로운 프레임 워크 등을 배우는 등) 느려질 때 단계를 거치게된다는 사실을 주로 배웠습니다. 이것은 정상이며 결국 극복 할 것입니다. 또한 좋은 방법론과 범용 프로그래밍 기술로이를 보완 할 수 있으며 그리 큰 문제는 아닙니다.

프로그래밍의 중요한 부분은 복잡성을 관리하고 제어하는 ​​것이며 개인적으로 가장 중요한 문제 중 하나입니다. 무시하면 결함 빈도가 급증하거나 귀하의 경우와 같이 완성 된 소프트웨어의 ETA가 급격히 증가합니다.

소프트웨어의 복잡성을 여러 수준과 방법으로 제어하고 관리 할 수 ​​있지만, 어떤 관점에서 볼 때 가장 좋은 방법은 다음과 같습니다. "모든 소프트웨어 프로젝트의 최우선 순위는 고객 만족입니다. 이는 고객의 기대에 따른 기능입니다."

다시 말해, 소프트웨어의 복잡성은 고객의 기대치를 얼마나 능숙하게 제어하는지에 달려 있습니다.

이 견해를 채택하면 두 가지 중요한 점이 분명해집니다.

1. 고객의 기대는 어떤 형태로든 명시되어야합니다.
2. 고객의 기대는 항상 수정 될 수 있으며 협상 기술을 통해 이루어집니다.

귀하의 예는 "간단히 작성"대 "다른 수많은 고려 사항"과 같은 매우 좋은 예입니다. 생각해보십시오-누군가가 두 변형에 대한 철저한 요구 사항을 적어 놓았다면 설명 된 기능에 동등한 것이있을 수 있습니까?

F16을 만드는 것은 Cessna를 만드는 것과는 다르지만 둘 다 날 수 있습니다.

간단한 대답은 : 받아들입니다.

모든 시스템에는 안정성, 견고성, 보안, 속도, 하드웨어 비용, 개발 비용, 출시 시간 등의 절충안이 있습니다. 고객이 이러한 절충점을 어떻게 만드는지에 항상 동의하는 것은 아니지만 결정을 내리는 사람은 아닙니다. 당신이 할 수있는 것은 고려 의견을 제공하는 것입니다. 소프트웨어 개발은 ​​"개인 웹 페이지"에서 "원자로 작동"에 이르기까지 전체 영역을 다루며 그에 따라 코드를 작성해야합니다. 충돌이 "내 개인 웹 페이지를 새로 고침"을 의미하는 경우 누가 그런 일이 발생하는지 누가 정말로 걱정합니까? 그러나 충돌이 "Chernobyl"을 의미하는 경우 솔리드 코드에 대한 선호는 내 취향에 약간 우연한 것입니다.

"Proof of Concept"레벨 코드를 기꺼이 받아 들여 라이브 시스템에서 실행하는 클라이언트가 있으며, 종종 익숙한 시스템 관리자가 있습니다. IME 시스템은 대개 한밤중에 한 시간 정도 사용할 수 없으며 예약 된 재시작이 많이 발생합니다. 그러나 그들은 그들이 원하는 방식으로 사업 결정을 내 렸습니다. 필드가 너무 빠르게 이동하여 고품질 코드가 준비되지 않았을 때 이상적이지만 값을 볼 수 없기 때문에 (시스템이 "작동하는 경우"인식하지 못하므로 시스템이 돈). 그것이 당신을 너무 귀찮게한다면, 그 클라이언트를 피하십시오.

최신 상태를 유지하는 것은 우리 모두가 소비해야하거나 최소한 지출해야하는 시간입니다. 때때로 그것은 당신을 일하게 할 것이고, 다른 때는 단지 당신의 마음을 좋은 상태로 유지합니다. 어느 쪽이든 즐기십시오.

금융 / 무역 관련 응용 프로그램, 방송, 항공 우주, 국방 등과 같은 매우 중요한 미션 크리티컬 시스템 개발에 귀하의 기술이 매우 유용 할 것 같습니다.

이러한 종류의 응용 프로그램의 오류는 비용이 많이 들고 모든 경우를 처리 할 수 ​​있다고 생각하는 사람들을 고용합니다.

진실은 현대 시스템이 점점 더 복잡해지고 있다는 것입니다. 컴퓨터는 이제 게임 "Jenga"와 유사합니다. 여기서 "Jenga"는 다른 모든 것들에 의존합니다. 잘못된 부분을 잡아 당기면 오류가 발생하고 올바른 / 필요한 부분을 잡아 당겨도 여전히 오류가 발생할 수 있습니다. 시스템이 복잡할수록 코드를 더욱 강력하고 안전하게 만드는 방법을 생각하는 데 더 많은 시간을 할애 할 수 있습니다. 속도는 좋겠지 만 요즘 "XYZ"회사가 해킹 당하고 6 백만 고객의 신용 카드 번호가 도난 당했다는 소식을 들었을 때 속도가 많이 뒤쳐져 있다고 생각합니다.

고객은 자신의 프로그램이 안전하고 강력해야한다는 말을 듣고 싶지 않을 수 있습니다. 그러나 자동차에는 안전 벨트와 에어백이 필요하지 않으며 집에는 자물쇠와 문이 필요하다고 말할 수 있습니다. 그?

지나치게 생각하고 있다면 "콘크리트 한"전략을 선택하고 그 전략을 따라야한다는 점을 제외하고는 올바른 방법으로 진행하고 있습니다.

잘못 될 수있는 모든 것에 대해 생각하는 경향을 알고있는 것 같습니다.

숙련 된 신중한 개발자는 종종 진언을 따르는 법을 배웁니다. YAGNI실패 모드 분석이 사라진 잡초에 너무 질식 된 후 기민하고 민첩하며 생산적인 워크 플로로 돌아 가려고 할 때 필요하지 않습니다.

그러나 실제로 해당 수준의 관리가 전문성에 요구되는 수준 이상인 것을 작성하는 경우, 순 개념으로 "속도", "생산성"이 얼마나 좋은지에 의해 측정 될 수 있음을 알아야합니다 회사, 고객 및 소프트웨어 제품군 또는 구축하거나 유지 관리하는 제품군에 대한 귀하의 행동.

기억해:

• 접근 방식의 변화를 고려할 때 총 유지 관리 비용, 총 소유 비용 및 솔루션 배포 및 유지 관리 총 비용이 포함됩니다. 더 빨리 가고 더 많은 실수를하면 더 나아질 수 있습니다.

• 훌륭한 회사에서 일하는 경우 경력 제한 이동이 아닌 팀과 감독자와 논의 할 수 있습니다. 당신이 할 수 없다면, 지금 그것을 찾아 새로운 직업을 찾을 수있는 좋은 시간입니다.

내가 볼 수있는 것은 "당신은 점점 더 귀중 해지고 있습니다"입니다.

경험이 많을수록 피해야 할 것들에 대해 배우게되며 이것이 다른 사람들보다 나아지게합니다.

코드가 더 안전하고 유지 관리가 쉬워 질 것입니다.

• 당신이해야 할 일은 고객에게 왜 시간이 걸렸고 어떻게 유용한 지 설명하는 것입니다.
• 당신은 그들에게 당신의 지식의 깊이를 보여줄 필요가 있습니다.
• 당신은 왜 당신이 무엇을했는지, 그리고 어떻게 그들과 그들의 사업에 문제가되는지 이야기해야합니다.

내 제안은이 부분에 집중하는 것입니다.

의심 스러울 때 Knuth를 잘못 인용하면 ...

"조기 최적화는 모든 악의 근원입니다."

때때로 내가 가진 문제가있는 것처럼 보이기 때문에 내가 제안하는 것이 있습니다 ...

정말로 나를 위해 일하는 것은 ...

1. 모든 코드가 완료된 것처럼 단위 테스트를 작성하십시오.
   
2. 인터페이스를 문서화하십시오.
   
3. 인터페이스를 구현하십시오.

당신이 실제로 한 일 :

1. 모델 레이어 요구 사항을 통해 작업
2. 실제로 업무 분담을 설정합니다.
3. 실제로 작업 코드를 단계별로 진행할 수있는 환경에서 작업하면 훨씬 더 빠르게 작업을 수행 할 수 있습니다.

또한 초기 개발에서 주장에 의존합니다 ... 그런 다음 어떤 구제책을 구현해야하는지 파악하고 도달 할 수 없거나 테스트하기 어려운 코드를 작성하지 마십시오.

나는 당신이 당신의 코딩 표준을 고수해야한다고 생각하지만, 당신이 당신의 고객과 선입견을 갖도록하십시오. 많은 고객들은 좋은 소프트웨어를 구축하는 데 무엇이 / 비용이 필요한지 모릅니다. 그것들을 교육하는 것은 전문 개발자의 일의 일부입니다.

애자일이든 워터 폴이든 관계없이 클라이언트가 응용 프로그램이 기대하는 것에 대해 일종의 동의를 얻습니다. 너무 많은 개발자 (아마도 더 많은 영업 사원)가 모래 주머니에 죄를 범했습니다 . "그들은 그들이 매우 안전한 웹 사이트를 원한다고 말하지 않았습니다." 대부분의 경우 요청하지 않았기 때문입니다. "전자 상거래 사이트가 해킹 당해도 괜찮습니까?" 물론 그들은 관심을 갖고 왜 누군가가 보안에 침투 할 수 있도록 그것을 구축하겠습니까? 당신은 그들을 교육해야합니다.

고객이 지불 한 금액 만하고 있는지 확인하십시오. 서비스의 일부는 경험입니다. 고객은 요청하지 않아도 함정을 알기를 기대합니다. 요구 사항을 포함하는 것은 그들에게 달려 있습니다. 저렴한 것을 원하는 고객에게 전달하고 싶을 수도 있습니다.

해결해야하는 다른 모든 문제와 비교하여 버그의 실제 결과에 대해 생각하십시오.

잘못 작성된 코드를 작성하면 다음과 같은 결과를 고려하십시오.

1. 전체 데이터베이스는 격월마다 덤프됩니다. 백업이 복원되는 동안 48 시간의 가동 중지 시간
2. 고객 레코드가 서로 연결됩니다. 한 달에 $ 200 상당의 주문이 잘못된 고객에게 배송됩니다.
3. 주문은 일주일에 한 번 잘못된 상태에 빠집니다. 배송을 주문하지만 창고는 주문할 때마다 헬프 데스크에 연락해야합니다.
4. 2 주 정도가 지나면 앱이 중단되고 사용자는 2 분 분량의 데이터를 다시 입력해야합니다.
5. 한 달에 한 번 앱이 시작되면 중단됩니다. 사용자는 프로세스를 종료하고 다시 시작해야합니다.

첫 번째는 분명히 받아 들일 수 없습니다. # 2-# 5는 사업의 성격에 따라 달라질 수도 있습니다. # 2-# 5는 비즈니스가 직면하고있는 다른 문제와 관련하여 평가해야합니다.

이상적으로, # 2-# 5는 결코 일어나지 않을 것입니다. 현실에서 우선 순위가 상충되는 사람들은 월급에 서명하는 사람들이 결코 문제가없는 완벽한 코드를 작성하는 대신 다른 일을하고 싶어 할 것입니다. 다른 프로그램에서 더 심각한 버그를 수정하지 않고 # 5를 고치면 감동을받지 않습니다.

해결책은 여러 프로젝트에서 재사용 할 수있는 일반적으로 사용되는 기능을 가진 라이브러리 모음을 만드는 것입니다. 예를 들어 인코딩, 암호화, 암호 해독, 정규 표현식 평가 등과 같은 작업을 수행하는 StringFunctions.dll .NET 라이브러리가 있습니다. 이런 식으로 변경되지 않는 것을 계속 다시 작성할 필요가 없습니다.

파일 작성 작업을위한 랩퍼를 갖는 것도 많은 의미가 있습니다. 라이브러리는 모든 검사를 수행하고 null 또는 파일 (또는 유용한 것으로 간주되는 것)을 반환하는 GetFile ()이라는 메서드를 노출 할 수 있습니다.

어느 프로젝트에서 얼마나 많은 작업을 수행해야하는지 결정하는 법을 배워야한다고 생각합니다. 일부 프로젝트는 사소한 것일 수 있으므로 완벽하게 완료하는 데 모든 시간을 소비 할 필요는 없습니다. 모든 것이 견고한 암호화를 필요로하는 것은 아니며 모든 것이 수백만 명의 사용자로 확장되지는 않습니다.

백만 명 이상의 사용자를 위해 확장 가능한 프로그램을 작성하는 데는 현재 시간과 경험이 필요하지만 최대 1000 명 이상의 사용자가 응용 프로그램을 사용할 수 없다는 것을 알고 있다면 모두 지출 할 필요가 없습니다 그 시간을 완벽하게.

저는 이것이 프로그래밍 경력에서 중요한 단계라고 생각합니다. 이제 프로그래밍이 아닌 성숙도와 관련된 다음 단계로 넘어 가야합니다. 특정 프로젝트에 필요한 시간과 코드의 양을 올바르게 결정할 수 있어야합니다.

그리고 다른 모든 것들과 마찬가지로 연습을 통해서도이를 달성 할 수 있습니다. 따라서 프로젝트를 시작하기 전에, 이미 프로젝트를 진행하고있는 동안에도 경험을 통해이를 결정하십시오. 처음에는 몇 가지 안타와 누락이있을 수 있지만 시간이 지나면 완벽 해집니다 (코드가 아닌 의사 결정).

@Zilk, 저는 훌륭한 프로그래머가 아니며 1998 년부터 프로그래밍을하고 있습니다. 심지어이 문제에 직면하고 있습니다. 그러나 내가 깨달은 것은 궁극적으로 품질 문제입니다. 내가 오늘 죽으면 누군가가 내가 떠난 곳에서 지금하고있는 것을 집어들 수있을 것입니다. 프로그래밍 표준 (Universal)이어야합니다.

나는 지금 개발자에서 건축가로 이사했다. 관리로 이동하면 회선이 변경됩니다. 당신이 당신의 열정을 계속하고 싶다면 Architect가 될 수 있습니다.

처음에는 기술 아키텍트-> 솔루션 아키텍트-> 엔터프라이즈 아키텍트-> 최고 아키텍트 등입니다.

건축가로서 당신은 사람들을 성공으로 안내 할 것입니다. 수십 년간의 경험을 통해 프로그래밍을해온 당신과 같은 사람들은 다른 사람들을 인도하기 위해 활용할 수 있습니다.

더 높은 새처럼 그것은 더 많은 땅을 날아 다니며 당신의 경험도 볼 수 있습니다.

잘못된 구현을 더 빨리 프로그래밍하는 것보다 올바른 구현을 프로그래밍하는 것이 중요하다는 것도 알려 드리겠습니다. 최근에 내 후배 중 한 명이 무언가 잘못 프로그래밍했고 많은 돈이 들었습니다. 물론 우리는 더 일찍 제 시간에 전달했지만 아무 소용이 없었습니다! 같은 주니어가 문제가 발생하지 않았을 것이라고 코딩 했음에도 불구하고 가이드 역할을 부여 받았습니까? 나는 좋은지도를하는 것도 중요하다는 점을 강조하기 위해이 예를 제시하고 있습니다. 일부는이 직무를 상담직이라고 부릅니다.

또 다른 옵션은 코드 작성을 중단하고 문제를 미리 발견하는 데 전문 지식을 판매하는 것입니다.

다시 말해 컨설턴트 가 되십시오 .

많은 조직은 문제 를 일으키는 코드를 작성하는 데 몇 달을 소비 하기 전에 누군가가 문제를 발견 할 수 있도록 비싼 달러 (최고 달러가 아닌 경우)를 지불하게되어 기쁩니다 . 디자인에서 버그를 수정하는 것은 코딩, 테스트 및 배포 후에 버그를 수정하는 것보다 훨씬 저렴하고 쉽다는 것은 잘 알려져 있습니다.

많은 코드를 작성하지는 않을 것입니다. 그러나 실제 코드 행은 핵심 강점이 아니라 어떤 코드 행을 작성해야하는지 아는 것이 아닌 것 같습니다.

당신의 강점에 집중하십시오.
(그게 당신이 즐기는 것이라면 ...)

가장 좋은 방법은 빌딩 블록입니다.

항상 신뢰할 수있는 파일 구성 요소를 만들고 API 용으로 작성하고 같은 내용을 반복해서 쓰는 데 시간을 낭비하지 마십시오. 모든 문제를 한 번 생각하고 한 번에 해결하십시오.

아무도 이해하지 못하는 경우에 실패하는 코드를 디버깅하는 데 80 %의 시간을 소비하는 초보자는 아닙니다.

무엇보다도 잘못된 권한과 같이 발생할 수없는 문제를 해결하지 마십시오.

권한이 잘못되면 이미 잘못된 것이 있으므로 프로그램을 방탄하지 말고 수정해야합니다.

어떤 시점에서 당신은 항상 여부를 확인하는 대신 발로 자신을 쏘지 말아야합니다.

문서화에 시간을 소비하는 대신 코드를 자체 문서화하고 가능한 한 짧게 만드는 데 시간을 투자하십시오. 모든 중복 기능을 교체하십시오. 라이브러리를 축소하고 이름을 정확하게 바꾸십시오.

너무 열심히하지 마십시오. 그 어느 때보 다 더 많은 인간 지능, 지식 및 경험이 필요한 복잡성이 증가하는 직업에 종사하고 있습니다.

컴퓨터 처리 성능이 저하 될 수 있습니다 (아마도 곧 실속 될 수 있음).

따라서 현재와 미래의 큰 발전은 프로그래머들-고급 알고리즘과보다 효율적인 코드에서 나올 것입니다.

GTA 4와 GTA 5를 보면 그 차이가 놀랍습니다. 그러나 둘 다 동일한 하드웨어에서 실행됩니다. 이것은 10 년 전에는 필요하지 않았거나 이용할 수 없었던 매우 지능적이고 고급 인 프로그래밍 실습의 결과입니다.

또한 숙련 된 프로그래머는 미래에 최고 가치가 발생하는 엔지니어링과 같은 다른 직업과 마찬가지로 미래에 더 가치가있을 수 있습니다.

당신과 마찬가지로, 나는 14 세의 나이에 프로그래밍을 시작했습니다. 또한 처음 컴퓨터를 받았을 때도 (그 시점에서 몇 달 동안 공부했지만). 그러나 나는 지금 33 살이다. :-)

내 제안은 무언가를 개발할 때 각각의 걱정 (파일 사용 권한, 디렉토리의 파일 수 등)을 취한 다음 광대 한 경험을 모두 사용 하여이 정신에 대한 몇 가지 질문에 대답하는 것입니다.

• 코드에서 해당 문제를 올바르게 처리하는 데 얼마나 걸립니까?
• 제대로 다루지 않으면 나중에 물릴 가능성이 얼마나됩니까?
• 그것이 당신을 물면 결과는 무엇입니까?

그러한 대답으로 무장 한 그런 경험 많은 사람은 현명한 결정을 내리는 데 아무런 문제가 없을 것입니다. ;-)

이러한 유형의 요구 사항을 제시하는 것은 "재향 군인"의 책임이며, 여기에는 무엇이 잘못 될 수 있는지 식별하고주의를 기울여야 할 잠재적 문제를 결정하는 것이 포함됩니다.

앱을 개발하는 동안 가능한 모든 기준을 아는 것이 양질의 제품을 개발하는 데 가장 중요한 것입니다. 당신은 이것에서 잘하고 있습니다. 할 수있는 한 가지는 요구 사항을 품질 수준으로 분류 한 다음 지정된 마감일로 수준을 매핑 할 수 있다는 것입니다. 이러한 방식으로 프로젝트 마감일을 쉽게 맞출 수 있습니다.

Edsger Dijsktra의 말에 따르면 : "디버깅이 소프트웨어 버그를 제거하는 프로세스 인 경우 프로그래밍은 버그를 처리하는 프로세스 여야합니다." 코딩하는 데 시간을 소비하는 것은 학습의 문제 일뿐입니다. 나는 여전히 비교적 젊은 프로그래머 (20ish 읽기)이며 한 번만 완전히 코딩 할 수 있기를 갈망합니다. 1 시간의 계획과 10 분의 코딩은 10 분의 계획, 1 시간의 코딩 및 3 개의 디버깅보다 훨씬 좋습니다.