Có thể sử dụng lập trình meta mặc dù không phải tất cả các đồng nghiệp của tôi đều hiểu nó?

Tôi sử dụng nhiều lập trình meta để tránh các tác vụ lặp đi lặp lại và xây dựng các bản tóm tắt an toàn hơn để sử dụng.

Gần đây tôi đã chuyển sang một công việc mới, nơi tôi đang làm việc trong một nhóm lớn hơn và điều này làm lo lắng một số đồng nghiệp của tôi, vì họ không hiểu nó.

Tôi luôn cố gắng tận dụng toàn bộ tiềm năng của ngôn ngữ, nhưng một số (không phải tất cả) các đồng nghiệp của tôi cho rằng đó là một rủi ro (một số hoan nghênh cách tiếp cận).

Tôi đồng ý rằng đó là một vấn đề để viết mã mà không ai khác trong nhóm có thể hiểu được. Mặt khác, tất cả chúng ta đều là những nhà phát triển C ++ chuyên nghiệp và tôi nghĩ chúng ta nên khao khát một tiêu chuẩn cao hơn so với việc viết C với các lớp.

Câu hỏi của tôi là, ai đúng, tôi nên làm gì?

Làm rõ: Cố gắng tận dụng toàn bộ tiềm năng của ngôn ngữ, không có nghĩa là tôi ném TMP vào mọi vấn đề. C ++ là một hộp công cụ và với tôi thành thạo C ++ là về khả năng sử dụng tất cả các công cụ từ hộp và về việc chọn đúng công cụ cho một công việc cụ thể.

Siêu lập trình là OK. Những gì bạn đang cố gắng làm là không ổn.

Tôi sử dụng siêu lập trình mọi lúc trong công việc của mình. Đó là một công cụ mạnh mẽ có thể được sử dụng để làm rất nhiều thứ theo cách dễ đọc và dễ bảo trì hơn. Đây cũng là một trong những phong cách lập trình khó hơn để hiểu, vì vậy nó thực sự cần phải kiếm tiền. Tôi thích nó khi tôi có thể giảm 1000 dòng mã xuống còn 50, nhưng tôi cố gắng hạn chế nó như vậy.

Vấn đề không phải là siêu lập trình, mà là:

Mặt khác, tất cả chúng ta đều là những nhà phát triển C ++ chuyên nghiệp và tôi nghĩ chúng ta nên khao khát một tiêu chuẩn cao hơn so với việc viết C với các lớp.

Đây là nơi bạn gặp rắc rối. Bạn có ý kiến. Thật tốt khi có ý kiến ​​rằng siêu lập trình là tốt. Thật tốt khi có ý kiến ​​rằng tất cả chúng ta nên khao khát trở thành nhà phát triển C ++ tốt hơn.

Sẽ không ổn khi bắt buộc cả đồng nghiệp và người thuê trong tương lai, những người sẽ phải duy trì mã bạn đã viết để đồng ý với ý kiến ​​của bạn. Đó là công việc của sếp bạn. Sếp của bạn là người nên quan tâm đến việc đảm bảo rằng mã của bạn có thể được duy trì trong thời gian dài. Họ (hy vọng) có nhiều kinh nghiệm kinh doanh hơn, bởi vì hãy tin tôi khi tôi nói đó là một quyết định kinh doanh, không phải là một quyết định ý thức hệ.

Nó là tốt để muốn metaprogram. Sẽ rất tốt nếu bạn muốn dạy người khác lập trình siêu dữ liệu. Nhưng hãy hiểu rằng cũng tốt cho những người khác chọn không học lập trình siêu dữ liệu, và điều đó sẽ đúng cho đến khi bạn ở trong một vị trí quyền lực. (và, như một bí mật của ngành: khi cuối cùng bạn là nhà phát triển chính, ở vị trí quyền lực, bạn hoàn toàn không ở vị trí quyền lực. Có ai đó đang điều khiển những kẻ theo đuổi quyền lực).

Nếu bạn muốn khuyến khích họ ổn với siêu lập trình, hãy bắt đầu nhỏ . Bắt đầu với một enable_ifcái giúp API dễ đọc hơn. Sau đó nhận xét ánh sáng ban ngày của nó. Sau đó, có thể tìm thấy một trường hợp trong đó một siêu dữ liệu mẫu biến 10 lớp lặp lại lớn thành 1 lớp với 10 người trợ giúp nhỏ. Bình luận cái quái gì đó Nhận phản hồi. Tìm những gì mọi người nghĩ về nó. Sẽ ổn nếu họ bảo bạn đừng làm điều đó. Tìm một vị trí thích hợp trong đó siêu lập trình kiếm được tiền kỹ lưỡng đến mức tất cả các đồng nghiệp của bạn (bắt đầu) đồng ý rằng đó là công cụ phù hợp cho công việc.

Như một câu chuyện ngắn, tôi đã viết một thư viện đẹp một lần, sử dụng siêu lập trình mở rộng. Nó đã làm chính xác những gì chúng ta cần vào thời điểm đó, khi không có cách tiếp cận nào khác có thể đến gần. Nó thực sự đã thay đổi hướng của ứng dụng mà tôi đang viết. Nhưng nó đã được lập trình siêu dữ liệu. Chỉ một hoặc hai người khác trong toàn bộ công ty của tôi có thể đọc nó.

Sau đó, đồng nghiệp của tôi đã đâm một vấn đề khác. Thay vì tận dụng siêu lập trình để làm chính xác những gì cần thiết, ông đã làm việc với lãnh đạo để nới lỏng các ràng buộc đã đặt ra cho vấn đề sao cho việc lập trình siêu dữ liệu là không cần thiết. Có lẽ chính xác hơn, siêu lập trình là ít cần thiết hơn . Anh ấy đã có thể giới hạn nó với những gì siêu lập trình làm tốt nhất.

Các thư viện kết quả hiện đang ở một vị trí để được sử dụng trong một đáng kể thị trường rộng, và đó là chắc chắn một phần không nhỏ do thực tế rằng mã mới có thể được duy trì bởi một phạm vi rộng rãi hơn của các nhà phát triển. Tôi tự hào mở đường với siêu lập trình, nhưng đó là mã của đồng nghiệp của tôi sẽ tiếp cận đối tượng rộng hơn và có lý do chính đáng cho điều đó.

Đầu tiên và quan trọng nhất, đây là vấn đề của nhóm và bạn phải giải quyết nó với nhóm. Nếu bạn có bản sao lưu từ nhóm để lập trình bằng các phần tử và cấu trúc nhất định, hãy làm điều đó; nếu không, hãy thảo luận với họ và nếu bạn không thể thuyết phục họ và đưa ra một trường hợp mạnh mẽ tại sao "cách tiếp cận của bạn" rõ ràng tốt hơn, bạn sẽ tốt hơn nếu không sử dụng nó.

Lưu ý rằng việc sử dụng lập trình meta mẫu trong C ++ luôn là một sự đánh đổi: chắc chắn, đôi khi nó có thể giúp thiết kế một số phần nhất định của ứng dụng DRY hơn và nó rất hữu ích để tạo các thư viện hiệu quả cao và có thể tái sử dụng cao.

Mặt khác, những lợi ích này đi kèm với chi phí nhất định: mã được trừu tượng hơn, thường nhiều khó khăn hơn để đọc, nhiều khó khăn hơn để gỡ lỗi và nhiều khó khăn hơn để duy trì. Điều này làm cho tính hữu dụng của lập trình meta trong lập trình ứng dụng thường bị nghi ngờ. Vì vậy, giả sử bạn sẽ không tạo STL tiếp theo, mỗi khi bạn muốn sử dụng lập trình meta, hãy tự hỏi xem những nhược điểm đó có thực sự đáng giá không. Và nếu bạn không chắc chắn, hãy thảo luận điều này với người đánh giá ngang hàng của bạn trong quá trình xem xét mã.

Ý kiến ​​chung của tôi: nếu bạn có một lựa chọn, như thường lệ, giữa ba tùy chọn sau:

• Gõ nhiều cấu trúc mã không cần thiết lặp đi lặp lại bằng tay;
• Sử dụng siêu lập trình mẫu C ++ để tự động tạo mã;
• Sử dụng một số cơ chế tạo mã khác, chẳng hạn như macro hoặc một số ngôn ngữ lập trình khác để tạo tệp nguồn C ++

sau đó lập trình siêu mẫu, được thực hiện đúng cách, có thể sẽ dễ đọc và duy trì nhất trong ba tùy chọn. Đây là lập luận mà tôi sẽ đưa ra cho đội, nếu tôi ở vị trí của bạn. Các ví dụ với mã thực tế sẽ giúp thuyết phục họ.

Khi bạn sử dụng Lập trình siêu mẫu ( TMP ) để tránh lặp lại, bạn nên sử dụng nó để xây dựng các bản tóm tắt được kiểm tra kỹ lưỡng, được kiểm tra cẩn thận nhằm bản địa hóa độ phức tạp trong mã TMP, giúp dễ dàng viết mã máy khách chính xác. Đây là thiết kế của thư viện chuẩn C ++.

Tôi không nghĩ rằng chúng ta có thể đánh giá ai đúng hay sai mà không xem ví dụ về loại mã bạn đang cố viết.

Các nhà phát triển phần mềm nên khao khát viết mã hoạt động, hoạt động rõ ràng, có thể được kiểm tra, có thể được xem xét, có thể gỡ lỗi và có thể được điều chỉnh khi cần thay đổi. Nếu viết "C với các lớp" đạt được điều này, thì nó vẫn ổn.

Và đây là những tiêu chuẩn mà bạn nên đo lường mã của mình. Đặc biệt: Nó hoạt động rõ ràng, nó có thể được thử nghiệm, nó có thể được xem xét, nó có thể được gỡ lỗi và nó có thể được điều chỉnh khi cần không?

Một lập luận từ lòng trắc ẩn:

Công việc của bạn có cho thời gian rảnh để học, hoặc thay vào đó, bạn có thể thuyết phục sếp phân bổ một số giờ để học các tính năng ngôn ngữ này không?

Nếu không, sử dụng những thứ đó về cơ bản là cho họ thêm công việc không được trả lương. Bạn có thể nghĩ rằng một lập trình viên C ++ nên biết toàn bộ ngôn ngữ, hoặc một cái gì đó tương tự, nhưng một điểm học thuật không làm giảm gánh nặng mà bạn sẽ đặt ra cho họ. Đồng nghiệp của bạn có con, cha mẹ ốm yếu, vợ / chồng ốm yếu - hoặc địa ngục, chỉ là một cuộc sống xã hội hợp lý không liên quan đến việc học C ++. Đối thủ mạnh mẽ hơn trong đề xuất của bạn có thể lười biếng - hoặc họ có thể sẽ hoàn thành một khoảng thời gian khó khăn và không cần thêm shit trong cuộc sống của họ ngay bây giờ.

Mã phải được viết trước tiên để con người đọc và chỉ tình cờ cho trình biên dịch phân tích cú pháp.

Bây giờ điều cần nhớ về TMP không tầm thường là bạn đang hạn chế số lượng người có thể đọc mã đó, đó có thể là một sự đánh đổi hợp lệ, nhưng tôi sẽ tranh luận nhiều hơn về sự đánh đổi hợp lý trong các thư viện và như vậy bạn có đội ngũ chuyên gia nhỏ của các chuyên gia sau đó nó là trong một ứng dụng lớn hơn.

Khi bạn rút ra tất cả các mánh khóe trong cuốn sách mà bạn áp đặt chi phí cho những người khác vì giờ họ cần hiểu ngôn ngữ bao gồm tất cả các trường hợp góc luật sư mà bạn đã khai thác, bạn cũng phải trả một khoản chi phí cho việc thuê mà bạn đã nâng thanh để làm việc trên ứng dụng một cách hữu ích, bây giờ có lẽ điều đó đáng giá, nhưng hãy xem chi phí ....

Đối với tôi, gõ nhiều hơn một chút, thậm chí có thể sao chép mã, nhưng tôi có thể đặt trước Mr "C với các lớp cộng với STL" khi nó cần sửa đổi sẽ hữu ích hơn rất nhiều sau đó là một điều TMP cực kỳ thanh lịch mà chỉ tôi mới có thể duy trì (Và do đó sẽ được duy trì mãi mãi). Cũng cần nhớ rằng anh chàng C với các lớp có thể là chuyên gia về vấn đề này và chuyên môn đó thường có giá trị hơn rất nhiều khi trở thành một luật sư ngôn ngữ.

Tôi quên người đã nói điều đó nhưng "Mọi người đều biết rằng việc gỡ lỗi khó hơn sau đó viết nó ngay từ đầu, vì vậy nếu bạn lập trình nó một cách khéo léo nhất có thể, bạn sẽ gỡ lỗi bằng cách nào?".

Ngay cả khi tôi có thể viết thực sự ra C ++ hiện đại, tôi thường không thích, điều đó có nghĩa là tôi phải làm ít hơn về lập trình bảo trì.

Không, bạn không nên. Bạn được sử dụng để sản xuất mã thỏa mãn một đặc điểm kỹ thuật. Mã này phải được duy trì không phải là một chuyến đi bản ngã. Bạn có thể bị điều khiển bởi một chiếc xe buýt vào ngày mai, vì vậy ai đó phải có thể nhận mã của bạn và thực hiện nhiệm vụ trong tay. Tuy nhiên, điều tích cực là cố gắng thuyết phục nhà tuyển dụng của bạn kết hợp các kỹ thuật mới vào các tiêu chuẩn lập trình của họ.

Cách duy nhất để trả lời câu hỏi này trong ngữ cảnh là xem xét các vấn đề cụ thể và cách cụ thể mà bạn đã giải quyết chúng bằng lập trình meta. Trừ khi bạn đăng mã ở đây, chúng tôi không thể biết liệu bạn có đắm chìm trong một sự phức tạp không cần thiết hay không, đó là niềm vui cho một mình bạn "giải quyết" một vấn đề không tồn tại; hoặc liệu bạn có sử dụng toàn bộ sức mạnh của ngôn ngữ để viết một giải pháp đơn giản, thanh lịch không có sẵn bằng các phương tiện khác.

Nếu đó là cái sau, tôi sẽ khuyến khích bạn tiếp tục làm như vậy cùng với nhóm của bạn.Mỗi nhóm tốt phải thực hiện đánh giá mã có ý nghĩa, không chỉ thảo luận về các vấn đề về phong cách mà còn về việc giải pháp của lập trình viên có sử dụng phương pháp tốt nhất, sử dụng các tính năng ngôn ngữ phù hợp, có thể duy trì và kiểm tra được không, v.v. Giải pháp lập trình meta của bạn nên điền vào một phiên đánh giá như vậy, có khả năng cả buổi chiều. Các lập trình viên từ chối cách tiếp cận của bạn nên đưa ra các lựa chọn thay thế (như tạo mã với perl, sao chép mã, v.v.) và chỉ ra cách nó thực hiện theo các tiêu chí được đề cập, so với giải pháp của bạn. Công việc của bạn, với tư cách là "đối thủ" thân thiện của họ trong cuộc tranh luận, là cho thấy rằng đó là một cách để hoàn thành công việc nhanh chóng, bảo trì dễ dàng, kiểm tra dễ dàng và mã thực sự có thể đọc được khi bạn vượt qua rào cản phân tích ngữ pháp vui nhộn.

Hầu hết các lập trình viên đều lười biếng và thích các giải pháp nhỏ, thanh lịch. Nếu bạn là một, rất có thể bạn có thể thuyết phục họ, đặc biệt là nếu các lựa chọn thay thế được chứng minh là ngắn.

Không có một câu trả lời đúng cho câu hỏi này.

Bởi vì điều đầu tiên bạn nên tự hỏi mình là: trong tình huống nào bạn được đặt bởi công việc của bạn? Một số người thực sự được thuê làm khỉ mã để mã hóa các thông số kỹ thuật, những người khác được tuyển dụng làm người chơi nhóm, những người khác được thuê làm công nhân tri thức hoặc chuyên gia.

Điểm mấu chốt duy nhất không đổi là bạn cần xem xét nó từ quan điểm của chủ lao động, vì về cơ bản, điều này có nghĩa là trở thành một nhân viên. Đôi khi đó là lợi ích tốt nhất của chủ nhân của bạn thực sự để thúc đẩy các đồng nghiệp của bạn trở nên tốt hơn và thành thạo các kỹ thuật tiên tiến. Tuy nhiên, trong một tình huống khác, bạn có thể tạo ra nhiều vấn đề và trách nhiệm pháp lý và gây nguy hiểm cho sự thành công của các dự án bạn tham gia.

Câu hỏi không thực sự là liệu lập trình meta có ổn hay không, mà là về việc liệu nó có tốt hơn những người khác trong nhóm hay không, vì vậy đây là một vài điểm gây tranh cãi về cách tôi nhìn thấy nó ...

Gần đây tôi đã chuyển sang một công việc mới, nơi tôi đang làm việc trong một nhóm lớn hơn và [lập trình meta] này làm lo lắng một số đồng nghiệp của tôi, vì họ không hiểu được nó.

Họ lo lắng rằng bạn tốt hơn họ. Điều đó thật tốt. Bạn sẽ trở thành chuyên gia mới. Bạn vừa phá hủy thế giới hiện trạng của họ.

Tôi luôn cố gắng tận dụng toàn bộ tiềm năng của ngôn ngữ, nhưng một số (không phải tất cả) các đồng nghiệp của tôi cho rằng đó là một rủi ro (một số hoan nghênh cách tiếp cận).

Chắc chắn, không ai thích kém kỹ năng hơn bất kỳ ai khác, vì vậy họ đang cố gắng ngăn bạn sử dụng các kỹ thuật quá phức tạp đối với họ. Họ không thể hiểu nó hoặc sẽ không, bởi vì họ cảm thấy an toàn ngay bây giờ.

Tôi đồng ý rằng đó là một vấn đề để viết mã mà không ai khác trong nhóm có thể hiểu được.

Tôi không. Tôi nghĩ rằng nó thể hiện chuyên môn của bạn.

Câu hỏi của tôi là, ai đúng, tôi nên làm gì?

Bạn nên sử dụng tất cả các kỹ năng của mình để viết mã tốt nhất bạn có thể viết và đừng nhìn vào phía sau những người không hiểu nó. Nếu không, bạn sẽ bị kẹt ở cấp độ của họ và chỉ là một lập trình viên bình thường. Đó là một điều tốt để tốt hơn những người khác, và đó là một điều tốt để phấn đấu để trở nên tốt hơn họ. Bạn sẽ không bao giờ có được bất kỳ trải nghiệm mới nào nếu bạn không thử sử dụng bất kỳ thứ gì mới hoặc làm những điều khác biệt.

Tôi biết tôi sẽ bị hạ thấp, nhưng đây là cách nó trông như thế nào. Nó không phải là tội ác để tốt hơn những người khác trong đội và không phải là tội phạm khi sử dụng các kỹ năng của bạn. Chỉ là mọi người đều sợ phải thừa nhận điều đó ... bởi vì họ ở phía không có kỹ năng và ghét rằng anh chàng mới đột nhiên có thể làm điều gì đó họ không thể. Nếu họ thông minh, họ sẽ nhờ bạn giúp đỡ và cho lời khuyên và không chỉ trích mã của bạn là không thể hiểu được.

BIÊN TẬP

Dường như có rất nhiều nhầm lẫn về câu hỏi này. Như các ý kiến ​​cho thấy nhiều người nghĩ rằng đó là về khả năng đọc mã chung. Không, không phải vậy. Đó là về việc các tính năng / cấu trúc ngôn ngữ nhất định nên bị cấm hoặc tránh vì một số thành viên trong nhóm không hiểu chúng.

Câu trả lời của tôi là không . Họ không nên bị cấm. Nếu bạn muốn cấm một cái gì đó, làm thế nào bạn sẽ làm điều đó? Bạn sẽ phải chuẩn bị một số câu hỏi để tìm hiểu những gì các thành viên trong nhóm của bạn có thể và không thể - hoặc đúng hơn là không muốn học vì tôi nghĩ rằng tất cả các tính năng languague đều hữu ích ở đâu đó vì vậy luôn biết chúng và có thể sử dụng chúng tốt và bạn càng biết nhiều mã bạn có thể viết. Bạn cũng cần một thang đo để xác định các tính năng nào là dành cho người mới bắt đầu, trung cấp hoặc nâng cao.

Để chứng minh những hạn chế ngớ ngẩn như vậy, hãy lấy một ví dụ rất đơn giản: bạn sẽ được thuê làm kỹ sư phần mềm nhưng ông chủ tương lai của bạn nói với bạn rằng bạn sẽ không được phép sử dụng do/whilecác vòng lặp vì có một vài người trên nhóm chưa bao giờ sử dụng chúng trước đây và cũng sẽ không tham gia vì họ luôn sử dụng forcác vòng lặp cho mọi thứ để họ thấy do/whilecác vòng lặp khó hiểu.

Bây giờ bạn nghĩ điều này là ngu ngốc và điên rồ, phải không? Nhưng như vậy là cấm các tính năng khác. Một số poeple có thể sử dụng chúng và những người khác không muốn tìm hiểu chúng.

Tại sao bạn nên tạo mã xấu hơn nếu bạn biết có một cái gì đó cho phép bạn làm điều tương tự với ít nỗ lực hơn và kết quả là mã dễ đọc hơn nhiều là mã mạnh mẽ?

Và không quan trọng bạn chỉ sử dụng các tính năng ngôn ngữ cơ bản hoặc nâng cao, bạn có thể sử dụng một trong hai để tạo ra một mã không thể nhầm lẫn và không thể nhầm lẫn được vì vậy đây là một chủ đề hoàn toàn khác.