인터페이스를 조정하여 조정되는 것은 정확히 무엇이며 작업량은 어디에 있습니까?

기술을 이해하지 못하는 IT 실무자로서 요즘 인터페이스를 조정하고 있는데 여러 인터페이스를 조정하는 데 시간이 오래 걸린다는 말을 자주 듣습니다. 조정 인터페이스에서 정확히 무엇을 조정하고 있는지 묻고 싶습니다. 업무량은 어디에 있나요? 기술 전문가들이 나에게 간단한 용어로 대중 과학을 알려줄 수 있기를 바랍니다. 매우 감사합니다! (간단하게 설명할 수 없다면 더 깊게 설명하는 게 낫습니다. 백과사전도 천천히 확인해 보겠습니다. ㅎㅎ. 다시 한 번 감사드립니다!)

답글 내용:

중재는 당신과 동료들 사이의 동일한 요구에 대한 서로 다른 이해에 관한 것입니다. 누가 당신을 첫날부터 긴밀히 협력하지 못하게 만들었습니까? 이것이 내가 두 사람이 서버와 클라이언트를 작성하는 것에 반대하는 이유입니다. IT는 오랜 세월 동안 존재해 왔습니다. 사람을 CPU 슈퍼 파이프라인으로 취급하는 것이 더 낫지 않습니까? 먼저 서버를 수행하고 작업이 끝나면 클라이언트를 수행합니다. 일시적인 이유로 강제로 서버와 클라이언트를 함께 작성해야 하는 경우에도 실제 서버와 클라이언트를 매번 동시에 시작해야 합니다. 문제가 발생하더라도 다른 사람을 차단할 염려는 없습니다. 함께 해결해 보세요.

초기에는 시간이 낭비되는 것처럼 보이지만 장기적으로 보면 전체적인 효율성은 몇 배로 향상될 것입니다.

이상적인 상황.

서버: 괜찮아요, 전화해도 돼요!

고객: 테스트 호출이 정상입니다. 테스트할 준비가 되었습니다!

실제(국내)상황.

서버: 괜찮아요, 전화해도 돼요!

클라이언트: 500

서버: 확인해 보니 일부 오래된 코드가 비정상적인 것 같습니다. .

(30분 후)

서버: 괜찮아, 전화해도 돼!

클라이언트: 아직 500

서버: 잊어버리세요. 이전 코드를 리팩토링하겠습니다.

(2시간 후)

서버: 괜찮아, 전화해도 돼!

고객: 아직 500입니다. . 매개변수를 변경하셨나요?

서버: 새 매개변수에 따라 조정되었습니다.

클라이언트: 이 인터페이스는 괜찮지만, 해당 인터페이스는 다시 다운되었습니다. 매개변수를 변경했습니다.

클라이언트: 문서 작성

서버: 긴급하게 처리해야 할 온라인 오류가 있습니다

클라이언트: 알았어 (그런 다음 차 붓을 만들어 확인 Zhihu)

(1시간 후)

클라이언트 팀장: 조인트 디버깅 괜찮나요? 우리 클라이언트는 가능한 한 빨리 새 버전을 출시해야 합니다.

클라이언트: 서버에서 새 문서를 기다리는 중입니다.

클라이언트 팀장: 잠시 기다려서 마무리하세요. 빨리, 그렇지 않으면 성능이 -1초입니다

클라이언트: 서버, 이리 오세요. 인터페이스를 빨리 고치겠습니다. 우리는 죽을 것입니다

서버: 젠장, 오류가 발생했습니다. 아직 해결되지 않았습니다. 10분간 도와드리겠습니다

서버팀장 : 문제점은 해결되었나요? 서비스 품질을 보장해야 합니다

서버: 클라이언트와 공동 디버깅 후 나중에 오세요

서버 팀장: 전화해서 빨리 문제를 해결하세요. 그렇지 않으면 성과가 - 1초

클라이언트&서버: 정말 망했어요

인터페이스 조정의 본질은 '기다림'에 있다 작업량이 조정되는 중입니다. 소프트웨어 제작을 제조가 아닌 개발이라고 부르는 이유는 끊임없는 시행착오가 필요하기 때문이다. 관련 시스템과 인터페이스를 공동 디버깅하면서
0은 공동 디버깅 날짜에 동의했습니다. 그들은 이제 막 개발을 시작했고 공동 디버깅까지 이틀을 기다리겠다고 말했습니다.
1 인터페이스 문서를 세 가지 버전으로 변경할 수 있으며, 각 버전마다 매개변수 이름이 다릅니다.
2 약속된 5개의 출력 매개변수가 갑자기 2개로 바뀌었습니다. 결함 알림을 받은 후 롤백하고 수정하는 데 반나절이 걸렸고 온라인에 접속하기 이틀 전 다시 출력 매개변수가 2개밖에 없었습니다.
3AB 국경절 초과 근무 중에 두 인터페이스의 호출 순서가 알려졌는데, 열흘이 지나도 순서가 잘못된 것으로 확인되었습니다.
4. 온라인 인증 중 D가 너무 많이 호출된 것을 발견했습니다. C 인터페이스 호출할 때 어젯밤에 잠을 못 잤어요
다들 IT인이군요╭(╯^╰)╮ 물어본 사람이 우리 상사 아닌가요? 표준 프로젝트 프로세스는 다음과 같습니다.

PM은 프로젝트 요구사항 문서 및 MRD를 생성합니다. -> PM은 MRD 검토를 위해 관련 담당자에게 연락합니다. -> Designer는 MRD를 기반으로 설계 도면을 작성합니다. -> 백엔드 엔지니어는 프로젝트 요구사항, MRD 및 설계를 기반으로 서버를 생성합니다. 인터페이스 문서 작성 -> 프론트엔드 엔지니어가 인터페이스 문서 검토 -> 프론트엔드 및 백엔드 엔지니어가 병렬 개발 및 자체 테스트 수행 -> 프론트엔드 및 백엔드 개발이 완료된 후 인터페이스 결합 디버깅 진행 -> 테스터 진행 -> 테스트 완료 후 출시 -> 온라인 서비스 기능 복귀

개발 과정이 모두 잘 진행되면 자연스럽게 괜찮을 거예요. 그러나 백엔드 엔지니어들은 자신에 대한 자신감으로 인해 충분한 자체 테스트를 수행하지 않거나 심지어 전혀 테스트하지 않는 경우가 많습니다. -end는 백엔드를 사용할 수 없음을 발견하고 백엔드에서 문제를 해결합니다. 당연히 백엔드에서 시간이 낭비됩니다. (프론트엔드에 문제가 있는데 백엔드에서는 이를 모릅니다. 관련), 프로젝트가 지연되었습니다. 마찬가지로, 인터페이스 문서가 명확하게 작성되지 않으면 프런트엔드와 백엔드가 매개변수에 대해 서로 다른 이해를 갖게 되며, 이로 인해 인터페이스나 프런트엔드 구현이 수정되는 횟수가 늘어나게 됩니다. 프로젝트가 지연됩니다.

이런 일이 흔하기 때문에 일반적으로 공동 디버깅 시간에는 자체 테스트 시간이 포함되므로, 이 테스트 시간이 추가되면 자연스럽게 공동 디버깅 시간이 길어집니다.

룬 형제님의 방법은 예술에 전문성이 있고 사람의 에너지가 제한되어 있다고 생각합니다. 풀스택 엔지니어라 할지라도 자신이 잘하는 것이 하나 있다. 게다가 언어와 개발마다 개발 사양이 다르기 때문에 자주 로테이션을 하면 에너지가 많이 낭비된다. , 언어 개발을 전환하면 개발 효율성도 저하됩니다. 게다가, 대규모 프로젝트를 한 사람이 전적으로 개발할 수는 없으며, 여러 사람이 공동으로 작업하는 경우에는 동일한 모듈의 코드를 수정하더라도 문제가 발생할 가능성이 더 높습니다. 공동 디버깅 단계에서는 개발 단계에서 문제가 발생하면 효율성이 떨어지지 않을까요? 서쪽 벽을 메우기 위해 동쪽 벽을 허무는 것이 아니라 표준화된 프로세스를 통해 공정 문제를 해결해야 합니다. 우선 키(4성) 인터페이스가 아닌 키(2성) 인터페이스를 이야기한다고 가정해보자. 후자에는 작업 부하 문제가 없기 때문입니다.

이전 질문에 대한 답변은 만료된 여권을 재발급할 때 발생하는 문제에 관한 것인데, 이는 인터페이스 디버깅 문제와 일치합니다.

샤오밍(우리 측)이 지금 해외로 나가고 싶어 여권을 신청해야 한다고 가정해 보겠습니다(비즈니스 요건).

Xiao Ming은 신청 안내서(인터페이스 문서)를 확인하기 위해 공안국 웹사이트(인터페이스 제공업체)에 갔습니다. 여권을 신청하려면 다음이 필요하다고 합니다.

• 사진 한 장
  
• 신분증
  

이 자료(매개변수)입니다. Xiao Ming은 온라인(인터페이스 1)으로 예약을 하고 예약 번호(인터페이스 1의 통화 결과)를 받은 후 호적 주소가 있는 공안국에 가서 신청할 수 있습니다. 또는 공안국(인터페이스 2)에 직접 방문할 수도 있지만 당일 예약이 불가능할 수도 있습니다.

Xiao Ming은 온라인으로 약속을 잡기로 결정했지만 웹사이트에 "약속 성공"이라고 표시되었습니다(인터페이스가 문서와 일치하지 않음). 그러면 당신은 그것이 효과가 있었다고 생각할 것입니다(우리 측의 실수입니다).

샤오밍은 사진과 신분증을 가지고 공안국에 갔지만 공안국 여자가 물었습니다. 전화번호는 어디에 있나요?

당신의 전화번호는 무엇입니까?

예약번호가 무엇인가요?

아니요?

아니요, 해당되지 않습니다. 그렇지 않은 경우 온라인으로 예약하고 예약 번호를 받거나 현장에서 예약할 수 있습니다. (결과가 예상과 다르니 다시 시도하세요)

샤오밍이 생각나면 그 자리에서 약속을 잡겠습니다. 예약하려고 했을 때 다른 직원이 내 어린 딸에게 최근 시스템이 업그레이드되고 있는데 문제가 있을 수 있다고 말하는 것을 들었습니다. 많은 사람들이 예약을 했지만 번호를 받지 못했습니다. 구조조정). 어린 소녀는 Xiao Ming이 하루 휴가를 요청했다는 이유로 그의 상사에게 얼마나 불쌍한지 엿먹이려고 하는 것을 보고 그냥 내버려두고 Xiao Ming에게 오늘 휴가를 달라고 요청했습니다(양측 모두 해결책을 협상했습니다).

샤오밍은 기뻐하며 사진과 신분증을 꺼내고 증명서 신청을 준비했습니다(인터페이스 2 호출).

어린 소녀가 그것을 보고 말했습니다. 뭐 하는 거예요?

사진..어?

아니요. 여권 사진은 표준화되어야 합니다. 사진 갤러리 A는 사진을 찍으려면 사진을 직접 보내드립니다. 카드(두 번째 카드에서 제공) 사각형).

샤오밍은 말문이 막혔다. 웹사이트에서 이를 명확하게 밝히지 않는 이유는 무엇입니까?

어린 소녀는 웹사이트에 가보면 우리 웹사이트가 재작년에 만들어졌는데, 정책이 오래 전에 바뀌었다고 말했습니다(문서가 유지되지 않았습니다).

샤오밍은 어쩔 수 없이 갤러리 A로 향했습니다.

사진관에서 들었을 때 아, 아, 사진 찍어도 되는구나.그런 다음 그는 그것을 가져가서 말했습니다. "좋아, 내가 당신을 위해 그것을 그들의 시스템에 업로드할 테니 직접 가셔도 됩니다."

샤오밍은 공안국으로 복귀했습니다.

꼬마 소녀: 잠깐만요, 오늘은 인터넷이 좀 느리고, 사진도 전송이 안 되더라구요(제공자 간 인터페이스 호출 문제).

기다리고 기다리다가 퇴근 시간이 거의 다 되어서야 성공했습니다.

여동생: 자, 드디어 다운로드가 됐으니 시작해도 됩니다.

샤오밍은 안도의 한숨을 쉬었습니다.

여동생: 잠깐만요, 저희 시스템 제출 채널이 닫혔어요.

샤오밍:? ? ?

꼬마 소녀: 맞아요, 우리 상사가 우리를 너무 사랑해서 사무실 시스템을 설계할 때 30분 후에 퇴근하면 업무 채널을 닫아달라고 하더군요. 테이블을 정리하고 밤에 먹을 곳.

샤오밍:? ? ?

여동생: 미안해요, 내일 일찍 갈게요.

샤오밍은 다음날 공안국에 갈 수밖에 없었다.

여동생: 정말 안타깝습니다. 어젯밤에 파운드가 급락했는데 갑자기 영국에 여권 신청하고 쇼핑하러 2,000명이 넘게 왔어요.

샤오밍:? ? ?

꼬마 소녀: 우리 시스템은 255명 이상이면 충돌이 발생합니다(예상치 못한 상황).

샤오밍:? ? ?

여동생: 저희 시스템 담당자가 오늘 결혼하고 내일 돌아옵니다.

샤오밍:? ? ?

여동생: 언제 수리될지 모르겠어요. 내일이나 모레 전화해서 물어보셔도 됩니다.

샤오밍이 피를 토했습니다.

============

인터페이스를 조정하는 것이 바로 그런 과정입니다.

작업량과 문제는 다음과 같습니다.

• 공급업체의 사업 설명이 불완전합니다. 그 이유는 다음과 같습니다: 1. 명확하게 생각하지 않음, 2. 게으르거나 의욕이 없음, 3. 업그레이드 또는 비즈니스 변경 이후에 따라잡지 못함, 4. 의도적으로 문제를 야기함. 따라서 결과가 예상한 대로인지 확인하려면 지속적으로 통신하고 반복적으로 확인하거나 인터페이스를 호출해야 합니다.
• 저희와 다양한 공급업체 사이는 물론 공급업체와 다른 공급업체 사이에도 협력 문제가 있습니다. 한 단계의 문제가 전체 상황에 영향을 미칩니다. 이것은 항상 일어나는 일입니다. 저는 일방통행로를 건널 때 양방향을 봅니다. 왜냐하면 스스로 잘 한다고 확신할 수 있다고 해도 다른 사람들도 같은 일을 할 것이라고 보장할 수 없기 때문입니다. 논리는 동일합니다. 그러므로 기다리거나 화해하거나 다른 해결 방법을 찾아야 합니다.

이 외에도 예상치 못한 특정 상황(예: 높은 동시성)에서 인터페이스에 예상치 못한 문제가 발생할 수 있으며, 이 문제도 디버깅해야 합니다.

이 사실을 알고 나면 진시황이 도량형을 통일한 위업에 엄지손가락을 치켜세울 것입니다. 왜냐하면 그는 서로 다른 표준과 인터페이스 간의 의사소통을 피했기 때문입니다. 전 세계가 동일한 인터페이스를 사용하므로 통신 비용이 크게 절감됩니다.

그럼 인터페이스를 조정할 땐 형이 인터페이스를 조정하고, 동생이 멘탈을 조정하는 거죠.

사장님이 빵가게에 가서 '햄버거 있어요?'라고 물으셨어요. 사장님은 몇 분 만에 햄버거를 사러 건너편 맥도날드로 달려간 뒤, 속을 신선한 고기로 바꾸고, 미소를 지으며 양손으로 햄버거를 들고 있었다. 업무량이 없고, 상대방이 당신에게 맞춰줄 수 있습니다.

반대로 맥도날드에 가서 혼자 햄버거를 사고, 신선한 고기빵을 사서 속재료를 꺼내고, 남들의 시선을 참으며 묵묵히 버거를 먹을 수 밖에 없다.

작업량이 당연히 엄청납니다. 카드를 신청하러 은행에 갈 때와 마찬가지로 다행스럽게도 우리 팀에는 프론트엔드와 백엔드를 통해 실행되는 js가 있습니다. 마이그레이션 파일에서 프론트엔드 효과까지 요구사항을 작성할 수 있습니다. 디자이너가 제공하는 디자인 결과물은 그래픽을 클릭하면 관련 CSS 정보가 표시되는 페이지를 가져오는 것이므로 논쟁의 여지가 없습니다.