비즈니스 코드를 작성하지 않는 것이 얼마나 멋진 일인지 깨달은 것은 저수준 개발을 하고 나서였습니다.

비즈니스 코드를 작성할 때 다른 사람의 인터페이스를 조정하는 데 대부분의 시간을 보낼 수 있습니다. 인터페이스는 기능을 캡슐화하는 데 적합하지 않으며 요구 사항은 끊임없이 변합니다.

결국 기능 구현이 가장 중요하고, 사용자 경험이 가장 중요합니다. 다른 사람이 요구하면 구현하면 됩니다.

당신은 비슷한 기능을 달성하기 위해 반복적인 비즈니스 코드를 작성하는 무자비한 기계와 같습니다. 당신은 진전이 없고 비전이 향상되지 않았다고 느낍니다...

하지만 드라이버 개발은 완전히 다릅니다. .....

괜찮을지 말지는 여러분의 몫입니다

비즈니스 코드에서 가장 흔한 것은 수요 변화입니다.

예를 들어 이 모듈에 다른 함수를 추가하고 이 코드를 캡슐화한다면 이렇게 작성할 수 없다면 이렇게 작성해야 하는데...

하지만 드라이버의 경우, 쓸 수 있다, 쓸 수 있다, 쓸 수 없으면 수요가 전혀 없다.

예를 들어 네트워크 카드 드라이버는 정상적으로 네트워크에 연결하고 파일을 정상적으로 전송할 수 있는 것이 그 기능입니다. 코드 작성 방법은 칩 매뉴얼을 기반으로 하므로 아무도 묻지 않습니다.

그러니 필요 사항에 대해 걱정하지 마세요. 사용할 수 있는 한 작업은 완료됩니다. 대부분의 경우 버그가 수정됩니다.

당신을 제외한 대부분의 사람들은 당신의 코드를 감히 건드리지 못합니다.

왜 감히 건드리지 못하는 걸까요?

드라이버 코드는 애플리케이션 계층에 작성된 비즈니스 로직과 같지 않습니다. 비즈니스 코드는 인터페이스 캡슐화, 매개변수 판단, 특수 상황 처리 및 기타 부분 소프트웨어 설계와 같은 일부 프로그래밍 기술 및 코드 최적화에 관한 것일 수 있습니다. 특정 비즈니스 로직이 제대로 작성되지 않은 경우 경험이 있는 사람이 코드를 변경하는 것이 더 쉬울 것입니다.

하지만 드라이버 코드 작성의 가장 큰 특징 중 하나는 먼저 칩 매뉴얼을 이해하는 것입니다.

예를 들어 드라이버는 64바이트 정렬 메모리를 할당하고 스케줄링 전에 레지스터를 다시 설정하는 이유는 무엇입니까? 당신은 모른다.

누군가 드라이버에 문제가 있다고 생각하여 코드를 변경하고 싶다면 먼저 칩 설명서를 읽어야 합니다.

칩 매뉴얼을 읽기 전에는 이 코드를 이동할 수 없었습니다. 이 명사와 이 비트가 무엇을 의미하는지, 코드가 왜 이렇게 작성되었는지는 여러분만이 알 수 있습니다.

드라이버에 문제가 있더라도 직접 변경해야 합니다. 왜냐하면 대부분의 사람들은 자신의 업무 범위에 속하지 않는 문서를 읽느라 한가하지 않을 것이고, 문서를 이해하는 데 며칠이 걸릴 것이기 때문입니다.

작은 오류라도 직접 수정해야 하는 경우가 많습니다. 이 위치를 변경하면 다른 위치에 영향을 미칠지 다른 사람은 알 수 없기 때문입니다.

그래서 드라이버를 정상적으로 사용할 수 있는 한 누구도 건드리지 않을 것입니다.

내가 어떤 기능을 가지고 있는지 말해주는데,

원하는 기능을 알려주는 대신

비즈니스 코드라면 대개는 요구 사항이 모든 것을 이끌어줍니다. 사용자 경험을 위해.

근데 드라이버 코드가 반대네요. 어떤 기능을 원하는지 알려주시지 않고 제가 가지고 있는 기능만 알려드리겠습니다.

드라이버에는 이러한 기능만 있을 수 있습니다. 이 드라이버에는 이러한 기능이 있다고 말씀드릴 수 있습니다. 어떤 종류의 인터페이스를 원하시나요? 전화하다.

매개변수를 전달하고 xxx를 반환하고 싶다고 하면 불가능하다고 말씀드릴 수도 있습니다. 몇몇 매개변수를 동시에 전달하고 xxx를 동시에 반환하고 싶다고 하면 할 수 없다는 점만 말씀드리겠습니다.

왜 물어보나요? 하드웨어 자체로는 그러한 효과를 얻을 수 없기 때문입니다. 믿을 수 없다면 칩 매뉴얼을 읽어보시고 이해하신 후 다시 질문해 주세요.

위 내용은 비즈니스 코드를 작성하지 않는 것이 얼마나 멋진 일인지 깨달은 것은 저수준 개발을 하고 나서였습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!