셰에베레스트는 영감의 원천을 제공했다. 모든 장면에 대한 코드를 작성해 주셔서 감사합니다. 잘 못 썼으면 그를 찾아 주세요.
침을 뱉다
우리는 기술자의 KPI 를 설정하는 방법에 대해 계속 논의합니다.
알리 테크놀로지는 문장' 기술자의 KPI 를 정량화하는 방법' 을 가지고 있는데, 저자는 장검비다. 그는 기술자의 KPI 를 비즈니스 기여, 기술 기여, 팀 기여 등 "세 가지 기여" 로 나눌 수 있다고 믿습니다.
1. 비즈니스 기여: 수요 통제, 비즈니스 프로젝트 및 비즈니스 혁신을 포함합니다.
2. 기술 기여: 설계 재구성, 기술적 영향, 코드 검토, 혁신 및 효율성 향상, 코드 품질 등을 포함합니다.
3. 팀 기여: 채용, 신규 인재 양성, 팀 분위기 포함.
두 번째' 기술 공헌' 이 해체되었고, 작가는 일의 몇 가지 사례로 다음과 같이 설명했다.
1, 애플리케이션 품질:
품질 점수 적용에 대한 책임 또는 * * * 공동 책임 (코드 반복률, 서클 복잡성, 계층화 합리성 등의 차원에서 조사할 수 있음). ) 및 기술자가 응용 품질 점수를 높이기 위해 어떤 일을 했는지 알 수 있습니다.
2. 설계 재구성:
고객 커뮤니케이션 프로젝트에서 기술자는 CRM 판매 영역을 모델링하고 설계하여 추상적이고 합리적입니다.
인프라 내 가방의 분류가 불합리하다는 것을 발견하고 재설계하고 재구성했다.
현재 시스템의 오류 코드가 비교적 혼란스럽다는 것을 발견하고 새로운 오류 코드 사양을 개발하고 코드 재구성을 완료했습니다.
3. 기술적 영향:
팀 공유 전략 모델은 학생들의 호평을 받았다.
초청을 받아들여 업계 대회에서 SOFA 아키텍처를 공유했다.
4, 코드 검토:
코드를 심사할 때, 나는 스레드 불안정의 위험이 있을 수 있다는 것을 발견했다.
코드를 심사할 때 불합리한 디자인이 있는 것을 발견했다. 여기서 책임사슬을 사용하면 우아하게 문제를 해결하고 일정한 확장성을 가질 수 있다.
5, 혁신과 효율성:
현지 테스트에서 Pandora Boot 를 시작하는 것은 시간이 많이 걸리기 때문에 테스트 컨테이너를 작성하면 자체 테스트의 효율성이 크게 향상됩니다.
일부 템플릿 코드는 쓸 필요가 없습니다. 낙관적 잠금 및 페이징은 코드 주석을 단순화하기 위한 것입니다.
프로젝트 또는 기술적 시점에서 특허: 도메인 모델을 기반으로 한 비즈니스 구성이 생성됩니다.
6, 코드 품질:
테스트 후 버그 및 온라인 장애 수 (시스템을 추출할 수 있으며 채울 필요가 없음).
한 모듈의 단위 테스트가 완벽해져서 여러 차례 자동 복귀하여 문제를 발견하였다.
다음으로 갈고리 세트의 그림을 보여드리겠습니다. 저자는 Bigger (빅데이터 엔지니어) 가 만든 기술 KPI 입니다.
Bigger 는 기술자들이 자유로운 환경을 선호하지만 창업팀에게는 모두가 규범을 지키지 않으면 이 회사의 기술팀이 난장판이 될 것이라고 생각한다.
기술자는 어떤 KPI 를 사용해야 합니까?
알리 기술 문장 (Ali technology foundation) 에 대한 의견을 바탕으로 저자는 다음과 같이 분명히 생각합니다.
KPI 는 능동적이며 다른 단계에 집중해야합니다.
1. 창업단계, KPI 는 가능한 업무에 기울어야 한다. 생존이 모두 문제가 될 때, 기술 이상을 이야기하는 것은 그야말로 유토피아다.
2. 수입이 차츰차츰 안정되면 가능한 한 기술에 기울어야 한다. 그래야만 온건함에 대해 이야기할 수 있다. 전체가 정상 궤도에 들어서면 시스템이 충분히 튼튼할 때 6/4 (비즈니스/기술) 비율을 유지하는 것이 더 적절할 것이다. 물론 이것은 각 기업의 실제 상황에 따라 유연하게 조절해야 한다.
또한 TL 자체의 업무, 기술, 시장에 대한 다차원 평가 기준도 제시했다. 순수 기술이나 순수 상업은 모두 바람직하지 않다. 결국, 모두가 상업 기관을 기다리고 있으며, 상업 이윤이 1 위이다. 다른 모든 것은 이것을 중심으로 해야 하고, 기술 최적화도 상업적 이윤을 위해 서비스해야 한다.
따라서, 기술에 대해 이야기하지 않거나, 기술에 대해 이야기하지 않는 것은 모두 유토피아적인 사고이다.