Ghép nối logic kinh doanh lập trình với một người không CNTT [đã đóng]

Bạn đã có kinh nghiệm trong đó một người không phải CNTT làm việc với lập trình viên trong quá trình mã hóa chưa?

Nó giống như lập trình cặp, nhưng một người là một người không CNTT biết nhiều về kinh doanh, có thể là một kỹ sư quá trình với nền tảng toán học, người biết cách tính toán mọi thứ và có thể hiểu mã thủ tục, không thành ngữ.

Tôi đã thấy rằng một số ngôn ngữ theo quy trình, tên miền cụ thể như PL / SQL khá dễ hiểu bởi các kỹ sư không phải là CNTT. Những người này cuối cùng là đồng tác giả của mã và đảm bảo tính chính xác của các công thức, các yếu tố, v.v.

Tôi đã thấy loại lập trình cặp này khá hiệu quả, loại người dùng kiểu kỹ thuật này cảm thấy họ cũng là "chủ sở hữu" và "tác giả" của mã và giúp giảm thiểu những hiểu lầm trong quá trình giao tiếp. Họ thậm chí còn giúp thiết kế các trường hợp thử nghiệm.

• Là thực hành phổ biến?
• Nó có tên không?
• Bạn đã có bất kỳ kinh nghiệm tương tự?

Mặc dù bạn đang mô tả đây là phiên mã hóa được chia sẻ (tôi không thể gọi đó là lập trình cặp, vì chỉ có một người là "lái xe" - trong lập trình cặp, cả hai bên đều lấy bàn phím và viết mã), tôi sẽ gọi đó là thu thập các tiêu chí chấp nhận .

Đó là, bạn đang xác thực các quy tắc kinh doanh (tính toán và quy trình chính xác) với người dùng doanh nghiệp (mặc dù một quy tắc có vai trò rất kỹ thuật, một kỹ sư).

Trong trường hợp này, nó dịch ngay lập tức thành mã viết (SQL), nhưng đối với nhiều hoạt động khác thì không, mặc dù có công cụ kiểm tra chấp nhận tự động cho các ngôn ngữ và nền tảng khác nhau (tôi đặc biệt nghĩ về ngôn ngữ gherkin và công cụ liên quan).

Cách làm này không phổ biến như mong muốn, nhưng ngày càng có nhiều người theo dõi và những người theo nó (nhận được tiêu chí chấp nhận ở dạng có thể thực thi) thấy nó là một công cụ để giao tiếp với doanh nghiệp và để lái xe phát triển.

Đúng. Nơi tôi làm việc tôi làm công cụ loại lập trình cứng, trong khi các chiến lược gia làm việc theo chiến lược uhm. Đó là để nói rằng tôi viết các chương trình thực hiện mô hình giao dịch của họ.

Chìa khóa cho vấn đề này là ngồi ngay bên cạnh họ và hiểu chính xác ý tưởng là gì, và đặt nhiều câu hỏi về những điều có thể là ngẫu nhiên đối với họ, nhưng quan trọng đối với phía thực thi. Chẳng hạn, tôi hỏi về việc giao dịch cần được thực hiện nhanh như thế nào, liệu điều đó có ảnh hưởng đến mô hình của họ không. Điều này có tác động rất lớn đến cách tôi sẽ viết mã. Thực tế tôi có xu hướng phun các câu hỏi vào phòng khi chúng tôi ngồi đó làm việc mỗi ngày.

Có một phản hồi hai chiều. Nếu tôi nói với họ một số kế hoạch giao dịch sẽ không dễ xây dựng, họ sẽ quay lại và suy nghĩ về sự đánh đổi nào có thể được thực hiện ở phía ra quyết định. Nếu họ quyết định chiến lược mới của họ cần một số tính năng mới, tôi có một cuộc trò chuyện với họ về việc sẽ mất bao lâu để xây dựng và những cạm bẫy tiềm năng là gì.

Thỉnh thoảng, họ thực hiện các mô-đun mã hóa một số khía cạnh của chiến lược giao dịch, nhưng tôi kết hợp các phần lại với nhau thành một kiến ​​trúc cho phép chúng tôi theo dõi tất cả các chiến lược khác nhau cũng như các công cụ vận hành phụ trợ. Bằng cách đó, họ không cần phải biết quá nhiều về hệ thống.