Tôi đã được giao nhiệm vụ triển khai Ngôn ngữ cụ thể miền cho một công cụ có thể trở nên khá quan trọng đối với công ty. Ngôn ngữ đơn giản nhưng không tầm thường, nó đã cho phép các vòng lặp lồng nhau, nối chuỗi, v.v. và thực tế chắc chắn rằng các cấu trúc khác sẽ được thêm vào khi dự án tiến triển.
Tôi biết bằng kinh nghiệm rằng việc viết một lexer / trình phân tích cú pháp bằng tay - không cần ngữ pháp là tầm thường - là một quá trình dễ bị mất thời gian và dễ bị lỗi. Vì vậy, tôi còn lại hai tùy chọn: trình tạo trình phân tích cú pháp à la yacc hoặc thư viện kết hợp như Parsec. Cái trước cũng tốt nhưng tôi chọn cái sau vì nhiều lý do, và thực hiện giải pháp bằng ngôn ngữ chức năng.
Kết quả là khá ngoạn mục đối với mắt tôi, mã rất súc tích, thanh lịch và dễ đọc / trôi chảy. Tôi thừa nhận nó có thể trông hơi kỳ lạ nếu bạn chưa bao giờ lập trình ở bất cứ thứ gì ngoài java / c #, nhưng sau đó điều này sẽ đúng với bất cứ điều gì không được viết bằng java / c #.
Tuy nhiên, tại một số điểm, tôi đã bị đồng nghiệp tấn công theo nghĩa đen. Sau khi liếc nhanh vào màn hình của tôi, anh ta tuyên bố rằng mã này không thể hiểu được và tôi không nên phát minh lại phân tích cú pháp mà chỉ sử dụng một ngăn xếp và String.Split như mọi người. Anh ta gây ồn ào, và tôi không thể thuyết phục anh ta, một phần vì tôi đã bị bất ngờ và không có lời giải thích rõ ràng, một phần vì ý kiến của anh ta là bất biến (không có ý định chơi chữ). Tôi thậm chí đề nghị giải thích cho anh ta ngôn ngữ, nhưng vô ích.
Tôi khẳng định cuộc thảo luận sẽ xuất hiện trở lại trước ban lãnh đạo, vì vậy tôi đang chuẩn bị một số lập luận chắc chắn.
Đây là một vài lý do đầu tiên xuất hiện trong đầu tôi để tránh giải pháp dựa trên String.Split:
- bạn cần rất nhiều ifs để xử lý các trường hợp đặc biệt và mọi thứ nhanh chóng vượt khỏi tầm kiểm soát
- rất nhiều chỉ số mảng mã hóa cứng làm cho bảo trì đau đớn
- cực kỳ khó xử lý những thứ như hàm gọi như một đối số phương thức (ví dụ: add ((thêm a, b), c)
- rất khó để cung cấp các thông báo lỗi có ý nghĩa trong trường hợp lỗi cú pháp (rất có thể xảy ra)
- Tôi hoàn toàn đơn giản, rõ ràng và tránh những thứ khó hiểu thông minh không cần thiết, nhưng tôi cũng tin rằng đó là một sai lầm khi làm câm lặng mọi phần của cơ sở mã để ngay cả một người bán bánh mì kẹp thịt cũng có thể hiểu được. Đó là cùng một lập luận mà tôi nghe thấy về việc không sử dụng giao diện, không chấp nhận phân tách mối quan tâm, sao chép mã dán xung quanh, v.v ... Rốt cuộc, tối thiểu phải có năng lực kỹ thuật và sẵn sàng học hỏi để làm việc trên một dự án phần mềm. (Tôi sẽ không sử dụng lập luận này vì nó có thể sẽ gây khó chịu và bắt đầu một cuộc chiến sẽ không giúp được ai)
Đối số yêu thích của bạn chống lại phân tích cú pháp theo cách của Cthulhu là gì? *
* tất nhiên nếu bạn có thể thuyết phục tôi thì anh ấy cũng sẽ hoàn toàn hạnh phúc