우리 모두는 학습 능력이 중요하다는 것을 알고 있습니다. 그렇다면 학습 능력은 어디서 오는 것일까요? 책을 읽고 수업을 듣는 것 외에, 어떻게 실천 속에서 성장을 배울 수 있습니까?

웨이보는 내가 전에 대략적인 개념을 말했다. 능력이란 무엇인가? 문제에 대한 태도와 문제를 처리하는 생각과 방법.

먼저 태도를 말하다.

가끔 서버에서 50 1 오류가 발생할 수 있습니다. 높지 않을 수도 있습니다 (Zhihu 도 여러 번 나타남). 많은 프로그래머, 예, 많이, 보이지 않는 척, 신경 쓰지 않거나 이상한 성격 문제. 이것이 바로 태도의 문제이다.

이후 고부하 또는 기타 이유로 갑자기 50 1 오류가 자주 발생했습니다. 심층적인 원인을 따지지 않고, 여러 가지 변명을 찾는다. IDC 서비스 업체가 좋지 않다. 서버 브랜드가 좋지 않다. 운영 체제가 좋지 않다. 데이터베이스가 좋지 않다. CDN 이 좋지 않다. 인터넷 상태가 좋지 않다. 웹 서버가 좋지 않다. 심지어 사장에게 우리가 DDOS 라고 직접 말할 수도 있다. 네, 사장님을 도와 여러 명의 보안 전문가 상담을 했는데 결국 DDOS 가 아니라 프로그래머가 너무 형편없다는 것을 알게 되었습니다. ) 을 참조하십시오

바로 이런 태도, 충격적이다. 만약 당신이 문제에 민감하고, 어떤 사소한 문제에 대해서도 충분한 민감도를 가지고 있다는 것을 안다면, 당신은 빠른 성장의 기초를 갖게 될 것이다. (조지 버나드 쇼, 자기관리명언) 문제에 대한 민감성은 매우 중요하다. 많은 성능이나 프로그램 논리상의 치명적이지 않은 버그는 날카롭지 않을 때는 발견할 수 없지만, 일단 특수한 장면에 들어가면 갑자기 폭발한다. 만약 네가 좀 더 예민하다면, 너는 이번 위기의 위험을 낮출 것이다.

두 번째 태도는 문제를 해결하는 태도이다. 어떤 사람들은 자신의 해결책에 대해 자신감이 넘치고, 만유의 실수가 없다고 생각하지만, 어떤 사람들은 다른 길을 찾을 것이다. 예를 들어, 내 서버는 안전하고, 정확해야 하며, 가능한 한 엄격하고 포괄적이어야 한다고 말하지만, 비밀번호를 데이터베이스에 저장할 때 암호화해야 합니까? 그리고 무작위로 소금을 넣는 것도 만일의 허점이 있을 경우 사람들이 창고를 가져가는 것을 막기 위해서다. 프로그램도 마찬가지다. 과거에 쓴 일부 서버 데몬은 버그가 있으면 영문도 모른 채 종료됩니다. 물론, 이 버그는 수정을 찾아야 하지만, 동시에 cron 을 써서 이 데몬의 상태를 점검해야 한다. 일단 종료되면 자동으로 복구된다. 이것은 중고 준비입니다. 집행하고 싶지 않더라도 이 준비는 해야 한다. 두 손, 심지어 세 손으로 문제를 준비하는 것도 우수한 프로그래머와 건축가의 핵심 자질이다.

세 번째 태도는 소통과 이해에 기반을 두고 있다. 제품이나 운영이 터무니없는 수요를 제시했는데, 한 마디로 회답하는 것은 당연히 멋지고 위신이 있다. 하지만 이 수요가 어떤 실제 수요에 기반을 두고 있는지, 그리고 이 실제 수요를 실현할 수 있는 더 합리적인 방법이 있는지 자세히 분석해 본 적이 있습니까? "이것은 할 수 없다. 이 실현 비용이 너무 높다." 라는 말은 올바른 소통 태도가 아니다. 게다가, 최고의 제품은 사람들이 원래 실현할 수 없다고 생각했던 호소를 실현하는 경향이 있다.

이런 태도가 있어야 끊임없이 진보할 수 있는 기초가 있다. 다음은 몇 가지 아이디어와 방법입니다.

훌륭한 프로그래머와 평범한 프로그래머는 코드만 치는 속도만 보면 서로 구분할 수 없다. 누구나 하루에 코드를 많이 쓸 수 있을지도 모르지만 문제가 생기면 평범한 프로그래머와 훌륭한 프로그래머의 해결 효율성이 크게 달라질 수 있다. 해결효율이란 bug 에 대한 분석, 포지셔닝, 사고일 뿐이다.

가장 기본적인 것은 실행 로그, 다양한 로그, 웹 서버 로그, 데이터베이스 로그, 느린 쿼리 로그, binlog 로그, PHP 오류 로그 등을 보는 것입니다. 인터넷에는 많은 사람들이 함부로 추측하여 문제가 생기면 일지조차 보지 않는다. 일지를 꼼꼼하지 않고 불완전하게 보는 사람들이 많다. 일지를 자세히 연구할 수 있어 이미 많은 사람을 넘어섰다.

둘째, 모듈 테스트와 중단점 분석, 프로그래머의 나쁜 습관 중 하나는 한 번에 많은 코드를 쓰고 실행하는 것이다. 그들은 테스트를 위해 모듈을 하나씩 작성하는 방법을 모른다. 문제가 발생하면 중단점을 설정하고 범위를 좁히고 단계별로 분석하는 방법을 모릅니다. 중단점 분석은 매우 간단합니다. 전체 코드에 몇 개의 중간 출력을 삽입하여 어떤 부분에 문제가 있는지 확인하거나 각 부분의 시스템 오버헤드를 관찰하는 것이 디버깅 및 성능 최적화에 매우 중요합니다. 전문가들은 아마 이것이 ABC 의 일이라고 생각하지만, 내가 본 프로그래머들은 대부분 이런 습관이 없다.

셋째, 오류 메시지의 이해와 검색, 검색 엔진에는 다양한 기술 자료와 기술 문답이 있다. 발생한 오류 메시지 및 오류 프롬프트는 일반적으로 인터넷에서 검색할 수 있습니다. 물론, 검색이 끝나면, 고양이처럼 대하는 것이 아니라, 당신의 장면에 대해 진지하게 생각해야 한다. (윌리엄 셰익스피어, 템페스트, 희망명언) 그렇지 않으면, 너는 이번에 운이 좋을지도 모르니, 다음에는 어떻게 된 일인지 모르겠다.

넷째, 끊임없이 귀납을 요약하고, 한 가지 문제, 한 가지 문제, 다른 유형의 문제를 총결하고 정리하며, 끊임없이 자신의 문제를 반성한다. 시간이 지나도 다시 돌아가서 무버그 코드를 돌아보더라도, 여전히 많은 부정확하고 불합리한 생각이 있고, 많은 최적화점이 있다. 코드가 항상 훌륭하고 완벽하다고 생각한다면, 당신은 정체되어 있고 진전이 없는 것이 틀림없다. (존 F. 케네디, 코드명언)

귀납과 총결산에 관한 한 가지 사례를 말씀드리겠습니다.

과거에는 우수한 기술 관리자가 처리하는 요청 수가 많고 부하가 많은 시스템이 있었습니다. 그는 몇 가지 업그레이드 방안을 열거했는데, 모두 믿을 만하고, 모두 실시되어 효과가 매우 좋다. 그리고 우리가 보도를 따라가자, 그는 몇 가지 업그레이드를 했고, 전반적인 효과가 좋다고 말했고, 나는 그를 비판했다.

내가 뭘 비판했어? 그는 함께 업그레이드를 한 다음 함께 효과를 관찰했기 때문에 각 시나리오의 실제 효과와 업그레이드에 얼마나 도움이 되는지에 대한 데이터는 없었다. 따라서 그는 각 구체적인 업그레이드 계획의 가치와 중요성을 알지 못했다. 너는 문제를 정확하게 해결했지만, 너는 진지하게 요약하지 않았다. 너의 수확은 한계가 있다. 함께 업그레이드하는 것은 잘못이라고 할 수 없지만 효과 평가는 단독으로 해야 하는데 이 데이터는 매우 가치가 있다. 지식의 축적은 네가 가공한 것이 아니라 네가 정리한 것이다.

아마 이렇게 될 겁니다.

마지막으로 다시 한 번 말씀드리겠습니다.

능력이란 무엇인가?

문제를 대하는 태도

문제를 처리하는 사고방식과 방법

이것이 바로 능력입니다

이렇게 많은 짱, 감사합니다. 몇 가지 생각을 보충해 주셔서 감사합니다. 위의 방법에 대한 구체적인 전개입니다.

보충 1: 질문을 잘하는데, 어떤 대답을 얻을 수 있는지는 당신이 어떤 질문을 하느냐에 달려 있다.

당신이 문제가 있을 때, 당신은 어디로 가서 무엇을 물어야 하는지 알아야 합니다.

나의 일반적인 시험 문제 중 하나는 이렇다.

현재 데이터베이스가 다운되었습니다. 저는 종업원입니다. 왜 그런지 모르겠어요. 당신은 훌륭한 분석가입니다. 이제 제가 응답하겠습니다. 네가 나에게 한 가지 질문을 하면, 내가 지표에 대답하고, 네가 문제를 찾을 수 있는지 보자. (물론 나는 가설적인 질문에 근거하여 모든 데이터 지표에 대답할 것이다. ) 예를 들어 데이터베이스 연결이 얼마나 되는지, 시스템 i/o 압력이 얼마나 되는지, 쿼리 로그가 느린 지 등을 물어본다. , 질문을 잘하는 사람은 빨리 답을 얻을 수 있지만, 질문을 잘하지 못하는 사람은 많은 가능성을 추측하고, 결국 아무것도 얻지 못한다.

정말 흥미로운 사례가 있습니다. 한 형제회사가 있습니다. (얼마 전에 뉴스가 나와서 10 억 달러처럼 팔렸습니다.) 처음에는 서버 데이터베이스가 충분히 강하지 않아 로드할 때 몇 가지 문제가 발생합니다. 제가 맥을 잡게 해주세요. Windows server 와 SQL server (짐작하지 마세요, 몇 년 전의 일인데, 지금 고쳐야 할 것 같아요) 라고 말하면서, 저는 안 된다고 했어요. 그리고 사람들은 그렇게 열정적으로 제가 전문가라고 했어요. 억지로 두피를 굳히고 기본적인 조작조차 할 줄 모른다. 나는 단지 거기에 앉아서 질문을 했을 뿐이다. 처음에 그들은 그렇지 않다고 말했다. 나는 네가 맹목적으로 결론을 내려서는 안 된다고 말했다. 만약 당신이 결론을 안다면 나에게 묻지 마세요. 나는 나에게 어떤 지표와 일지를 물어볼 것이다. 그들은 현장에서 데이터를 조사할 것이다. 나는 그들 중 한 명이 나에게 보여주고, 검사하고, 그들의 엔지니어들을 보게 할 것이다. 역시 그들의 원래 구상과는 완전히 다르다. 사실 관건은 역시 질문을 해야 한다. 그들은 처음에 올바른 질문을 하지 않았다. 문제를 제대로 묻자, 그들 자신은 곧 원인을 찾아냈다.

보충 2: 범위를 동그라미하고 문제의 범위를 좁히는 데 능숙합니다.

앞서 언급한 중단점 분석은 매우 일반적인 분석 방법이지만, 많은 시나리오에서 어떤 프로그램에 문제가 있는지 알 수 없고, 문제의 범위를 정의하는 것도 요약과 분류 능력이다.

나는 한 기술 팀에서 고전적인 테스트를 한 적이 있다. 웨이보에서 언급한 고전적인 면접 문제를 기억하십니까? 브라우저 입력 웹 사이트에서 웹 페이지 열기까지 무슨 일이 일어났는지' 는 고전적인 종합 인지화제다. 이 제목을 바탕으로 보다 현실적인 장면 테스트를 한다 (사실 역장과 게임 운영의 90% 가 이 장면을 만났다). "현재 사용자 신고 사이트나 게임 카드가 있습니다. 원인과 현재 우선 순위 단계는 어떻게 분석합니까? 클릭합니다 。 그 결과 이 무리에서는 제 제자만이 완전히 정확한 답을 주었습니다 (2009 년에 가져온 것). 우선 순위의 첫 번째 단계는 온라인 인원수와 현재 방문량을 보고, 역사를 비교하고, 문제의 현재 영향을 받고, 후속 우선 순위를 결정하고, 분석 범위를 좁히는 것이다. 분석 아이디어는 프런트 엔드, 네트워크 계층, 서버의 세 부분으로 나뉩니다. 물론, 이 세 조각은 많은 세부 사항에 대해 끊임없이 이야기 할 수 있지만, 적어도 우리는 먼저 문제를 세 조각으로 나눌 수 있습니다. 그런 다음 몇 가지 분명한 분석 방법에 따라 신속하게 그 중 일부를 제거하고 점차적으로 문제를 미세 조정할 수 있습니다. 대부분의 사람들은 한 부분에서만 생각하고, 많은 부분 세부 사항을 말하고, 완전한 해결책은 없으므로 이것이 격차입니다.

이것들을 먼저 생각해봐, 기침.

자업자득으로 조정을 알다.