프로그래머가 갖춰야 할 방어적 프로그래밍 사고의 30가지 원칙

여러 가지 온라인 문제를 분석해 보면 많은 문제가 아주 드문 문제가 아니라 명백한 작은 실수가 축적되어 발생한다는 것을 알 수 있습니다. 왜 작은 실수를 하는가? 어쩌면 운이 좋아서일 수도 있고, 부분적인 혜택만 보기 때문일 수도 있습니다. 어떤 예를 보면 '실수하면 뛰어난 사람이 된다'는 횡설수설이 있는 것은 사실이지만, 많은 경우의 통계를 보면 대부분의 경우 긍정적인 결과가 나오지 않는 것으로 나타났다.

이 글은 제가 요구사항 검토, 코딩, 프로젝트 실행 단계에서 요약한 원칙을 정리한 것입니다. 이러한 원칙이 문제를 직접적으로 해결할 수는 없지만 동작의 모든 단계를 최대한 최적화하고 실수를 방지할 수 있습니다. 방어적 프로그래밍 사고와 행동 습관의 관점이 발생합니다.

의사소통의 원리

다양한 시나리오에서는 다양한 커뮤니케이션 도구를 사용합니다.

IM(인스턴트 메신저)을 통한 타이핑은 비용이 적게 드는 일반적인 커뮤니케이션 방법으로, 팀 내의 간단한 문제 전달 및 다양한 정보 알림에 적합합니다. 하지만 복잡한 질문이 여전히 불명확하고 3분 동안 타이핑을 해도 진전이 없다면 즉시 음성이나 대면 등 좀 더 효율적인 의사소통 방법으로 전환해야 한다.

문자 통신에 비해 음성 통신은 톤이 있어 순수 텍스트의 무뚝뚝한 톤 문제를 피할 수 있고, 단위 시간당 더 많은 정보를 출력할 수 있어 더 효율적입니다. 가끔 두 사람이 그룹 내에서 한 명씩 이야기를 나누고 5분 동안 토론을 하는 것을 보는데, 결국 그들이 말한 내용이 동일하지 않다는 것을 알게 됩니다. 시간에 맞춰 음성으로 전환하시면 1분안에 문제를 찾아보실 수 있습니다.

말에 비해 대면 커뮤니케이션에는 표현이 추가되어 강한 호소력을 더 잘 표현할 수 있습니다. 특히 매우 긴급한 문제가 발생할 경우 직접 만나는 것이 가장 좋은 방법입니다. 가끔 온라인 문제가 발생하여 다른 사람들이 IM을 통해 답변하기를 기다리고 있는데, 이는 최적의 정지 손실 시간에 영향을 미칠 수 있습니다.

확증 편향을 피하세요. 반대 의견은 더 많은 폭로로 이어질 수 있습니다.

확증 편향은 '좋은' 뉴스, 즉 자신의 생각을 확인할 수 있는 뉴스만 듣고, '나쁜' 뉴스는 죽이는 것, 자신의 생각과 다른 뉴스와 생각은 받아들이지 않는 것을 말합니다. 이러한 현상은 장기적으로 유리한 이의제기를 수용할 수 없게 만들 수 있습니다.

이런 상황은 빅데이터 시대의 정보 흐름을 보면, 정밀한 알고리즘을 거쳐 자신이 어떤 관점을 갖고 어떤 관점을 좋아할 때 더욱 분명해질 것이다. 정확한 추천 알고리즘은 귀하가 동의하는 정보를 지속적으로 추천하기 위한 것입니다. 잘못된 견해를 바로잡는 부정적인 정보는 없을 것입니다. 이런 식으로 잘못된 견해를 강화하면 자신을 부를 수 없는 정보 고치에 빠지게 될 것입니다.

왜냐하면 뇌의 구조는 이성적 자아와 감정적 자아로 구성되어 매우 복잡하기 때문인데, 다른 사람의 반대에 대해서는 감정적 자아가 다른 사람의 반대를 공격으로 받아들이는 경향이 있기 때문이다.

그러므로 우리는 행동을 취하기 전에 다른 사람의 의견을 주의 깊게 생각하도록 감정적 자아를 훈련해야 합니다. 반대되는 관점은 자신의 생각에 잠재된 위험을 드러낼 수도 있고, 더 나은 계획을 깨달을 수도 있습니다. 능동적인 변증법적 사고 능력을 단련하여 '편안하게 들리는 견해'와 '장기적으로 자신에게 유익한 견해'를 구별하세요.

예시를 포함한 시연은 의사 결정을 위한 참고 자료로만 사용될 수 있습니다.

혼자서 문제에 대해 생각하거나 문제를 논의할 때 다음과 같은 두 가지 관점이 자주 나타납니다.

  • 지난 프로젝트에서는 기술 솔루션 A를 사용했는데 효과가 매우 좋았으므로 이번 프로젝트에도 기술 솔루션 A를 사용해야 합니다.

  • 그런 문제에 직면한 동급생이 있는데 이 친구가 이 방법으로 해결했으므로 우리도 똑같이 할 수 있습니다.

우연한 성공을 필연적인 결론으로 ​​받아들이는 현상. 그것은 토론과 자신의 경험 모두에서 나타날 수 있습니다. 이러한 경험은 의사결정의 참고사례로 활용될 수는 있지만, 직접적으로 필연적인 결론으로 ​​간주될 수는 없습니다. 과학적 방법은 다양한 시나리오와 배경에 따라 대규모 통계를 작성하여 다양한 시나리오에 따라 더 나은 결정을 내릴 수 있도록 해야 합니다.

최고의 아이디어를 선택하고 결정을 내리기 전에 가중치를 조정하세요.

기술적인 해결책을 논의하든, 논란이 되는 문제에 대한 소통을 하든, 모두가 각자의 관점에서 다른 의견을 가지게 될 것입니다. 사람마다 더 고민하는 부분이 있고, 입장도 다르고, 고민도 다릅니다. 스스로 결정을 내려야 한다면 토론 과정에서 각 아이디어의 이유를 이해해야 그 기본 논리를 이해하고 자신의 관점에서 그 무게를 판단할 수 있습니다. 다양한 관점의 아이디어를 종합적으로 고려하여 자신의 관점에서 보다 종합적으로 고려하고 결정을 내릴 수 있습니다.

이개푸 씨는 졸업 논문 주제를 선택할 때 위험과 안정성이라는 두 가지 주제를 선택했습니다.

  • 딥러닝을 선택하면 졸업이 연기될 수도 있고 리스크도 크지만 성공하면 단숨에 유명해질 수 있다.

  • 평범한 과목을 선택하면 위험부담 없이 제때 졸업할 수 있지만, 큰 성과를 거두지는 못할 것입니다.

사람마다 감수하는 위험이 다르기 때문에 선택도 다르며, 물론 장기적인 이점도 다를 것입니다.

입력 시 중요한 내용은 별도의 메시지를 보내세요.

텍스트 내용의 단락이 큰 경우 상대방이 반드시 모든 문장을 주의 깊게 읽을 필요는 없습니다. 중요한 질문은 별도로 게시해야 하며 다른 콘텐츠와 결합해서는 안 됩니다.

예시 1: 문제 해결 시 한 문장으로 두 가지 질문을 했고, 상대방이 "예"라고 대답했습니다. 상대방의 결론을 토대로 계속해서 문제를 해결해 나갔습니다. 하루 정도 조사를 해본 결과 문제B의 상황은 B1이 아니어야겠다는 생각이 들어서 다시 상대방에게 확인했는데 상대방은 내가 말한 앞 문장만 봤고 뒷 문장은 보지 못했다고 한다”고 말했다. 문제 B의 상황은 B1이겠죠?"

사례 2: 프로젝트가 시작되자 파트너에게 감사의 마음을 표현하는 문장을 보냈고, 상대방은 "어떤 문제를 해결하는데 협력해야 합니까?"라고 답했습니다.

여러 팀에서 작업할 때 가치를 강조할 수 있는 회의록

회의 주최자는 회의의 결론과 할 일을 실시간으로 기록해야 합니다. 그렇지 않으면 며칠, 몇 주가 지나면 모두가 서로 다른 결론을 내리고 갈등을 겪게 되며 중요한 할 일을 잊어버리게 됩니다.

내부팀 입장에서는 이런 문제가 큰 문제가 되지 않을 텐데, 결국 모두가 오랫동안 협력해왔고, 작은 실수도 용인할 수 있겠지만, 우리는 종종 용납되기 때문에 이 버릇을 잃을 수는 없습니다. 더 큰 커뮤니티에서는 회사가 수평적 팀과 협력하거나 심지어 외부 회사와 협력할 때 이 문제의 부정적인 영향이 배가되기 때문입니다.

맞춤형 기능을 제공하는 일부 타사 공급업체의 경우 많은 팀과 연결되며, 외부 세계와 소통할 때 연구 개발이 아니라 영업이나 비즈니스와 같은 다른 직위에 있는 학생들과 소통합니다. 도킹 과정에서 오해로 인해 필연적으로 잘못된 답변을 하게 되며, 잘못된 결론을 바탕으로 불합리한 기술 솔루션을 설계하게 되면 프로젝트 착수 초기까지 문제가 발견되지 않습니다. 상대방이 잘못 말했거나 내가 잘못 이해한 것입니다.

요구사항 검토 및 일정 수립 단계의 원칙

모두가 제품 관리자입니다. 수요가 방향을 결정합니다.

소프트웨어 개발은 ​​단지 주어진 업무만을 위한 것이 아니라 사용자의 요구를 충족시키고, 실질적인 문제를 해결하며, 가치를 창출하는 것입니다. R&D에는 제품 관리자의 요구에 따라 코드를 작성하는 것뿐만 아니라 그 합리성에 대해 생각하고 비판하는 것도 필요합니다. 단순히 코드 작성을 수작업의 대가로 여기기보다, 사용자의 관점에서 제품의 합리성을 면밀히 분석해야만 보다 가치 있는 코드를 작성할 수 있습니다.

기술은 수단이지 목적이 아니다

요구사항 분석과 시스템 설계는 두 가지 진보적인 단계입니다.

요구 사항 분석 단계에서는 세부적인 기술 세부 사항을 고려해서는 안 됩니다. 그렇지 않으면 "기술이 너무 어려워서 이 요구 사항을 충족할 수 없습니다." 또는 "이 작업 부하가 너무 큽니다. 요구 사항을 변경하여 작업 부하가 줄어들도록 하십시오." 많이 줄어들 것이다." 훌륭한 아이디어가 유산되는 현상이다. 초기에는 사용자의 실제 요구가 아닌 기술의 관점에서 보다 가치 있는 제품이 구현됩니다. 제품의 가치는 기술의 난이도가 아니라 사용자의 요구에 따라 결정되어야 합니다. 물론 기술구현 비용을 고려하지 않는 것이 아니라 순서가 있어야 하며, 요구사항이 결정된 후에 기술구현 비용을 확정해야 한다. ROI가 더 높아질 수 있습니다.

몇 가지 요구 사항이 있지만 일부 기술 솔루션의 경우 비용이 매우 낮습니다. 요구 사항을 완료하는 데 몇 시간이 걸리지만 의미 없는 요구 사항이고 의미 없는 기술 솔루션이라면 더 많은 작업을 수행하는 것이 무슨 소용이 있습니까?

단순화된 단계의 제품은 더 큰 가치를 갖습니다.

사용자 상호작용이 필요한 제품의 경우 사용자 운영 비용이 낮을수록 시간 비용은 낮아지고 가치는 높아집니다. 이는 제품을 고려할 때 기능을 그대로 유지하는 것을 전제로 기능을 추가하는 것이 더 쉽지만 기능을 추가하는 대신 중복되는 기능을 최대한 삭제하는 것이 필요합니다.

팀 간 협업하고 모든 내부 일정이 조정된 후 외부와 소통합니다.

개인에서 팀으로, 회사 전체로, 그리고 외부 기업으로 커뮤니티가 점차 늘어나고, 커뮤니케이션 비용도 점차 늘어나게 됩니다. 프로젝트 일정 등 통일된 결론이 필요한 일부 문제의 경우 커뮤니티 규모에 따라 소규모부터 대규모까지 점진적으로 결정되어야 합니다. 외부 팀과 프로젝트 시작 날짜를 확인하지 마세요. 내부 시간이 일치하지 않는다는 사실을 확인한 후 나중에 외부 팀과 조정하세요. 한편으로는 의사소통 비용이 매우 높을 뿐만 아니라, 내부 프로세스의 혼란도 노출됩니다.

일정 요구 사항을 뒤집고 휴일에 주의를 기울이고 공동 디버깅 시간을 보장합니다.

때로는 매우 긴급한 요구 사항이 발생하여 일정을 변경해야 하는 경우가 있습니다. 시간을 압축해야 한다면 개발 시간을 압축하고 공동 디버깅 시간이 충분한지 확인하세요. 공동 디버깅으로 인해 문제가 더 빨리 노출될 수 있기 때문입니다. 문제를 사전에 노출해야만 자원을 조율하고 문제를 최대한 빨리 해결할 수 있습니다.

대규모 휴일 하루 전에 공동 디버깅을 시작하지 마십시오. 특히 여러 팀이 참여하는 대규모 프로젝트의 경우 한 사람이 휴가 중이어서 공동 디버깅을 시작할 수 없고 결국 전체 프로세스에서 공동 디버깅을 시작할 수 없기 때문입니다. 시간.

파트너의 작업량을 평가하지 마십시오

형제 팀이나 심지어 외부 회사와의 협력에 있어서 상대방이 기능을 추가하거나 수정해야 하는 상황이 발생할 수 있습니다. 본인 입장에서는 이 기능이 완료되는 데 몇 분밖에 걸리지 않지만, 코드 변경 권한이 없는 한 상대방의 작업량을 본인 입장에서 평가하지 마세요.

한편으로는 사람마다 각 기능에 대한 친숙도가 다르고, 상대방은 코드를 막 넘겨받아서 별로 익숙하지 않을 수도 있습니다. 반면, 각 팀에는 자체 프로세스가 있으며 전체 기능 수정을 완료하는 데 드는 한계 비용이 낮지 않습니다. 현재 기능에 맞게 코드를 개발하고 수정하는 것뿐만 아니라 확장성과 안정성, 테스트 등 팀의 협업까지 고려해야 하기 때문입니다.

개발 단계의 원칙

완벽한 문서화는 장기적인 전략적 비전의 표현입니다

자신뿐만 아니라 프로젝트에 참여할 수 있는 전체 팀을 커뮤니티로 대하십시오. 한 번 문서를 작성하는 로컬 관점에 비해, 보다 글로벌한 관점에서 장기적인 이점을 살펴볼 수 있습니다. 다중 팀 협력 요구 사항의 경우 기록되지 않으면 중요하지 않은 매개 변수처럼 보일 수 있으며, 이는 많은 팀의 의사소통 및 협업 비용을 수반할 수 있습니다. 다른 사람의 프로젝트를 유지 관리할 때는 코드나 주석을 보면 전체 프로젝트를 이해할 수 있습니다. 그러나 일부 복잡한 프로젝트와 보다 복잡한 로직의 경우 코드에서 전체적인 구조를 파악하기 어려운 경우가 있는데, 이때 문서화의 중요성이 드러납니다.

문서를 유지하는 데 비용이 들지만 이는 단기적인 비용입니다. 장기적으로 문서화를 통해 향후 더 많은 통신 비용을 방지하고 익숙하지 않은 논리를 살펴보는 데 더 많은 시간을 소비하는 것을 피할 수 있습니다. 코딩이 완료된 후 뒤집어서 다시 시작하는 것에 비해 문서 수정 비용은 높지 않습니다.

단기 균형과 장기 균형의 두 끝을 마주했을 때, 당신은 어느 끝에 무게를 둘 의향이 있습니까? 인생은 마라톤이지만 문서를 작성하지 않으면 단기적으로는 편할 것입니다. 그러나 장기적인 관점에서 보면 장기적인 비전, 더 넓은 관점, 장기적인 전략적 비전을 갖는 것이 실제로 더 중요합니다.

또한, 문서를 작성해야 한다고 생각하는 사람들도 있지만 복잡한 프로젝트에만 작성해야 하며 간단한 프로젝트를 작성할 필요는 없습니다. 실제로 간단한 프로젝트는 습관을 훈련할 수 있는 좋은 기회입니다. 문서를 작성하는 습관이 없었다면 대규모 프로젝트를 맡게 되면 문서 작성에 익숙하지 않다는 것을 알게 될 것입니다. 관련되어 있어 큰 압력을 가하면 동작이 쉽게 변형됩니다. 움직임이 일관되고 매끄럽게 유지되도록 하려면 평소에 좋은 습관을 키워야 합니다.

문서를 유지하는 동시에 문서 인덱스도 유지합니다.

단일 프로젝트의 문서라면 구조가 비교적 단순하고, 여러 버전을 반복하더라도 전체적인 구조가 비교적 명확합니다. 하지만 모두가 함께 녹음하는 팀이라면 새로운 주제 페이지가 추가되면 사람마다 레벨이 달라져서 다음번에 찾기가 매우 어려울 것입니다. 이때 인덱스의 중요성은 명백합니다. 즉, 문서를 추가한다는 것은 단일 문서를 추가하는 것뿐만 아니라 해당 인덱스를 유지하는 것이기도 합니다.

이는 실제로 유형이 다양하고 분류가 유연하며 수준이 끊임없이 변화하는 현대 전자 문서 저장의 문제와 관련이 있습니다. 팀의 규모가 커지고 프로젝트 수가 늘어나면 장애는 계속해서 엔트로피의 증가로 이어질 것입니다. 더 깔끔하게하려면 인덱스가 필수적입니다.

코딩 시간은 30% 미만이어야 합니다.

프로젝트는 요구사항 검토, 기술 솔루션 연구, 문서 작성, 코드 작성, 테스트 및 출시부터 시작됩니다. 순수 코딩 시간의 비율은 크지 않습니다. 특히 디자인이 완벽하고 코드가 한 번에 작성되면 더욱 그렇습니다. 코딩 시간이 큰 비중을 차지한다면 코딩 과정에서 절반만 썼다가 나중에 갑자기 어떻게 써야 할지 몰랐거나, 다 쓰고 나서 디자인이 심각하다는 걸 알았기 때문일 가능성이 높습니다. 나는 그것을 전복하고 다시 시작해야 했습니다.

코드는 단순히 정상적으로 실행되는 것이 아니라 다른 사람이 이해해야 합니다.

학교 기간 동안 정상적으로 운영될 수 있는 한 커리큘럼 설계 프로젝트입니다. 교사가 변수 명명의 의미를 이해할 수 있는지 여부는 중요하지 않습니다. 이 프로젝트 때문에 앞으로는 아무도 관심을 두지 않을 것입니다. 그러나 엔터프라이즈 프로젝트에서는 프로젝트가 자체적으로 유지 관리되어야 할 뿐만 아니라 이를 유지 관리하기 위해 팀의 다른 학생들도 참여해야 합니다. 따라서 코드에 대한 요구사항은 실행이 가능해야 할 뿐만 아니라 다른 사람이 이해할 수도 있어야 합니다.

먼저 주석을 작성한 다음 코드를 작성하세요.

코멘트는 작성되지 않으나, 코딩시 작성해 주셔야 합니다.

코드와 댓글은 분리할 수 없는 통일체입니다. 지식과 행동의 통일성이라는 개념과 마찬가지로 지식과 행동은 밀접하게 결합되어 있으며 둘은 분리될 수 없습니다. 몇 초 안에 몇 단어를 입력하고 메모를 작성하면 나중에 볼 때 더 많은 시간을 절약할 수 있습니다. 어떤 사람은 내가 이해할 수만 있으면 나중에 내가 이해하지 못하면 다른 사람도 이해하지 못할 것이며 나와는 아무 상관이 없다고 말할 수도 있습니다. 본인의 관점에서만 보더라도 꼭 그렇지는 않습니다. 믿지 못하시겠다면 2개월 전에 작성하신 코드를 보시면 됩니다. 더욱이, 더 큰 커뮤니티 이익의 관점에서 볼 때, 주석을 작성하는 것은 자신을 위한 것이 아니라 전체 그룹의 이익을 위한 것입니다. 처음에 코드를 작성하면서 주석을 쓰는 것이 익숙하지 않다면 코드를 작성하기 전에 먼저 주석을 작성해도 됩니다.

외교는 작은 문제가 아니며, 외부 인터페이스, 변수 변경은 가능한 한 빨리 동기화되어야 합니다.

외부 인터페이스 프로토콜은 주의해야 하며 확인 후 수정해서는 안 됩니다. 다만, 초기 검토가 포괄적이지 않아 수정이 필요한 경우에는 최대한 빨리 수정한다. 전역 검색 및 교체 비용은 매우 낮지만, 특히 테스트 후반 단계에서 파트너의 수정이 필요한 경우 통신 비용이 훨씬 더 높아질 수 있습니다. 업스트림과 다운스트림을 파악하고 변경이 빠를수록 모든 사람의 상대적 비용이 낮아집니다.

모듈과 기능은 단일 목적의 원칙을 따릅니다.

각 기능은 한 가지 작업만 수행하며, 각 모듈의 기능은 가능한 한 단일합니다. 각 모듈은 해당 인터페이스를 외부에 노출하여 "높은 응집력과 낮은 결합"을 달성합니다. 말은 아주 간단해 보이지만 요구 사항의 첫 번째 버전에서 고도로 결합된 코드를 작성하면 통제할 수 없는 후속 유지 관리가 발생하고 클래스당 수천 줄이 발생하게 됩니다. 나중에 바꾸려고 하면 비용이 기하급수적으로 늘어나게 됩니다. 각 기능마다 30줄을 초과하지 않도록 하세요. 각 수업마다 900줄을 넘지 않도록 노력하세요.

이름은 겉과 속이 같아야 하며, 이름을 보고 뜻을 알아라.

변수는 코드에서 가장 작은 단위이며 이름 지정의 품질은 가독성과 많은 관련이 있습니다. 예를 들어 이름이 keyString이라면 그 의미는 키 값의 문자열이어야 하는데, 그 값을 사용할 때 사용한다면 다른 사람이 읽기에 큰 장애가 될 것입니다.

인코딩: 특별한 트릭을 사용하지 마세요

가독성 측면에서 언급할 가치가 없는 매우 복잡한 기믹 코드입니다. 오픈 소스일 수 있다면 스타일을 보여주는 것으로 간주될 수 있고, 그렇지 않으면 자체 홍보입니다.

커밋 메시지는 눈에 띄지 않지만 큰 정보를 포함합니다.

Commit 메시지를 인덱스로 사용할 수 있어 반복적인 프로세스를 검토하는 데 편리할 뿐만 아니라 롤백에도 편리합니다. 각 커밋 메시지는 모듈 및 함수의 단일 목적과 유사해야 하며, 하나의 함수만 수정하도록 시도해야 합니다. 그리고 커밋 메시지는 [브랜치 이름][수정된 내용]과 같은 고정된 형식을 갖는 것이 좋습니다. 더 자세한 내용을 원하시면 [코드 유형]을 추가하여 함수인지 버그 수정인지 구분할 수 있습니다. [bugId]를 추가하여 해당 버그 공간에 연결할 수도 있습니다. 이 습관은 통합되고 롤백될 때 그 가치를 깨닫습니다.

코드 리뷰는 입력과 출력 이후의 피드백이며, 코드를 개선하는 가장 빠른 방법 중 하나입니다.

코드 검토: 누군가 내 실수를 발견하면 설명하려고 하기보다는 감사해야 합니다. 운동할 때와 마찬가지로 먼저 책에 있는 이론을 읽고, 연습하고, 마지막으로 코치에게 피드백을 구하세요. 가끔 우리는 우리가 하고 있는 행동이 옳다고 생각하지만, 출력 후 코치의 피드백을 찾아보면 부주의한 세부 사항으로 인해 발생하는 많은 실수를 바로잡을 수 있습니다. 코드 리뷰도 마찬가지입니다. 때로는 자신의 글이 완벽하다고 생각하지만 실제로는 허점이 가득할 수도 있습니다.

균형을 맞추지 않으면 실패한 데이터도 필요합니다.

일부 로직 처리의 경우 투명 전송을 위해 성공 결과를 출력합니다. 성공 사례만 처리하면 되지만 실패 사례도 처리해야 합니다. 실패한 데이터는 일시적으로 쓸모가 없더라도 실패율을 계산하고 문제를 분석할 수 있습니다.

테스트 단계의 원리

사용자 작업과 관련된 제품 기능의 경우 교차 테스트를 통해 문제를 더 쉽게 찾을 수 있습니다.

사용자마다 조작 습관이 다르기 때문에 사용자 조작과 관련된 제품 기능의 경우 항상 동일한 QA 테스터를 사용하면 고정된 조작 습관으로 인해 숨겨진 버그를 찾기가 쉽지 않을 수 있습니다. 이때 가능한 많은 "사용자" 작업을 수행하고 다양한 작업 습관을 경험해 보면 문제를 찾는 것이 더 쉽습니다. 범위를 더욱 확장하여 서로 다른 입장의 학생들이 함께 사용하고 경험하고 불만을 토로한다면 실제 사용자의 경험 문제를 더 빨리 발견할 수 있을 것입니다.

풀리지 않는 어려운 문제, 연구 아이디어를 시도해 보세요

때로는 너무 어려워서 하루만에 풀 수 없는 문제에 직면할 때도 있습니다. 주로 두 가지 상황이 있습니다.

  • 아이디어가 잘못되었습니다.

  • 알려지지 않은 지식이 너무 많습니다.

아이디어가 틀리면 지금 당장 후퇴하고 싶을 수도 있고, 왜 이 기능을 개발하고 싶은지 생각해 볼 수도 있고, 심지어 다른 더 간단한 해결책이 있는지 수요 수준으로 돌아가고 싶을 수도 있습니다. 더 높은 관점에서 보면 지역 세부 사항에 얽매이거나 전화를 걸 수 없는 상황을 피할 수 있습니다.

모르는 지식이 너무 많으면 이 문제를 직접 해결할 필요는 없고, 연구한다는 생각으로 관련 지식을 모두 익히면 이 어려움이 쉽게 해결될 가능성이 있다. 시간이 부족하다면 다른 사람에게 물어보고 기록하고, 나중에 스스로 요약해서 문제 해결을 통해 얻을 수 있는 성장의 기회를 포착해 보세요.

출시 후 원칙

우연의 일치, 이상한 승리로

운에 따른 기습 승리는 거의 없으며, 충분한 긍정적인 힘과 약간의 추가 힘이 있어야만 최종 승리를 거둘 수 있으며, 프로젝트를 할 때도 마찬가지입니다.

프로젝트를 더 빠르고 효율적으로 완료하려면 일일 누적 없이는 할 수 없습니다. 프로젝트의 시작은 끝이 아닌 성장의 시작입니다. 프로젝트는 많은 경험과 자료를 제공할 수 있으며, 이는 자신의 입력 및 출력에 대한 일종의 피드백으로 사용될 수 있어 단점을 찾고 다음에 동일한 실수를 방지할 수 있습니다.

혼자가 아닌 회사의 후광 아래서 성장하라

여가 시간에는 무엇을 하시나요? 부업을 찾으시나요? 단기적으로는 어느 정도 추가 수입이 생기는 것은 사실이지만, 장기적으로는 수입이 30% 늘어나더라도 본질적인 변화는 없을 것입니다. -전자제품, 의류, 생활필수품까지. 개인의 힘이 너무 약하기 때문에 회사의 아우라 아래에서 프로젝트를 보다 효율적으로 완수한다는 전제하에 개인의 성장을 이루는 것이 좋습니다.

한편으로는 회사의 플랫폼에 더 많은 리소스가 있고, 다른 한편으로는 회사 프로젝트의 성장에 따라 한계 배송 비용이 더 낮기 때문입니다. 기존 프로젝트를 기반으로 그와 관련된 기본 원리를 깊이 파고들어 더 빠르게 축적하고 성장합니다. 단순한 프로젝트를 할 때는 기본원리의 역할이 명확하지 않지만, 매우 복잡한 프로젝트의 경우 기본원리의 지원이 필요할 때 축적된 기술은 분명한 효과를 발휘하게 됩니다.

온라인 문제 앞에서 불안은 의미가 없습니다. 중요한 것은 즉각적인 해결책을 찾는 것입니다.

과거에 대해 걱정하거나 미래에 대해 걱정하는 것은 온라인 문제에 있어서는 도움이 되지 않습니다. 현재 순간에 집중하고, 침착하고 적극적으로 해결책을 모색하세요. 실패는 우리가 어떻게 대응하느냐에 따라 개인의 성장이나 자기 파괴의 동기가 될 수 있습니다. 당신을 이길 수 있는 것은 그 누구도 아니고 그 무엇도 아니라 바로 당신 자신입니다. 온라인에서 문제가 발생하면 다음 두 가지 조치를 취해야 합니다.

  • 현재 상황을 해결하는 방법.

  • 이유를 검토하고 다음번에는 같은 실수를 저지르지 않도록 하세요.

'온라인에서 사고가 발생했다'는 현 상황을 볼 때, 온라인에서 사고가 발생했을 때 최우선적으로 해결방안을 찾는 것이 최우선이다. 특히 손실이 지속적으로 확대되는 경우에는 Stop Loss가 매우 중요합니다. 이때 모든 작업이 매우 중요합니다. 문제가 매우 복잡하다면 더 많은 사람들에게 전화하는 것을 잊지 마십시오. 상사와 경험 많은 동급생을 그룹에 끌어들이고 결국 서두르면 종합적으로 생각하지 못할 수도 있습니다. 뉴스가 안 보이면 직접 전화해 보세요.

이유를 분석해 보면 팀워크가 많이 필요한 복잡한 프로젝트라면 사실 이유도 많고, 여러 각도에서 분석하면 다른 결과가 나올 수밖에 없습니다. 복습회에서는 특히 내성적인 학생들의 경우 두려워하기보다는 객관적인 실제 상황을 최대한 표현하려고 노력합니다. 모임에서 말하지 않고, 모임 후에 후회하는 일을 피하고, 표현해야 할 때 표현하는 데 인색하지 마세요.

내 관점에서는 '이 온라인 문제가 나와 관련이 없는 한' 관심을 가질 필요가 없다는 것이 아닙니다. 이런 문제는 아주 좋은 부정적인 교재이며, 자신과 관련이 없더라도 다음번에 실수하지 않기 위한 자료로도 활용할 수 있습니다.

예를 들어, 이 글에 나오는 원칙 중 일부는 나와는 관련이 없지만, 이러한 문제를 보고 나 자신도 같은 실수를 저지르지 않기 위해 요약을 만들었습니다. 최악의 경우는 심각한 실수를 하여 큰 손실을 입는 경우입니다. 고통스러운 경험 앞에서 벗어날 것인지, 적극적으로 대응할 것인지는 자신의 태도에 달려 있다. 고통에 압도당하지 말고, 고통을 성찰의 먹이로 삼으십시오. 고통 + 반성 = 성장.

사람이 제안하면 하나님이 처리하시느니라

노력과 결과를 분리하고, 그 관계는 목표를 추구하는 것과 액세서리를 추구하는 것과 비슷합니다. 때로는 많은 대가를 치렀지만 그 결과가 너무 안타깝기 때문에 이때는 아들러의 주제분리법을 활용해 보겠습니다. 기여는 우리가 통제할 수 있는 것이지만 결과는 그렇지 않기 때문에 노력과 결과를 분리해야 합니다.

또 다른 관점에서는 골대와 액세서리의 관점에서도 생각해 볼 수 있다. 우리가 결과를 추구한다면, 실패한다면 참으로 슬픈 일이 될 것입니다. 하지만 결과가 부수적이고 과정이 목표라면 결과는 더 이상 중요하지 않습니다.

정중한 상호작용

" 일상의 행동을 최적화하기 위해 업무에서 어떤 원칙을 요약하고 있습니까? " 댓글 영역에서 누구나 채팅을 할 수 있습니다. 좋아요 수가 가장 많은 친구 3명에게는 8월 29일 오후 9시에 추첨을 통해 디디 맞춤형 컴퓨터 가방을 드립니다.

c8df45c37d7c5d032abb9ed7a2a6b1ff.png

추천

출처blog.csdn.net/DiDi_Tech/article/details/132439888