Làm thế nào để bạn khuyến khích tổ chức của bạn chuyển từ Java sang Scala? [đóng cửa]


15

Có ai tổ chức đã bắt đầu di chuyển từ Java sang Scala chưa? Nếu có, làm thế nào để bạn làm điều đó? Tôi có thể làm gì để khuyến khích các đồng nghiệp của mình làm điều tương tự?


vui lòng thêm scala và di chuyển vào thẻ nếu bạn có quyền làm như vậy
nanda

9
Có lẽ bạn nên giải thích tại sao
TheLQ

Bạn cần có đủ kiến ​​thức trong nhà để đảm bảo yếu tố xe buýt "đủ cao".

Câu trả lời:


15

Có lẽ cách dễ nhất là trước tiên chỉ sử dụng Scala để thử nghiệm. Trong trường hợp này, bạn thậm chí có thể không phải nói với sếp của mình :-) Nếu anh ta hỏi, hãy nói với anh ta "đó chỉ là trường hợp thử nghiệm riêng tư của tôi, việc sử dụng Scala cho nó dễ dàng hơn và nhanh hơn nhiều". Khi bạn (và tổ chức của bạn) có đủ kinh nghiệm với Scala, bạn có thể bắt đầu sử dụng nó cho mã 'thực'.


Đây là những suy nghĩ của tôi, chính xác, cho việc di chuyển C # -to-F #.
GregC

7

Từ quan điểm của các công ty, tốt hơn là ở lại với Java nếu không có lợi thế khác biệt mà họ sẽ có được bằng cách di chuyển sang Scala. Việc thuê lập trình viên Java để xây dựng và duy trì ứng dụng sẽ dễ dàng hơn. Bạn có thể rời đi sau khi thực hiện mọi thứ trong Scala :-) Không vi phạm :-)


1
Đồng bằng Java là ở đây để ở lại. Scala có thể hoặc không. Còn quá sớm để nói.

"Việc thuê các nhà phát triển Java dễ dàng hơn" có lẽ đúng. Nhưng thuê những người "dễ thuê" có thể không phải là cách rẻ nhất để hoàn thành dự án của bạn.
kevin cline

7

Để sếp của bạn đọc những kinh nghiệm như thế này:

  1. Hiện tại tôi đang làm hầu hết mọi thứ ở Scala. (Tôi nên đề cập rằng tôi nghĩ rằng Scala là điều tốt nhất kể từ khi phát minh ra bánh xe cách đây một thời gian. :-D)

    Theo ý kiến ​​khiêm tốn của tôi, đó là ngôn ngữ duy nhất thực sự cho phép mọi người chọn cách tiếp cận tốt nhất cho một nhiệm vụ mà không có sự phân chia không cần thiết giữa (nhiều hơn) hướng tiếp cận theo hướng đối tượng và (nhiều hơn).

    Nhìn vào các ngôn ngữ đã tuyên bố một cái gì đó như thế này trước đây, về cơ bản tôi có thể thấy hai trại thiết kế ngôn ngữ cạnh tranh:

    • Những người từ phía hướng đối tượng đã thấy rằng lập trình chức năng đã đạt được một số lực kéo gần đây và nghĩ rằng "Chà, chúng tôi không thực sự hiểu điều đó về chức năng, nhưng hãy thêm một số đường cú pháp ưa thích vào ngôn ngữ của chúng tôi, vì vậy chúng tôi có thể khẳng định đó là chức năng quá!" (ví dụ: Java, Python)

    • Sau đó, những người từ phía chức năng, người nghĩ rằng "Chà, cách tiếp cận chức năng của chúng tôi vượt trội hơn bất cứ thứ gì khác và sự vô nghĩa hướng đối tượng đó gây phiền nhiễu, nhưng hãy đặt một số từ khóa bổ sung vào ngôn ngữ của chúng tôi, điều đó sẽ khiến ngôn ngữ của chúng tôi thoát khỏi giới hàn lâm. ! " (ví dụ: F #, OCaml)

    Các nhà thiết kế của Scala đã thống nhất nhiều cách tiếp cận đến từ cả hai phía và tạo ra một số ngôn ngữ được thiết kế tốt, theo ý kiến ​​khiêm tốn của tôi - sự khác biệt lớn nhất so với các ngôn ngữ khác, đã quyết định áp dụng phương pháp "Frankenstein" vào thiết kế ngôn ngữ lập trình.

  2. Chỉ thực hiện những điều nhỏ hơn với thang máy và chỉ có kinh nghiệm hời hợt với Rails và Django, tôi phải thừa nhận rằng hầu hết thời gian tôi tự hỏi tại sao một cái gì đó trong thang máy hoạt động khác với những gì tôi mong đợi, điều này là do sự mong đợi của tôi là thiếu sót và nâng cấp của phương pháp tiếp cận.

    Nâng chắc chắn không phải là "giới thiệu dễ dàng về Scala" nhưng học cách thức hoạt động của thang máy cũng gần như bổ ích như học Scala trước đó.

    Khả năng có một chế độ xem "sạch" mà không có bất kỳ logic nào trong đó là một sự cải tiến tuyệt vời cho các khung công tác khác cũng tuyên bố tương tự, nhưng không đạt được điều đó. Hỗ trợ bằng chữ XML của Scala cho phép xác minh mức độ phù hợp của phản hồi của bạn: Trình biên dịch sẽ chứng minh tại thời điểm biên dịch rằng bạn chỉ phát XML được định dạng tốt cho máy khách.

  3. Nâng là công nghệ khả thi và hiện tại là cách tiếp cận thực sự duy nhất nếu bạn muốn xây dựng các ứng dụng web trông, cảm nhận và hoạt động giống như các ứng dụng máy tính "thực" mà không cần tự viết số lượng mã điên rồ.

[ Nguồn ]


3

Trong hai năm qua, chúng tôi đã tiến bộ một cách công bằng trên hành trình này tại Guardian.co.uk - Nền tảng mở của chúng tôi được xây dựng trên Scala, CMS cốt lõi của chúng tôi (ban đầu là Java) đang dần kết hợp thêm Scala (chúng tôi sẽ sớm chuyển từ Maven to SBT cho bản dựng của chúng tôi) và đó là một trải nghiệm tuyệt vời - thực sự tiếp thêm sinh lực cho các nhà phát triển của chúng tôi, một số người đã trở nên hơi khó hiểu với Java :)

Tôi khuyến khích bạn đọc hai bài viết này về quá trình chuyển đổi của chúng tôi và có thể sử dụng chúng làm bằng chứng hỗ trợ cho mái tóc nhọn của bạn:

http://skillsmatter.com/podcast/home/how-we-mond-from-java-to-scala

http://www.infoq.com/articles/guardian_scala

Một số mẹo nhanh:

  • Bắt đầu bằng cách viết bài kiểm tra của bạn bằng Scala - theo cách đó bạn có thể làm quen với ngôn ngữ, tăng sự tự tin về ngôn ngữ đó và không phải chinh phục bất kỳ nỗi sợ nào mà bạn có thể có về việc thêm thời gian chạy vào máy chủ sản xuất của mình ngay lập tức.

  • Đừng xin phép thử các công nghệ mới. Tốt hơn là yêu cầu sự tha thứ nếu bạn phải :-)


+1! cho "Đừng xin phép thử công nghệ mới. Tốt hơn là xin tha thứ nếu bạn phải :-)"
Giorgio

2

Câu hỏi này đuôi bồ câu trong một câu hỏi khác. Đó là đối với những loại hoặc dự án nào di chuyển đến Scala cung cấp giá trị gia tăng? Tôi làm công việc Java hàng ngày, nhưng mơ về ngày tôi có thể sử dụng Scala "trong sự tức giận".

Một vài câu trả lời cho câu hỏi của riêng tôi:

  • Các vấn đề mà đồng thời dựa trên diễn viên sẽ mang lại lợi ích lớn (Akka)

  • Các ứng dụng web có dữ liệu được đẩy đến chúng thông qua COMET (Nâng)

Bất kỳ hiểu biết khác hoặc kinh nghiệm tốt hơn chưa?


1

Tôi đang viết bài kiểm tra cho các ứng dụng Java của mình trong Scala và đồng ý rằng đó là một nơi tốt để bắt đầu. Phạm vi kiểm tra của tôi tốt hơn vì viết nhanh hơn và dễ dàng hơn (kể từ khi tôi sử dụng Scala, tôi sẵn sàng tập trung vào viết bài kiểm tra nhiều hơn).

Tôi cũng đã bắt đầu thực hiện các nguyên mẫu và POCs vứt đi trong Scala khá nhiều. Tôi cố gắng làm cho các nhà quản lý và giám sát nhận thức rõ nhất có thể rằng tôi đã sử dụng Scala cho những lần này và nhấn mạnh rằng tôi có thể có được thứ gì đó và chạy nhanh vì Scala. Chúng tôi cần (tốt, loại cần thiết) một ứng dụng web để theo dõi trò chơi voi trắng trong bữa tiệc của chúng tôi - 1,5 giờ với Scalatra và MongoDB và toàn bộ bộ phận của tôi đang xem ứng dụng này và hỏi về nó. Hãy đối mặt với điều đó, bạn sẽ không bao giờ nhận được bất cứ nơi nào mô tả cho các nhà quản lý mức độ biểu cảm của ngôn ngữ nhiều hơn hoặc mô hình tương tranh của nó tốt hơn nhiều. Nhưng nếu bạn cho họ thấy bạn có thể hoàn thành công việc nhanh hơn, bạn sẽ có được chỗ đứng.

Nhưng tôi nghĩ phần lớn nhất là khiến các nhà phát triển hào hứng với Scala. Tôi chắc rằng tất cả chúng ta đều làm việc với nhà phát triển, những người không tích cực theo kịp công nghệ mới và đôi khi thật khó để khiến những người đó hào hứng làm bất cứ điều gì mới (tại sao, tôi thực sự không hiểu). Hiển thị cho những người này một số lợi ích của Scala (thử REPL) là chìa khóa. Nếu bạn nhận được đủ các nhà phát triển ầm ĩ về cùng lợi ích của năng suất, thì bạn có nhiều khả năng để Scala chính thức được thông qua trong tổ chức của bạn.

Truyền bá và nhận được rằng nỗ lực cơ sở là mục tiêu chính của tôi trong năm 2011. Chúng ta sẽ thấy nó như thế nào, bởi vì tôi không thể chờ đến ngày tôi có thể sử dụng Scala cho phần lớn công việc của mình.


1

Tôi đang tự hỏi tại sao chọn cái này hay cái kia? Tại sao quyết định ném Java ra khỏi cửa và đi hết Scala?

Không có thứ gọi là công cụ hoàn hảo cho công việc. Không có lý do để ném chuyên môn trong một ngôn ngữ ra khỏi cửa hoàn toàn và thay thế nó bằng ngôn ngữ khác.

Tôi sẽ không muốn làm việc (nữa) tại một công ty tập trung vào một ngôn ngữ hoặc môi trường, tbh. Tốt hơn là nên biết nhiều thứ và chọn công cụ phù hợp cho công việc.

Bên cạnh đó, thật khó nếu không thể khiến tổ chức của bạn chuyển hoàn toàn sang Scala. Thay vào đó, tôi sẽ cố gắng thực hiện một số dự án (hoặc thậm chí là một phần của các dự án) trong Scala, thay vì đi theo cách tiếp cận tất cả hoặc không có gì. Ví dụ, bạn có thể chọn kiểm tra mã Java của mình bằng Specs2, có cú pháp khá hay so với JUnit cũ - và nó cũng không phức tạp, khó hiểu và mã Scala, chỉ là cú pháp cú pháp xung quanh việc xác định hành vi của ứng dụng của bạn .


0

Một cách tốt là thể hiện hai phiên bản của cùng một chương trình. Bằng cách đó, bạn có thể cho các đồng nghiệp của mình (trong thực tế) Tính biểu cảm của Scala . Làm điều tương tự cho các vấn đề khác (XML, đồng thời, v.v.) có thể chứng minh lợi ích của việc sử dụng Scala thay vì Java để giải quyết các vấn đề cụ thể.

Tất nhiên đừng mong đợi sự di cư sẽ xảy ra trong một ngày. Có nhiều vấn đề mà bạn có thể đánh giá thấp: Đường cong học tập, cơ sở mã hiện có, v.v.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.