회사에 중요한 도구가 될 도메인 특정 언어를 구현하는 임무를 맡았습니다. 이 언어는 단순하지만 사소한 것이 아니라 이미 중첩 루프, 문자열 연결 등을 허용하며 프로젝트가 진행됨에 따라 다른 구문이 추가 될 것입니다.
나는 문법이 사소한 것이 아닌 한, 직접 렉서 / 파서를 작성하는 것은 시간이 걸리고 오류가 발생하기 쉬운 프로세스라는 것을 알고있다. 그래서 나는 파서 생성기 à la yacc 또는 Parsec과 같은 결합기 라이브러리의 두 가지 옵션이 남았습니다. 전자도 좋지만 여러 가지 이유로 후자를 선택하고 기능적 언어로 솔루션을 구현했습니다.
결과는 내 눈에 매우 훌륭하고 코드는 매우 간결하고 우아하며 읽기 쉽고 유창합니다. java / c # 이외의 다른 프로그램을 프로그래밍하지 않으면 조금 이상하게 보일 수 있지만 java / c #으로 작성되지 않은 것은 사실입니다.
그러나 어느 시점에서 나는 문자 그대로 동료의 공격을 받았습니다. 내 화면을 간략히 살펴본 후 코드를 이해할 수 없으며 구문 분석을 다시하지 말고 스택과 String을 사용하면된다고 선언했습니다. 그는 많은 소음을 냈으며, 나는 놀랍게도 설명이 없었기 때문에 부분적으로 설득 할 수 없었다. 나는 심지어 그에게 언어를 설명하라고 제안했지만 아무 소용이 없었다.
토론이 경영진 앞에서 다시 등장 할 것이므로 긍정적 인 주장을하고 있습니다.
이것이 String.Split 기반 솔루션을 피하기 위해 떠오른 처음 몇 가지 이유입니다.
- 특별한 경우를 처리하기 위해 많은 if가 필요하며 물건을 빨리 통제 할 수 없게 만듭니다.
- 하드 코딩 된 배열 인덱스가 많으므로 유지 관리가 어려움
- 함수 호출과 같은 것을 메서드 인수로 처리하기가 매우 어렵습니다 (예 : add ((add a, b), c)
- 구문 오류가 발생할 경우 의미있는 오류 메시지를 제공하기가 매우 어렵습니다 (매우 발생할 수 있음)
- 나는 단순성, 명확성 및 불필요한 스마트 암호를 피하기 위해 모두 노력하고 있지만, 햄버거 플리퍼조차도 그것을 이해할 수 있도록 코드베이스의 모든 부분을 멍청하게 만드는 것은 실수라고 생각합니다. 인터페이스를 사용하지 않고, 문제를 구분하지 않고, 코드를 복사하여 붙여 넣는 등의 말을 듣는 것과 같은 주장입니다. 결국 소프트웨어 프로젝트를 수행하려면 최소한의 기술적 역량과 배우려는 의지가 필요합니다. (이 주장은 아마도 불쾌하게 들릴 것이므로 사용하지 않을 것이며, 전쟁을 시작해도 아무도 도움이되지 않을 것입니다)
크 툴후 길을 파싱 하는 것에 대해 당신이 가장 좋아하는 주장은 무엇입니까 ? *
* 물론 그가 옳다는 것을 확신 할 수 있다면 나는 또한 완전히 행복 할 것이다.