회사 개발에 대한 나의 경험을 공유하십시오.

이 제목의 원칙이라는 단어가 맞는지 모르겠습니다. 코드를 작성하는 우리들에게는 사실 나중에 표준이라고 부르겠지만, 생각해보면 다른 측면에서는 원칙일 수도 있겠네요. 얽매이지 말고 바로 본론으로 들어가죠.

새 회사에 온 지 한 달이 넘었습니다. 처음 도착한 날이 바로 반복의 시작이었습니다. 어제까지는 백엔드 버전이 공용 네트워크에 동기화되어야 했기 때문에 약간 지연되었습니다. 검토가 진행 중이었지만 내부 테스트도 본격화되었습니다. 방금 다른 환경으로 변경했는데 새로운 환경의 개발 모델, 코드 사양, 코드 제출 모드 등이 모두 새롭습니다. 저에게 가장 심오한 점은 당연히 코드 제출 방법입니다. 예전의 코드리뷰 방식에 익숙해져서 그런 강제적인 메커니즘이 없어서 조금은 마음이 편해졌습니다.

태만에 대한 대가는 다소 비극적입니다. 버전 출시 전날이 되어서야 많은 일에는 원칙, 규칙 및 표준이 필요하다는 사실을 깨달았습니다. 코드상으로는 좋은 제품이라고 할 수 없습니다. 안드로이드용으로 개발하면 당연히 좋은 앱이 나올 수 없습니다. 먼저 제 관점에서 규제에 대해 말씀드리겠습니다. 프로그래밍 표준, 특히 Java 프로그래밍 표준의 관점에서 볼 때 널 포인터는 가장 일반적인 문제 중 하나입니다. 배경에 필드를 추가했지만 APP 버전에서는 이전 배경에 먼저 연결하고 전후의 기능을 비교하려고 합니다. , 현재로서는 이 작업이 수행되지 않았습니다. 판단할 매개변수를 입력한 후 결과가 어떻게 될지 상상할 수 있습니다. 앱이 충돌합니다. 판단이 내려지면 적어도 사용자 경험의 관점에서 볼 때 이 앱에는 치명적인 문제가 없습니다. 그러나 매개변수 판단을 입력하는 것은 단지 하나의 단계일 뿐이며 null을 판단하지 않고도 충돌을 방지할 수 있습니다. 이는 인터넷에서 찾을 수 있는 트릭으로, 판단의 전제 조건으로 상수를 사용합니다. 사실 제가 이 문단을 썼을 때, 이 글을 읽은 반 친구들은 이런 간단한 일을 쉽다고 생각했을 것입니다. 그것은 제가 이 작은 실수에 대해 어리석었다는 것을 의미합니다. 이것도 어제 집에 와서 처음으로 느낀 깊은 감정이었습니다. 당신이 모르거나 이해하지 못하는 것이 아니라 주의를 기울이지 않았고 작은 세부 사항이 살인을 일으켰다는 것입니다.

null이 아닌 판단과 범위를 벗어난 배열 예외는 Java와 C 모두에서 일반적인 문제입니다. 이전 프로젝트 팀에서는 Java와 C에 대한 군사 규정이 있었던 것으로 기억합니다. 이러한 하위 수준 오류를 제거해야 했습니다. 이를 방지하는 좋은 방법은 우리는 물론 Google만큼 훌륭한 회사에서도 코드 검토를 수행하는 것입니다. 항저우 회사에 처음 도착했을 때 동료가 리뷰를 요청한 것을 기억합니다. 나는 한동안 응답하지 않았습니다. 나중에 점차 프로세스에 익숙해지고 몇 가지 일반적인 실수를 리뷰 전제 조건으로 나열했습니다. 나는 인터넷에서 닭고기 수프 기사를 많이 읽었으며 리뷰의 중요성에 대해 여러 번 언급했습니다. 다른 사람의 코드에 대해 더 많이 읽는 것도 자신의 능력을 향상시키는 방법입니다. 예전에는 코드리뷰가 프로젝트팀의 필수사항이었는데 지금은 시행하지 않아서 태만하게 되었고, 새 버전이 올라오면 코드에 문제가 생기네요. 사실 제가 책임을 회피할 수도 있습니다. 버전 출시 시 백엔드에 오류가 있어서 이를 수정하는데 3번의 롤백이 걸렸지만 여전히 구성되지 않은 매개변수가 있어 잘못된 구성과 잘못된 매개변수를 얻었습니다. 앱으로. 논리적으로 말하자면 APP와 백엔드가 강하게 연관되어 있는 상황에서 실제로는 예전에 백엔드로 확인을 했었는데 그 이유가 참을 수 없어서 백엔드 동료들이 문제 없을 거라고 말하는 건 아니고, 100% 확신해야 하는 것도 문제입니다. 이런 종류의 자기 판단 능력은 언제, 어디서든 자신의 내부 프로그래밍 표준과 원칙을 엄격하게 준수해야 하며 APP에 대한 완전한 계획을 세워야 합니다. 사용자 경험을 보장합니다.

처음으로 새로운 회사의 버전 출시에 참여했을 때 입력 매개변수가 비어 있지 않은 것으로 판단되지 않고 배열 길이가 판단되지 않아 클라이언트가 충돌을 겪었습니다. 사실 이건 정말 죄책감이 들었습니다. 이전에는 반드시 필요한 작업이었는데, 이번에는 전적으로 제가 이를 엄격히 준수하지 않아서 발생한 문제였습니다. 다행히도 사전 출시에 불과했고 문제는 내부적으로 소화되었습니다. 백그라운드 문제에 대해서는 잘 모르지만, 여러 차례 롤백을 하여 다행스럽게도 통제 가능했고, 아슬아슬한 상황도 발생하지 않은 것으로 알고 있습니다. 내가 아는 한, 대부분의 백엔드 문제는 구성이 동기화되지 않고 코드가 온라인으로 동기화되지 않아 발생합니다. 갑자기 일반적인 문제를 발견했습니다. 제가 접한 버전이 출시된 날 개발은 배포 중이거나 갑자기 테스트되지 않을 때 크든 작든 항상 문제가 있었습니다. 이런 일을 겪어본 사람이 있는지 알아보세요, 하하.

저도 처음 경험해봐서 그 루틴을 알아요. 제품을 만드는 건 또 다른 느낌을 공유하고 싶어요. 여러 명의 새로운 동료들과 함께 개발을 하고 있을 때, 그 중 한 명이 게을러서 아침 회의에서 그룹의 상사가 모든 사람 앞에서 다음과 같이 말했던 것을 아직도 기억합니다. 우리의 제품 개발은 더 이상 학교 졸업 프로젝트와 같지 않을 것입니다. 예, 모든 사람이 제품에 대해 알고 있어야 합니다. 그 이후로 이 문장을 염두에 두고 있었는데, 아쉽게도 제 스스로는 잘 하지 못했고, 특히 코드 작성에 있어서는 자기 이완에 빠져 제품에 대한 인식을 잃어버렸습니다. 제품을 만들기 위해서는 코드를 작성하는 것도 요구사항 분석, 요구사항 평가, 흐름도 등의 과정 중 하나일 뿐입니다. 지난 3년 동안 배운 내용을 최대한 활용하여 제품을 더 좋게 만들겠습니다. . 또한 처음으로 버전을 출시한 경험을 통해 스스로에게 경고했습니다. 버리는 것은 무엇이든 원칙을 잃지 마십시오. 그렇지 않으면 항상 할 일은 제품이 아니라 앱일 뿐입니다.

위 내용은 회사 개발에 대한 나의 경험을 공유하십시오.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!