Điều gì sẽ là lý lẽ thực tế tốt để thuyết phục quản lý cấp cao xem xét lập trình chức năng? [đóng cửa]


15

Có rất nhiều lý lẽ "lý thuyết" cho lý do tại sao lập trình chức năng là một ý tưởng tốt (quá nhiều cho rằng đó vẫn là một câu hỏi mở, và chính xác là như vậy).

Tuy nhiên, hầu hết trong số chúng là các đối số hoặc được tạo ra từ lý thuyết ("sự thanh lịch", v.v ...), hoặc, nhằm vào các nhà phát triển.

Vấn đề là, hầu hết trong số họ hoàn toàn vô dụng khi mục tiêu của một người là trình bày ý tưởng với quản lý cấp cao của một công ty lớn , một số người thậm chí không phải là nhà phát triển và tất cả những người chủ yếu quan tâm đến các lý lẽ kinh doanh : chi phí, quản lý vốn con người , giao sản phẩm, dịch vụ khách hàng và doanh thu; cũng như các sự kiện định lượng về các điểm lý thuyết không thể được sao lưu bằng các sự kiện.

Có bất kỳ đối số thuyết phục nào để trình bày để giải quyết các mối quan tâm kinh doanh đó không, nếu xem xét việc áp dụng lập trình chức năng như một khái niệm (không phải bất kỳ ngôn ngữ cụ thể nào), so với hỗn hợp điển hình của thủ tục / OOP, ví dụ Java / C ++ / (Perl | Python) .

Tốt hơn là, tôi đang tìm kiếm các đối số mang tính định lượng và / hoặc dựa trên nghiên cứu hoặc nghiên cứu trường hợp. Ví dụ: "theo tài liệu tham khảo này, tỷ lệ lỗi của các hệ thống đa luồng trong Lisp / F # là 10% so với Java" hoặc "80% sinh viên tốt nghiệp hàng đầu thể hiện sở thích của công nghệ mong muốn được đặt tên là lập trình theo 3 lợi ích hàng đầu".

Tôi biết rằng Graham đã trình bày các trường hợp sử dụng lập trình chức năng cho một ngôi sao và sẽ mở ra cho một số lập luận của anh ta cho rằng chúng có thể hợp lệ cho một công ty lớn hơn được thành lập.

Tôi hoàn toàn biết rằng bạn có thể làm một cái gì đó gần với lập trình chức năng trong Perl, có thể là Python và (có thể) ngay cả Java 8 hoặc C ++ 14. Nhưng điều đó không có nghĩa là một tổ chức sử dụng Perl, C ++ hoặc Java sẽ chứng thực chức năng so với Phương pháp tiếp cận OOP / thủ tục ngay cả trong các ngôn ngữ đó

Đối với mục đích của ngôn ngữ này, "lớn" được định nghĩa là đủ lớn để có nhóm công cụ / kỹ thuật phát triển chuyên dụng, điều này chỉ ra những gì tất cả các nhà phát triển được phép sử dụng / làm; và ít nhất hàng trăm nhà phát triển ở cấp thấp .


1
Bạn đang tìm kiếm cái này, tôi đoán? paulgraham.com/avg.html Trên thực tế, tôi nghĩ rằng bài viết này hơi lỗi thời, ở giữa rất nhiều khái niệm chức năng đã nhập vào các ngôn ngữ chính.
Doc Brown

34
Tại sao quản lý cấp cao nên đưa ra những ngôn ngữ và phương pháp lập trình được sử dụng? Tại sao họ sẽ tham gia vào một quyết định như vậy? Chắc chắn đó là một vấn đề cho các nhà quản lý kỹ thuật?
Đánh dấu hiệu suất cao

8
@HighPerformanceMark: Thay thế "người quản lý kỹ thuật" cho "quản lý cấp cao" và đánh giá lại câu hỏi.
Robert Harvey

2
Bạn đang kinh doanh gì? Nếu bạn làm lập trình và tư vấn hợp đồng, lập trình chức năng có thể là một từ thông dụng mà quản lý có thể nghĩ sẽ gây ấn tượng với khách hàng của bạn.
JeffO

3
Những đối số kinh doanh nào ban quản lý đã cung cấp cho bạn cho các ngôn ngữ bạn hiện đang sử dụng?
JeffO

Câu trả lời:


7

Có một đối số rất đơn giản, ít nhất có thể gây cười cho ban quản lý.

Người ta biết rằng các máy tính hiện đại không trở nên "nhanh hơn" như trước đây, bởi vì quy mô tần số, bây giờ, đã đạt đến giới hạn. Họ tăng năng suất tiềm năng bằng cách thêm lõi.

Điều này ngụ ý rằng để hưởng lợi nhiều nhất từ ​​kiến ​​trúc này, các chương trình phải được song song hóa. Nhưng lập trình song song khó hơn lập trình tuần tự, do có rất nhiều thách thức mới mà nó mang lại (tham khảo bài viết Wiki để biết tổng quan toàn diện).

Lập trình chức năng giúp loại bỏ một số thách thức này, ví dụ như điều kiện chủng tộc không áp dụng nếu bạn chỉ sử dụng các biến và phương pháp bất biến mà không có tác dụng phụ. Đường cong học tập cho lập trình chức năng thường dốc, nhưng đường cong học lập trình song song có thể còn dốc hơn, và hoàn toàn không trực quan.

Vì vậy, nếu thách thức là viết các chương trình hiệu quả hơn theo cách hiệu quả hơn, người ta có thể so sánh chi phí đào tạo mọi người để viết các chương trình song song với chi phí đào tạo mọi người để học lập trình chức năng và những rủi ro cả hai có thể mang lại.

Về các ngôn ngữ hỗn hợp (hỗ trợ cả phong cách lập trình chức năng và mệnh lệnh): từ một điểm, chúng có thể có ích cho quá trình chuyển đổi (mọi người có thể bắt đầu sử dụng chúng theo cách "quen thuộc" và dần dần học các phương pháp mới). Từ một điểm khác, đây có thể là một phước lành trong việc ngụy trang, bởi vì những lợi thế tiềm năng mà lập trình chức năng mang lại có thể bị hủy bỏ với mã vụng về của ai đó. Người ta có thể giảm thiểu điều này bằng cách thiết lập các nguyên tắc mã hóa rõ ràng (xem ví dụ " Scala hiệu quả " của Twitter), mặc dù theo các hướng dẫn này đòi hỏi một mức độ trưởng thành nhất định của nhóm. Từ quan điểm này, các ngôn ngữ chức năng thuần túy có thể "dễ dàng" hơn cho việc phát triển phần mềm do các quy tắc chặt chẽ hơn mà chúng áp đặt theo thiết kế.


Nếu bạn có thể tìm thấy nghiên cứu / bằng chứng thực tế cho những khẳng định này để sao lưu chúng - đặc biệt là "Ngôn ngữ chức năng giúp loại bỏ một số thách thức này" - cho đến nay, đây đã sẵn sàng là câu trả lời tốt nhất hiện có.
DVK

Chính câu hỏi này đã được thảo luận một vài lần, ví dụ quora.com/Why-does-feftal-programming-favor-concurrency hoặc stackoverflow.com/questions/474497/
Thẻ

3
Ngoại trừ việc nhiều ngôn ngữ OOP cũng hỗ trợ lập trình chức năng, vì vậy bạn có thể sử dụng các khía cạnh chức năng với việc ném em bé ra ngoài bằng nước tắm.
Andy

1
Phải, câu hỏi là về "lập trình chức năng" chứ không phải về "ngôn ngữ chức năng". Sẽ thay đổi từ ngữ.
Ashalynd

40

Bạn đang tiếp cận điều này từ phía sai. Trong hầu hết các công ty, quản lý không chịu trách nhiệm "chọn mô hình lập trình", họ (hoặc ít nhất nên có trách nhiệm) làm cho nhóm làm việc hiệu quả. Nếu toàn bộ nhóm của bạn được thuyết phục lập trình chức năng sẽ cải thiện tốc độ hoặc chất lượng công việc của bạn, thì cũng không quá khó để thuyết phục quản lý. Hơn nữa, nếu nhóm của bạn mới bắt đầu sử dụng các cấu trúc chức năng trong các ngôn ngữ lập trình đã thiết lập của bạn và mọi người đều hài lòng với điều đó, bạn thậm chí không cần phải xin phép (heck, một người không lập trình thậm chí có thể không hiểu sự khác biệt giữa những người không phải là lập trình viên chức năng và cấu trúc chức năng, vậy tại sao bạn muốn thảo luận vấn đề đó với anh ta?).

Nhưng hãy cẩn thận, nếu phần còn lại trong nhóm của bạn có ý kiến ​​khác về FP và họ bắt đầu phàn nàn về mã chức năng của bạn mà các thành viên khác trong nhóm không hiểu, bạn có thể gặp rắc rối với quản lý - vì một lý do chính đáng, vì như vậy trường hợp, nhóm mất hiệu quả.

Vì vậy, ý chính là: thuyết phục các thành viên khác trong nhóm, hoặc các trưởng nhóm của bạn, nhưng, không phải quản lý cấp cao!

EDIT: do nhận xét của bạn - thực sự, đây câu trả lời cho câu hỏi của bạn ;-). Một lý lẽ thực tế mà tôi đang nói đến là "toàn bộ nhóm nghĩ rằng FP rất hữu ích để thực hiện công việc . IMHO đó là đối số có cơ hội nuôi ong cao nhất được quản lý cấp cao chấp nhận và nó rất có thể áp dụng được. đối với những người không có kỹ thuật trực tiếp làm việc, không phải vì họ "quá ngu ngốc để hiểu lý do kỹ thuật", mà bởi vì họ đủ thông minh để biết rằng các quyết định kỹ thuật nên được đưa ra bởi các chuyên gia kỹ thuật, và họ cũng đủ thông minh để không dựa vào về ý kiến ​​của chỉ một chuyên gia.


7
Tôi ngạc nhiên khi 19 người đưa ra một câu trả lời mà không trả lời câu hỏi nào cả . Đó là một câu hỏi thực tế, trong một tình huống thực tế. Các thành viên trong nhóm KHÔNG có tiếng nói và không cần phải bị thuyết phục. Họ cũng sẽ không làm việc - và tôi cũng sẽ không làm điều đó - về công nghệ / ngôn ngữ không được chấp thuận, vì câu hỏi đã rõ ràng.
DVK

1
@DVK nếu không có ai khác sẽ xem mã của bạn, thì bạn không cần phải thuyết phục bất cứ ai khác rằng ngôn ngữ của bạn tốt. Chỉ cần bắt đầu sử dụng nó.
dùng253751

2
@DVK - bạn cần cung cấp thêm thông tin chi tiết về cách quản lý kiểm soát (các) ngôn ngữ được sử dụng trong công ty của bạn. Trong hầu hết các trường hợp, ban quản lý có ít đầu vào trong lĩnh vực này vì họ để lại cho các đội và lãnh đạo của họ.
JeffO

3
@DVK: Mọi người nêu lên những câu trả lời mà họ thấy hữu ích nhất cho câu hỏi trong tầm tay. Nếu hầu hết mọi người đang nâng cao câu trả lời cho biết bạn đang tiếp cận vấn đề sai, thì điều đó có thể gợi ý rằng một số lượng lớn lập trình viên đã gặp phải tình huống tương tự và thấy những câu "không trả lời" này hữu ích. Hầu hết đều đồng ý rằng có một cái gì đó không lành mạnh trong doanh nghiệp của bạn và nó không liên quan gì đến các lựa chọn ngôn ngữ. Hầu hết đều đồng ý rằng cần phải được giải quyết, mọi nỗ lực trực tiếp sau khi lựa chọn ngôn ngữ sẽ chỉ dẫn bạn đến chướng ngại vật tiếp theo, thay vì một loạt giải pháp.
Cort Ammon - Phục hồi Monica

1
@CortAmmon Mặc dù tôi rất vui khi đồng ý rằng câu hỏi cho thấy có gì đó không đúng với cách quản lý của công ty người hỏi, nhưng rất khó có khả năng anh ta có thể khắc phục những vấn đề như vậy. Tôi đã tận mắt nhìn thấy những vấn đề mà CTO gây tranh cãi có thể gây ra (thực tế, chỉ mới hôm qua tôi đã phải dành một khoảng thời gian đáng kể để giải quyết vấn đề do một quy tắc mà công ty chúng tôi sẽ không triển khai phần mềm bên ngoài "tệp chương trình "Các thư mục trên các máy Windows, nhưng Ruby sẽ không cài đặt trong một thư mục có một khoảng trắng trong tên của nó.
Jules

16

Để hiểu lý do tại sao Lập trình chức năng không chiếm lĩnh thế giới, bạn phải hiểu suy nghĩ của công ty đằng sau các quyết định ngôn ngữ lập trình. Để chọn Java trong giây lát:

  1. Có những đội quân lập trình viên có thể viết các đoạn mã Java thông thường. Điều này không đúng với các lập trình viên Lisp hoặc Haskell (hoặc thậm chí là Scala).
  2. Mọi người khác đang sử dụng Java, vì vậy nó phải tốt. Tương quan: các nhà quản lý không phải chứng minh sự lựa chọn Java của họ so với một số ngôn ngữ khó hiểu mà không ai trong cấu trúc lệnh đã từng nghe thấy.

Nếu tổ chức của bạn đã cố thủ trong Vương quốc Danh từ , việc thay đổi bán buôn sang Lập trình Chức năng sẽ không xảy ra. Lựa chọn ngôn ngữ (và tất cả các lựa chọn khác bao quanh nó) đã được nhúng sâu vào văn hóa doanh nghiệp.

Giả sử mục tiêu của bạn là phát triển như một nhà phát triển phần mềm, cách tốt nhất của bạn là

  1. Kết hợp các khái niệm chức năng vào các chương trình hiện có của bạn , nơi chúng hữu ích và phù hợp,
  2. Sử dụng các tính năng ngôn ngữ chức năng mới khi chúng được thêm vào ngôn ngữ và
  3. Tìm hiểu các mẫu thiết kế hướng đối tượng, một số trong đó tồn tại để khắc phục sự thiếu hụt ngôn ngữ trong các ngôn ngữ OO không có trong các ngôn ngữ Chức năng.

Lập luận của Paul Graham thực sự chỉ áp dụng cho các công ty mới thành lập, và đã có một số câu chuyện cảnh báo về các công ty bắt đầu sử dụng ngôn ngữ Chức năng thuần túy, nhưng sau đó họ đã bị mua bởi một công ty khác có đơn đặt hàng đầu tiên là chuyển đổi cơ sở mã chức năng đến một ngôn ngữ OO để các nhà phát triển phần mềm hiện tại của họ có thể hiểu nó.


1
Không, mục tiêu của tôi là KHÔNG (vì mục đích của câu hỏi này) để "phát triển như một nhà phát triển phần mềm". Mục tiêu của tôi là thu thập một loạt các lập luận tốt nhất để trình bày cho những người ra quyết định, điều đó sẽ khiến họ hướng tới việc cho phép FP như cách tiếp cận được phê duyệt. Không hơn không kém. Làm nổi bật các lợi ích của FP, đặc biệt là so với OOP / ngăn xếp thủ tục tiêu chuẩn.
DVK

Ngoài ra, trừ khi tôi mắc một lỗi từ ngữ lớn, câu hỏi chắc chắn không có ý ám chỉ đến "thay đổi bán buôn" là kết quả dự định của các đối số được tìm kiếm.
DVK

+1 cho Vương quốc danh từ. Tôi đã gọi nó là "Cuộc chiến giữa danh từ và động từ".
Cướp

4
@DVK: Cách thuyết phục quản lý mọi thứ đều giống nhau kể từ khi bắt đầu: chỉ cho họ cách nó sẽ tiết kiệm tiền cho họ.
Robert Harvey

9

Theo kinh nghiệm (hơi hoài nghi) của tôi, đã từng làm việc cho một cửa hàng nơi chúng tôi đã sử dụng lập trình chức năng và phỏng vấn tại một số người khác:

  1. Luôn có một CTO và những người kỹ thuật cấp cao khác có kinh nghiệm về lập trình chức năng và đã thuyết phục được các giám đốc phi kỹ thuật của nó. (Và thật tình cờ, những người này có trình độ tốt hơn để trả lời câu hỏi của bạn hơn tôi.)
  2. Một khi những người này rời khỏi công ty và được thay thế bởi những người không có thiên hướng này, mọi thứ sẽ đi về phía nam. Những kẻ mới sẽ đổ lỗi cho tất cả những gì sai (bao gồm, và đặc biệt là những thất bại của chính họ) về ngôn ngữ lập trình kỳ lạ và mô hình được sử dụng để xây dựng những gì trước đây. Họ sẽ gạt ra khỏi những người còn lại với các kỹ năng lập trình chức năng, đẩy họ ra khỏi công ty. Hệ thống được xây dựng trên ngôn ngữ chức năng sẽ xuống cấp không rõ ràng. Theo tôi, đây là rủi ro lớn nhất mà doanh nghiệp gặp phải nếu áp dụng ngôn ngữ chức năng và không được đánh giá thấp.
  3. Tổ chức phải có văn hóa "xây dựng thay vì mua" để làm việc này. Bởi vì việc áp dụng một ngôn ngữ chức năng sẽ có nghĩa là ít lựa chọn "mua" hơn.
  4. Hầu như luôn luôn có một số thỏa hiệp với những kẻ gièm pha kỹ thuật và phi kỹ thuật của ý tưởng. Điểm chung nhất của những thỏa hiệp này là mọi ngôn ngữ không phải JVM đều không được xem xét; Clojure và Scala đã được đề xuất, Haskell và O'Caml vừa ra khỏi con dơi.

4

Những điều cần xem xét đối với quản lý cấp trên khi / nếu quản lý cấp trên có liên quan đến việc chọn ngôn ngữ lập trình (là số lẻ, họ nên để nó cho những người đáng tin cậy, hiểu biết (cả về công nghệ và hiểu biết về kinh doanh):

  • Năng suất
    • Cả nhân viên hiện tại và tương lai
    • Tất cả các vai trò (kiến trúc sư, nhà phát triển, người thử nghiệm, OP, ...)
  • Nền tảng được hỗ trợ
    • Hệ điều hành, (phần cứng?)
  • Nhà xuất bản ngôn ngữ / nền tảng
    • Giấy phép
  • Sự trưởng thành của ngôn ngữ / nền tảng
    • Hỗ trợ / của nhà xuất bản và / hoặc cộng đồng
    • Thư viện
  • Di chuyển cơ sở mã hiện tại
    • Hoặc tích hợp với

Lưu ý rằng đây không phải là cụ thể cho các ngôn ngữ lập trình chức năng. Đây cũng không phải là đối số trừ khi bạn cung cấp dữ liệu với những điều này. Chúng tôi không thể cung cấp cho bạn dữ liệu vì chúng hoàn toàn phụ thuộc vào môi trường kinh doanh của bạn. Điều duy nhất chúng ta có thể làm là thu thập dữ liệu từ web để hiển thị lượng kiến ​​thức và sự quan tâm dành cho một ngôn ngữ cụ thể. Hãy cẩn thận khi dịch nhiều câu hỏi trên StackOverflow hoặc nhiều thẻ trên Linkedin sang một ngôn ngữ đang trở nên phổ biến.


1
Các doanh nghiệp cũng quan tâm đến việc thuê người, vì vậy nếu khó thay thế một nhà phát triển chức năng, tôi muốn nói rằng đó là lý do chính đáng để họ tham gia vào các quyết định đó.
Andy

1
@Andy - Vâng, đó là lý do tại sao tôi không bác bỏ câu hỏi và tôi nghĩ rằng các nhà quản lý nên quan tâm đến các chủ đề tôi đã nêu. Lo lắng của tôi ít nhiều là giải pháp (Ngôn ngữ lập trình hàm) được chọn TRƯỚC KHI vấn đề (???) được xác định.
Erno

Có thực sự khó để thay thế một nhà phát triển chức năng? Theo số lượng các nhà phát triển được thông báo đăng ở đây và trên các trang web khác trên Internet, tôi nghi ngờ rằng có nhiều nhà phát triển chức năng hơn nhiều so với các nhà quản lý nghĩ.
Giorgio

@Giorgio - Tôi chưa bao giờ nói rằng thật khó để thay thế chúng nhưng tôi trải nghiệm tính khả dụng của tôi có thể khác nhau từ vị trí này đến vị trí khác. Một số sinh viên tốt nghiệp đại học thậm chí không bao giờ học những điều cơ bản trong khi một số trường đại học chuyên về chúng. Đối với một doanh nghiệp, điều rất quan trọng là nhìn vào dài hạn và nhu cầu dự kiến ​​của các nhân viên mới.
Erno

@Erno: Tôi đồng ý với quan điểm của bạn. Tôi đã bình luận về bình luận của Andy. Dù sao, tôi luôn cho rằng có rất ít lập trình viên chức năng và rằng FP được xem như một cái gì đó bí truyền. Gần đây, ấn tượng của tôi là có nhiều nhà phát triển FP hơn các công việc FP.
Giorgio

3

Tôi không nghĩ rằng tranh luận hoặc sự kiện sẽ giúp. Và chắc chắn không phải không có những vấn đề bạn muốn giải quyết.

Chống lại niềm tin phổ biến và tự đánh giá điển hình, nhiều quyết định được đưa ra dựa trên cảm giác ruột thịt. Và thường thì những quyết định này là những quyết định rất tốt, bởi vì chúng kết hợp ở cấp độ tiềm thức rất nhiều kinh nghiệm của cá nhân đưa ra quyết định.

Nếu bạn muốn thách thức một quyết định như "Chúng tôi sẽ gắn bó với ngôn ngữ C cho đến khi kết thúc tất cả các máy tính", bạn phải làm nhiều hơn là chỉ cung cấp một số đối số.

Bước đầu tiên có lẽ là phát hiện ra những người và lý do đằng sau quyết định rằng quản lý cấp cao nên có tiếng nói trong các quyết định kỹ thuật như vậy. Tất nhiên tôi chỉ có thể đoán ở đây, nhưng rất có thể họ có một hồ sơ theo dõi các quyết định được thực hiện bởi cá nhân kỹ thuật trở nên tồi tệ. Hãy đối mặt với nó: Hầu hết các nhà phát triển không giỏi trong việc đưa ra các quyết định (thậm chí kỹ thuật) ở cấp độ công ty.

Một khi bạn tìm thấy những người này nói chuyện với họ để có được sự tin tưởng. Có thể cách tiếp cận tốt nhất là: lắng nghe họ. Họ quan tâm đến điều gì, rủi ro và cơ hội họ nhìn thấy là gì. Vấn đề họ đang gặp phải là gì. Từ đây bạn có thể di chuyển để đưa những người công nghệ tham gia vào loại quyết định này. Quản lý thường không thực sự muốn đưa ra các quyết định này, nhưng không tin tưởng người khác với nó. Vì vậy, nếu nhóm của bạn bắt đầu tham gia vào quyết định kiến ​​trúc và chứng minh rằng các quyết định bạn đề xuất là quản lý hợp lý có thể sẵn sàng tin tưởng bạn / nhóm của bạn.

Quan trọng để đưa ra các quyết định kiến ​​trúc hợp lý là:

  • Thu thập đầu vào từ những người nắm giữ cổ phần (Quản lý, Người dùng, Quản trị viên, Bán hàng, Khách hàng ...)
  • Quyết định cơ bản về đầu vào đó
  • Truyền đạt rõ ràng: các quyết định (đề xuất) là gì; Rủi ro nào họ nhắm đến để giảm thiểu; Những lợi ích xung đột là gì và với một số chậm trễ: họ đã làm việc tốt như thế nào.

Nếu bạn làm việc cho một công ty lớn có nhân viên 10K +, hãy chuẩn bị để học một số bài học sau đây.

  • tốc độ mã hóa không thực sự phù hợp với dòng dưới cùng.
  • những thứ như khả năng duy trì trên quy mô của nhiều thập kỷ là.
  • những vấn đề bạn nghĩ bạn có thể giải quyết bằng ngôn ngữ chức năng không thực sự phù hợp với điểm mấu chốt
  • các vấn đề như đào tạo 1000 nhà phát triển, sức đề kháng tự nhiên để thay đổi và duy trì cơ sở mã được viết bởi các nhà phát triển có ít hơn 5 năm kinh nghiệm trong công nghệ được sử dụng.

Khi bạn đạt đến một mức độ tin cậy rằng các đối số của bạn được lắng nghe và xem xét, bạn cũng sẽ thiết lập một cách thu thập và xem xét các yêu cầu mà bạn, nhóm và quản lý của bạn tin tưởng.

Nếu quy trình này tạo ra khuyến nghị sử dụng phương pháp tiếp cận chức năng trong một số lĩnh vực nhất định bạn đã thực hiện.

Nếu quy trình này tạo ra khuyến nghị bỏ qua các phương pháp tiếp cận chức năng vượt xa những gì ngôn ngữ lập trình chính hiện tại cung cấp cho bạn thì bạn cũng đã hoàn thành.

Tin xấu là: Tùy thuộc vào quy mô và phong cách của công ty, việc này có thể dễ dàng mất một vài năm hoặc nhiều thập kỷ.

Tin tốt là: Bạn sẽ học được rất nhiều trên đường.

Vì bước đầu tiên là bắt đầu nói chuyện và đặc biệt là lắng nghe quản lý cấp cao, tôi khuyên bạn nên bắt đầu với việc đọc Chỉ cần lắng nghe .


3

Một cách tiếp cận tốt sẽ cho thấy rằng nó cho thấy kết quả tốt trong ngành và được thông qua.

Bạn có thể nhận được một số dữ liệu từ:

Tốt nhất, hãy cố gắng nói chuyện với các nhà quản lý tại một số công ty niêm yết, đặc biệt nếu trong ngành của bạn, và nhận được số và lời chứng thực từ họ.

Google có nhiều liên kết tương tự khác cho Haskell, OCaml, v.v.


3
Một số công ty sẽ coi đây là một trường hợp chống lại, vì những người hành nghề OO đông hơn các tín đồ của FP bởi một biên độ rộng .
Robert Harvey

1
@RobertHarvey - đó là một chút tranh luận cá trích đỏ, ít nhất là trong trường hợp cụ thể của tôi. Họ đã đủ thông minh để biết RATNG. Điều họ KHÔNG biết (và những gì tôi phát hiện ra từ câu trả lời này) là Eaton Vance sử dụng Scheme và quan trọng hơn là Faceboook , BoA / ML, Deutsche Bank và Google [sử dụng Haskell]. Có nghĩa, đó là điều mà họ CÓ THỂ xem xét nhúng ngón chân vào, vì những giá trị khác quyết định. Thật ngạc nhiên khi câu trả lời thực sự hữu ích duy nhất đã cố gắng giải quyết câu hỏi mà tôi đã hỏi (và không phải là câu hỏi mà mọi người cảm thấy muốn trả lời) là câu trả lời ít nhất
DVK

1
@dvk: Câu hỏi bạn đặt ra (nếu tôi hiểu chính xác) là "Làm thế nào để tôi thuyết phục sếp của mình rằng FP là một điều tốt?" Vâng, đôi khi không. Chúng ta đang sống trong một thế giới đột biến, và Lập trình chức năng, nói một cách khá trung thực, có một chút kỳ quặc. Nếu bạn không tin tôi, hãy xem các đơn nguyên. Câu trả lời giải quyết những điều kỳ quặc này (và cách chúng ảnh hưởng đến quá trình thiết kế và phát triển phần mềm) rất hữu ích, cho dù bạn có nghĩ rằng chúng có hay không.
Robert Harvey

@RobertHarvey (1) Tôi lấy lại. Bây giờ HAI câu trả lời hữu ích được bình chọn thấp nhất :) (câu trả lời mới vừa được đăng có thể được cải thiện với sự thật nhưng là một khởi đầu tốt).
DVK

@RobertHarvey - vâng. Câu hỏi KHÔNG phải là "FP có phải là điều tốt" hay "Có thể thuyết phục mọi người FP là điều tốt không". Câu hỏi rất chính xác "Những lý lẽ nào có thể được sử dụng để hỗ trợ KHI cố gắng thuyết phục đó là một điều tốt". Đó không phải là "Làm thế nào tôi có thể lén lút giới thiệu FP vào công việc / mã hóa của mình theo cách tích cực", đó là những gì bạn đã trả lời - nếu đó là một lựa chọn tôi sẽ không hỏi ngay từ đầu, tôi sẽ viết mã: )
DVK

2

Bạn đang đến đây từ hướng sai.

Bạn đang cố gắng thuyết phục ban quản lý chuyển sang mô hình chức năng cho mục đích giải trí của riêng bạn và bạn đang cố gắng đưa ra những lý lẽ để hỗ trợ điều này không liên quan gì đến lý do thực sự tại sao bạn muốn nó. Nếu không, bạn sẽ không cần phải đặt câu hỏi, vì bạn có thể liệt kê các đối số của bạn từ đỉnh đầu của bạn.

Thay vào đó, những gì bạn nên suy nghĩ là những gì doanh nghiệp hiện tại cần là gì và làm thế nào nó được phục vụ tốt nhất. Nếu nó xảy ra rằng nó được phục vụ tốt nhất bằng cách sử dụng một mô hình chức năng thì - yay! - bạn được chơi Nhưng nếu bạn phân tích công bằng, có tính đến nhu cầu kinh doanh vận hành, đào tạo đồng nghiệp cần thiết, nền tảng của các lập trình viên tương lai, bảo trì, v.v., thường thì sẽ không như vậy.


2
Đây là một câu chuyện phiếm, và không quá hữu ích trong việc trả lời câu hỏi, cần được trừu tượng hóa khỏi việc chỉ giúp OP thực hiện "phương pháp" của mình.
VF1

1

Quản lý cấp cao không có kỹ năng kỹ thuật không nên quan tâm đến các khía cạnh kỹ thuật như việc sử dụng các mô hình chức năng. Đây không phải là lĩnh vực chuyên môn của họ, và có mùi quản lý vi mô. Tại sao họ không ủy thác những quyết định đó cho những người thực sự có kỹ năng cần thiết?

Điều này đang được nói, đây là một số gợi ý để thuyết phục những người có nền tảng kỹ thuật (trường hợp đầu tiên) và những người không có (trường hợp thứ hai).

Trường hợp đầu tiên

Nếu bạn đang nói chuyện với những người biết lập trình , so sánh mã được viết mà không có mô hình lập trình chức năng và cùng mã được viết theo kiểu chức năng có thể đủ thuyết phục:

Mã C # mẫu sử dụng kiểu bắt buộc:

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
{
    if (product.IsEnabled)
    {
        if (!categorizedProducts.ContainsKey(product.Category))
        {
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());
        }

        categorizedProducts[product.Category].Add(product);
    }
}

// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
{
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
    {
        if (product.Price < minimumPrice)
        {
            minimumPrice = product.Price;
        }

        if (product.Price > maximumPrice)
        {
            maximumPrice = product.Price;
        }
    }

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);
}

Cùng mã được viết lại với lập trình chức năng trong tâm trí:

return this.Data.Products
    .Where(product => product.IsEnabled)
    .GroupBy(product => product.Category)
    .Select(productsInCategory => new PricesPerCategory(
              category: productsInCategory.Key, 
              minimum:  productsInCategory.Value.Min(product => product.Price), 
              maximum:  productsInCategory.Value.Max(product => product.Price))
    );

Sau đó hỏi họ:

  1. Một lập trình viên có thể mắc bao nhiêu lỗi trong mẫu đầu tiên? Còn cái thứ hai thì sao?

  2. Làm thế nào là khó khăn để phát hiện sai lầm?

  3. Làm thế nào là khó khăn để sửa đổi mã?

Tất cả ba yếu tố ảnh hưởng đến năng suất, và do đó chi phí của sản phẩm.

Trường hợp thứ hai

Nếu bạn đang làm việc với những người không biết lập trình, bạn không thể nói với họ nhiều thứ kỹ thuật. Một trong những cách để thuyết phục là cho thấy tác động thực tế của các mô hình chức năng đối với công việc của bạn và công việc của đồng nghiệp.

Ví dụ, so sánh hai dự án được thực hiện bởi cùng một nhóm, một dự án sử dụng FP, dự án khác không sử dụng. Cho thấy số lượng lỗi thấp hơn nhiều hoặc đây là dự án đầu tiên mà công ty thực sự giao đúng thời hạn nên đủ thuyết phục.


3
Tôi thấy những gì bạn đã làm ở đó, nhưng ví dụ của bạn không hoàn toàn thuyết phục. Về cơ bản, bạn đã không kiểm soát ví dụ chức năng của mình thành một ví dụ bắt buộc, đây không phải là điều sẽ xảy ra trong bất kỳ mối quan tâm thực tế nào của công ty. Bạn yield returnlà một người gian lận, đó là một ví dụ về cách bạn sẽ chuẩn bị mã để được sử dụng trong kịch bản Linq và các ifcâu lệnh của bạn có thể được viết ngắn gọn hơn với các toán tử tạm thời. Tất cả các ví dụ đầu tiên của bạn có thể được tái cấu trúc thành các hàm bắt buộc, do đó độ phức tạp bị ẩn đi.
Robert Harvey

@RobertHarvey Bạn có thể cấu trúc lại ví dụ đầu tiên thành một loạt các hàm bắt buộc, nhưng chúng sẽ là các hàm mệnh lệnh tùy chỉnh dành riêng cho truy vấn đó; bạn vẫn phải xem tất cả để tự thuyết phục truy vấn là chính xác. Việc tái cấu trúc đó sẽ thổi kích thước của mã mệnh lệnh lên cao hơn nữa. Ngay cả khi bạn có thể viết nó thật gọn gàng, bạn vẫn phải đọc mã cẩn thận vì tất cả công việc đang được thực hiện thông qua các tác dụng phụ; bạn sẽ không muốn bỏ lỡ một hiệu ứng phụ được thực hiện trong phần thứ hai của một toán tử ternary ở cuối dòng.
Doval

1
@RobertHarvey Tôi thậm chí không chắc hai đoạn mã là tương đương nhau, vì "bộ lọc" bắt buộc bằng cách xây dựng một danh sách thứ hai thay vì chỉ bỏ qua lần lặp. Sẽ không tương đương thực sự chỉ sử dụng một vòng lặp và do đó thậm chí còn được lồng sâu hơn?
Doval

5
Không có câu hỏi nào về việc bạn tạo ra một trường hợp tốt để kết hợp các khái niệm chức năng trong ngôn ngữ OO / mệnh lệnh khác, nhưng không nhất thiết là một trường hợp tốt để sử dụng các ngôn ngữ chức năng hoàn toàn trong môi trường doanh nghiệp vốn đã bắt buộc / OO.
Robert Harvey

Một vấn đề khác (có lẽ ít hợp lệ hơn) với ví dụ của bạn: Tôi có thể viết ví dụ đầu tiên bằng Perl hoàn toàn có thể đọc được - Tôi đoán - 30% âm lượng. Có lẽ ít hơn. Phụ thuộc vào việc bạn chấp nhận map/ grepkhông phải là FP. IOW, bạn đang trình bày các lập luận rằng Java là một ngôn ngữ xấu, không phải FP là một cách tiếp cận tốt.
DVK
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.