Các vấn đề (như bảo trì) trong phát triển với ngôn ngữ không phổ biến

Tôi đang phát triển một số ứng dụng với clojure (lisp) một mình trong nhóm của mình. Nó bắt đầu như một ứng dụng nhỏ. Không vấn đề gì. Nhưng khi nó có các tính năng và mở rộng khu vực, nó trở thành chương trình quan trọng.

Tôi lo lắng về bảo trì hoặc một cái gì đó. Không ai trong nhóm của tôi biết clojure hoặc lisp và cũng không quan tâm đến các ngôn ngữ như chúng.

Vì vậy, không sai khi lập trình bằng các ngôn ngữ không phổ biến? (vì niềm vui của riêng tôi?) Tôi có nên sử dụng các ngôn ngữ phổ biến hơn không? (ít nhất là như trăn)

Tôi chắc chắn nếu tôi rời đội, - đừng nói tôi sẽ rời đi. :) - không ai sẽ duy trì nó. Chương trình này sẽ bị phá hủy và một số sẽ phát triển với ngôn ngữ khác.

Mặc dù vậy, tôi rất thích phát triển với clojure, tôi đã tình cờ thấy rằng điều này có thể không dành cho đội của tôi.

Bạn nghĩ gì về điều này? Tôi nghĩ rằng nhiều lập trình viên yêu thích các ngôn ngữ không phổ biến đã liên quan đến vấn đề tương tự.

Tôi cảm thấy nỗi đau của bạn, tôi rất thích làm thêm mã hóa trong lập trình chức năng (Haskell trông rất vui!). Tôi cảm thấy như mình chỉ bị trầy xước bề mặt vì tôi chưa sử dụng nó trong bối cảnh kinh doanh.

Tôi sẽ đề nghị chống lại làm điều đó mặc dù . Nếu bạn lập trình bằng một ngôn ngữ chỉ bạn biết thì chỉ có bạn mới có thể hỗ trợ nó. Trừ khi bạn muốn giải quyết mọi vấn đề hỗ trợ (Ngay cả khi bạn có thời hạn / ưu tiên khác) thì hãy viết mã bằng ngôn ngữ mà nhóm của bạn biết và có thể hỗ trợ. Điều gì xảy ra khi một cái gì đó phá vỡ trong khi bạn đang đi nghỉ? Điều gì xảy ra nếu bạn muốn được thăng chức?

Tôi muốn giới thiệu bạn có ít nhất một thành viên khác trong nhóm với bạn. Chỉ cho họ một số tính năng ngôn ngữ thú vị. Với hai người trên tàu, nó trở nên khả thi và bạn sẽ không được tải tất cả các hỗ trợ.

Tôi chắc chắn nếu tôi rời đội, - đừng nói tôi sẽ rời đi. :) - không ai sẽ duy trì nó.

Có thể sai.

Nếu chương trình có giá trị và quản lý thấy giá trị, họ sẽ giao nhiệm vụ cho ai đó học Clojure và duy trì nó.

Xảy ra mọi lúc.

Chương trình này sẽ bị phá hủy và một số sẽ phát triển với ngôn ngữ khác.

Luôn luôn đúng. Vậy tại sao phải lo lắng về nó?

Tất cả các chương trình cuối cùng phải được thay thế.

Tôi chính xác là nơi bạn hình dung người kế nhiệm của mình đang ở. Tôi được giao nhiệm vụ thêm các tính năng vào một chương trình cũ sử dụng Clojure và Erlang để thực hiện tìm kiếm không đồng bộ và biến nó thành một chương trình tìm kiếm không đồng bộ. Khi tôi vào công việc này, tất cả những gì tôi biết là Python và Java.

Lời khuyên của tôi cho bạn: sử dụng công cụ tốt nhất cho công việc . Nếu công cụ đó là Clojure, thì nó cũng vậy. Ngôn ngữ lập trình không khó học. Mã được viết tốt trong một ngôn ngữ phù hợp với nhiệm vụ trong tay luôn dễ đọc hơn mã cố gắng làm điều gì đó mà ngôn ngữ không được thiết kế để làm. Người kế nhiệm của bạn sẽ đọc Clojure sạch sẽ dễ dàng hơn so với Java.

Việc chấp nhận các ngôn ngữ mới hoặc ngôn ngữ " độc lập " bởi một số nhiệm vụ là một rủi ro cao trong một dự án.

Nếu phần đó của hệ thống có vấn đề hoặc phần đó phải bị loại bỏ thay vào đó bạn phải tìm một lập trình viên phải học các kỹ năng về ngôn ngữ đó. Trong cả hai trường hợp, bạn mất rất nhiều thời gian.

Trong một số trường hợp, vấn đề này có thể được sử dụng để cải thiện và đa dạng hóa các kỹ năng của một nhóm theo nhiệm vụ trong tương lai.

Clojure có thể có một cơ sở được cài đặt nhỏ hiện tại (nó xuất hiện vào năm 2007) nhưng nó hầu như không phổ biến - thực tế nó có thể là ngôn ngữ mới "nóng nhất" xung quanh. Tôi sẽ ngạc nhiên nếu bạn không thể tìm thấy những người khác quan tâm đến việc học nó.

Dù sao, việc áp dụng một ngôn ngữ mới tuy nhiên phải luôn luôn là một quyết định dựa trên giá trị cho doanh nghiệp . Bạn có thể thảo luận với người quản lý của mình dọc theo các dòng sau:

Ưu điểm của việc áp dụng Clojure:

• Năng suất cao hơn các ngôn ngữ khác được sử dụng - bằng chứng là số lượng chức năng hữu ích bạn đã cung cấp trong một khoảng thời gian nhỏ và với ít dòng mã hơn
• Chúng tôi đã có một ứng dụng quan trọng (của bạn) được viết bằng Clojure, do đó, đáng để xây dựng các kỹ năng Clojure để duy trì nó (thay vì viết lại đắt tiền)
• Sử dụng Clojure sẽ được coi là sáng tạo và có thể là một cách tốt để thúc đẩy các nhà phát triển tài năng tham gia / ở lại công ty.

Nhược điểm của việc áp dụng Clojure

• Thêm một ngôn ngữ để hỗ trợ
• Các nhà phát triển có thể cần đào tạo nhiều hơn và thời gian để tăng tốc

Nếu tôi là người quản lý đánh giá quyết định này, có lẽ tôi muốn ý tưởng về năng suất cao hơn từ Clojure đủ để cho phép một số thử nghiệm hạn chế và trì hoãn quyết định cho đến khi rõ ràng nhóm đã làm tốt đến mức nào. Trong trường hợp đó, có lẽ bạn sẽ cần phải là một người ủng hộ, hành động như một giáo viên giỏi và giúp đưa những người khác lên tàu.

Đừng lo lắng, hãy hạnh phúc.

Rõ ràng chương trình có giá trị, hoặc bạn sẽ không mở rộng nó. Chúc mừng một dự án thành công. Có lẽ bạn đã chọn Clojure vì làm như vậy tiết kiệm thời gian và do đó tiết kiệm tiền sử dụng lao động của bạn. Nếu bạn đã viết nó bằng Java, thì chương trình sẽ khó khăn hơn để duy trì. Ngay cả khi các đồng nghiệp của bạn có thể dễ dàng hiểu từng dòng chương trình hơn, liệu họ có thể duy trì và mở rộng nó không?

Tôi muốn nói thêm sức mạnh cho bạn! Lisp là Grandaddy của ngôn ngữ máy tính và ngày nay vẫn còn liên quan; thực tế là nó không phổ biến đến mức tôi nghĩ là do thực tế là nó không có các IDE mềm mịn của C # và Java và việc triển khai trình biên dịch chính trong Windows chỉ chạy dưới Cygwin (yuk!). Sự phát triển dường như diễn ra trong Emacs và tôi đoán nó chơi tốt hơn với Linux hoặc Mac.

Cuộc thi viết mã này đã giành chiến thắng bởi một chương trình Lisp năm 2010: http://planetwars.aichallenge.org/

Way trở lại trong ngày họ có thể gỡ lỗi nó sống từ khoảng 100 triệu dặm: http://www.flownet.com/gat/jpl-lisp.html

Bạn chắc chắn đang từ bỏ một lá cờ đỏ bảo trì, nhưng nghĩ về nó như là một cơ hội học tập cho người khác. Nếu bạn đang sử dụng một số ngôn ngữ ác mộng (như MUMPS) hoặc một số ngôn ngữ tẻ nhạt (như TCL) thì tôi nghĩ nên đặt câu hỏi. Nhưng tôi nghĩ bạn nên nghĩ về một chàng trai cố gắng phát huy tốt nhất những truyền thống cũ :)

Có rất nhiều câu trả lời hay nhưng tôi muốn thêm một điểm.

Tôi đã ở trong tình huống tương tự nhưng với một ngôn ngữ khác. Tôi đã phải học mọi thứ một cách khó khăn, tức là thông qua phương pháp thử và sai do thiếu hướng dẫn. Những gì tôi học được 'từ kinh nghiệm của tôi khi bạn chỉ ra bảo trì / mở rộng sẽ trở thành một vấn đề vì người ta có thể không biết cách tiếp cận hiệu quả do thiếu hướng dẫn.

Tôi đề nghị bạn nói chuyện với người quản lý của mình để được giúp đỡ đầy đủ để bạn có thể tránh mọi vấn đề trong tương lai.

Chúc may mắn!

Trong một số trường hợp, một ngôn ngữ như Lisp có thể giúp thực hiện chức năng nhanh hơn hoặc dễ dàng hơn, điều này sẽ rất khó khăn trong một ngôn ngữ khác. Nó cũng ảnh hưởng đến cách bạn nhìn nhận vấn đề, mang đến cho bạn một viễn cảnh mà những người khác trong nhóm của bạn có thể không có. Có một loạt các khả năng và một cái nhìn rộng hơn về những gì có thể có thể rất có giá trị đối với một công ty có thể hiểu và sử dụng chúng. Giá cho những khả năng đó, mặc dù, là thiếu tiêu chuẩn hóa.

Nhiều công ty cố gắng chuẩn hóa một hoặc hai ngôn ngữ vì điều đó giúp họ linh hoạt hơn về tổ chức: họ có thể chuyển các nhà phát triển từ dự án này sang dự án khác mà không phải đào tạo lại, họ có sẵn kiến ​​thức về ngôn ngữ họ sử dụng, và các nhà quản lý không phải xem xét điểm mạnh và điểm yếu của việc sử dụng ngôn ngữ này hay ngôn ngữ khác cho một dự án nhất định. Khi tất cả những gì bạn có là một cái búa, mọi thứ trông giống như một cái đinh.

Như tôi đã phác thảo, cả hai phương pháp đều có những lợi ích và hạn chế nhất định. Như thường lệ, không có cách tiếp cận đúng hay sai. Bạn chỉ đang giao dịch một bộ lợi ích và nhược điểm khác. Một công ty cũng không phải đi theo hướng này hay hướng khác. Hoàn toàn hợp lý để thực hiện hầu hết các công việc trong C ++ hoặc Java, nhưng thỉnh thoảng nhúng ngón chân vào Lisp hoặc Python để thử chúng và xem những gì hoạt động. Có vẻ như đó có thể là những gì công ty của bạn đang làm.

Vì vậy, hãy tiếp tục (nhưng không phải Forth), tìm hiểu càng nhiều càng tốt, và trở thành chuyên gia Clojure mà người quản lý của bạn có thể dựa vào để hiểu rõ hơn về những đồng nghiệp của bạn. Và đừng cảm thấy tồi tệ về điều đó ... lo lắng về công cụ tổ chức là công việc quản lý của bạn.

Tôi khuyên bạn nên bắt đầu viết lại chương trình của mình bằng ngôn ngữ khác (thuận tiện hơn) khi bạn bắt đầu cảm thấy rằng bảo trì có cơ hội cao để chi phối vấn đề.

Nếu bạn quản lý để viết nó trong trạng thái đóng (mà bạn không biết khi nào bạn bắt đầu tạo ứng dụng của mình, như tôi đã hiểu), thì sẽ không có vấn đề gì khi viết lại bằng ngôn ngữ tiện lợi / quen thuộc hơn. Việc đóng cửa sử dụng các khái niệm hoàn toàn khác nhau và do đó việc triển khai có thể khó chuyển sang ngôn ngữ khác. Nhưng điều quan trọng là nếu bạn vui vẻ với việc viết ứng dụng mới, thì bạn có thể thấy thú vị khi chuyển các khái niệm và ý tưởng bạn đã sử dụng sang một ngôn ngữ tiện lợi khác. Có thể rất vui khi so sánh các ngôn ngữ khác nhau và khả năng của chúng. Tôi nghĩ rằng trường hợp của bạn là hoàn hảo cho các thí nghiệm như vậy.

Chắc chắn không sai khi lập trình bằng các ngôn ngữ "không phổ biến". Tại sao bạn thực sự quan tâm nếu họ phổ biến hay không? Tôi hoàn toàn đồng ý với @quanticle về điều này. Nếu Clojure hoặc ngôn ngữ không chính thống khác là công cụ tốt nhất cho vấn đề bạn đang giải quyết, bạn nên chọn nó.

Tôi không thấy lý do tại sao bảo trì sẽ là một vấn đề. Nếu bạn áp dụng Đơn vị, Tích hợp, v.v. Kiểm tra và ghi lại mã của bạn, bất kỳ lập trình viên nào quan tâm đến lập trình chức năng sẽ có thể duy trì chương trình của bạn. IMHO thực tế là các đồng nghiệp của bạn không quan tâm đến Clojure không phải là một lý lẽ tốt cho việc không sử dụng nó, ngoại trừ nếu đó là chính sách của công ty mà bạn cần tôn trọng.

Việc chương trình có được tiếp tục hay không sau khi bạn khởi hành không liên quan đến bạn. Bạn có thể sử dụng ngôn ngữ lập trình bạn để làm cho một cái gì đó mà sếp của bạn thích, nghe có vẻ khá tốt với tôi. Lo lắng về việc tiếp tục là điều mà sếp của bạn nên làm.

Tổ chức một hướng dẫn hoặc một buổi đào tạo. Nếu các thành viên trong nhóm của bạn không muốn hành động như các chuyên gia và nâng cao kiến ​​thức của họ, đặc biệt là nếu chương trình đang trở nên quan trọng hơn là ngoài tầm tay của bạn. Trong trường hợp xấu nhất, bạn có thể nói chuyện với quản lý và họ có thể bắt buộc loại buổi đào tạo này. Bạn có thể trông giống như một kẻ ngốc, nhưng ít nhất bạn sẽ không phải là người duy nhất phải duy trì chương trình. Tùy chọn khác là đề xuất rằng một lập trình viên thứ 2 biết clojure sẽ được thêm vào nhóm.