วิธีแนะนำทีมของคุณให้รู้จักรูปแบบการทำงานของการเข้ารหัส

ฉันมีสถานการณ์ที่คนส่วนใหญ่ในกลุ่มของฉันมาจากพื้นหลังการเขียนโปรแกรมเชิงวัตถุโดยไม่มีความเข้าใจเกี่ยวกับการเขียนโปรแกรมการทำงาน พื้นฐานไม่เหมือนการปิด

ข้อเสนอแนะใด ๆ เกี่ยวกับสิ่งที่อาจเป็นวิธีที่ดีในการแนะนำพวกเขาเกี่ยวกับรูปแบบการเข้ารหัสการทำงาน? การเขียนโค้ดจำนวนมากที่เราทำได้นั้นสามารถย่อให้สั้นลงได้ถ้าเราทำตามหน้าที่การใช้งานสำหรับกรณีเฉพาะของเรา

ฉันได้รับการนำเสนอสองสามรายการเกี่ยวกับกระบวนทัศน์การทำงานและการเข้ารหัสแล้ว น่าเสียดายที่เราไม่ได้ใช้ภาษาการเขียนโปรแกรมที่เหมาะสมเช่น Haskell (โดยทั่วไปคือรหัสดั้งเดิมคือ C, C ++, Java) ดังนั้นเราต้องทำทุกอย่างที่มีอยู่กับสิ่งเหล่านี้

Luca Bolognese ทำการนำเสนอที่ยอดเยี่ยมนี้ซึ่งเขาแนะนำการเขียนโปรแกรมเชิงฟังก์ชั่น (เพื่อนำเสนอ F #) โดยใช้ตัวอย่างกาแฟซึ่งยอดเยี่ยมมากและช่วยฉันมากมายในการแนะนำการเขียนโปรแกรมเชิงหน้าที่ให้กับเพื่อนและเพื่อนร่วมงาน

คุณยังสามารถดูการเขียนโปรแกรมฟังก์ชั่น Real Worldโดย Petricek ซึ่งเป็นวิธีที่ยอดเยี่ยมในการเริ่มคิดในเชิงความคิดของฉัน

รหัสเพื่อนร่วมงานของคุณนอกเวลาทำงานหรือไม่?

พิจารณาว่าคุณไม่ได้ทำ FP ใด ๆ ที่ บริษัท ของคุณจากนั้นให้ทุกคนเรียนรู้ภาษา / กระบวนทัศน์ใหม่เมื่อพวกเขาไม่ทำอะไรนอกงานโดยตรงของพวกเขาจะเป็นไปไม่ได้

หากพวกเขาทำแล้วหาโครงการที่น่าสนใจที่พวกเขาต้องการที่เกี่ยวข้องกับการเขียนโปรแกรมการทำงานและแสดงให้พวกเขา คุณไม่ได้อยู่ในฐานะที่จะเปลี่ยนแปลงการควบคุมดังนั้นคุณจะต้องหว่านเมล็ดหากสนใจในระดับส่วนบุคคล นี่คือวิธีที่ฉันได้รับการแนะนำให้รู้จัก - โดยเพื่อนสนิทของฉันที่ทำงานกับฉัน

นอกเหนือจากนั้นคนส่วนใหญ่เขียนเครื่องมือภายในองค์กรเพื่อให้งานเล็กง่ายขึ้น ลองเขียนบางส่วนเป็นภาษาที่ใช้งานได้ ทุกคนที่ต้องการเห็นรหัสจะได้รับความสวยงาม (หวังว่า / อาจเป็นไปได้) ของรหัสและมีแนวโน้มที่จะถามคุณเกี่ยวกับมันเมื่อพวกเขาทำ นั่นคือโอกาสในการขายความคิด

จำไว้ว่ามีภาษาที่ใช้งานได้ซึ่งจะทำงานกับสแต็กของคุณ (สกาล่า / ปิดทั้งสองทำงานบน JVM) มันไม่ใช่ "ทำงานได้อย่างหมดจด" เหมือน Haskell แต่มันเป็นการเริ่มต้นที่ดีในการเดินทางไกล

หากคุณมีอำนาจควบคุมการว่าจ้างคนที่มีประสบการณ์การทำงาน (หรืออย่างน้อยก็มีความสนใจในการเขียนโปรแกรมการทำงาน)

และในที่สุด ... คุณอาจผิด บริษัท ถ้าคุณหลงใหลในการเขียนโค้ดฟังก์ชั่น คุณจะไม่เปลี่ยนวิธีที่ บริษัท ของคุณเขียนซอฟต์แวร์โดยเฉพาะอย่างยิ่งหากพวกเขาทำเงินและยิ่งกว่านั้นโดยเฉพาะในเวลาอันสั้น

นี่คือทั้งหมดที่เกี่ยวกับการขายให้กับ devs ... การจัดการเป็นสัตว์ร้ายอื่น ๆ ทั้งหมด

การเปลี่ยนจากความจำเป็นไปสู่การเขียนโปรแกรมฟังก์ชั่นที่บริสุทธิ์คือการเปลี่ยนแปลงครั้งใหญ่กับช่วงการเรียนรู้ที่สูงชัน ฉันขอแนะนำให้ลองเปลี่ยนผ่านอย่างรวดเร็วน้อยกว่าและในกรณีนี้คุณมีตัวเลือกมากมาย ยกตัวอย่างเช่นงูหลามสนับสนุนcomprehensions รายการและการแสดงออกกำเนิดทับทิมรองรับฟังก์ชั่นขั้นสูงผ่านบล็อกรหัส ฯลฯ ตั้งแต่ที่คุณกล่าวถึง Java, ถ้าทั้งหมดของคุณมีพื้นหลัง Java และคุณต้องการการสนับสนุนอย่างเต็มที่โปรแกรมการทำงานคุณสามารถลองสกาล่า

จ้าง (หรือรับหัวหน้าเพื่อว่าจ้าง) โปรแกรมเมอร์ที่ทำงานได้

ในที่สุดสิ่งนี้กำลังจะถูลงไปในส่วนที่เหลือของทีมของคุณ

นอกจากนี้ตามที่ระบุไว้ก่อนหน้านี้การส่งเสริมให้พวกเขาเขียนโค้ดในภาษาที่ใช้งานได้ในระหว่างการทำงานนอกเวลางานของพวกเขาจะไม่กระทบกระเทือนเช่นกัน

หากการโปรแกรมเชิงฟังก์ชันจะทำให้ชีวิตของคุณง่ายขึ้นมากขึ้นในกรณีของคุณฉันขอแนะนำให้แยกกรณีดังกล่าวหนึ่งกรณีและแสดงให้เห็นถึงการใช้งานที่เท่าเทียมกันทั้งใน OO และภาษาที่ใช้งานได้กับเพื่อนร่วมงานของคุณ

หากความแตกต่างในความซับซ้อนมีความกว้างเท่ากับที่คุณพูดคุณควรพูดเพื่อตัวเอง

+1 ถึง faif สำหรับการกล่าวถึง Scala: สิ่งนี้เริ่มต้นเป็นความคิดเห็นในคำตอบนั้น แต่ใหญ่เกินไป ...

ฉันต้องการเรียนรู้บางอย่างเกี่ยวกับการเขียนโปรแกรมใช้งาน (มาจาก C / C ++, Python & rusty Java); ฉันลองดำน้ำลึกที่สุดด้วย Ocaml จากนั้น Haskell และ Just Don't Get It จากนั้นฉันลอง Scala และพบว่าให้ฉันเริ่มใช้สิ่งที่ใช้งานได้ในสภาพแวดล้อมที่สะดวกสบาย OOP / Java-ey ที่ฉันสามารถย้อนกลับไปสู่รูปแบบความจำเป็นที่คุ้นเคยได้อย่างง่ายดายเมื่อวิธีการทำงานทำให้ฉันหลงไหล บางคนอาจบ่นว่า "multiparadigm", "hybrid" ของภาษาหมายความว่าคุณไม่เคยถูกบังคับให้ต้องไปทำงานที่บริสุทธิ์ แต่ฉันบอกว่ามันหมายความว่าคุณสามารถใช้ประโยชน์ได้ในสิ่งต่าง ๆ และรู้ว่าคุณจะรู้ สามารถทำสิ่งต่าง ๆ ได้อย่างง่ายดายเมื่อคุณต้องการ

สองสามปีที่ผ่านมา (และโซลูชัน Project Euler Scala กว่า 200 แห่งใน Scala ในภายหลัง) การเผชิญหน้ากับการใช้งานนั้นมีอิทธิพลต่อ Python ของฉันอย่างแน่นอน (การใช้แผนที่ตัวกรองลด lambdas, itertools, list comprehensions และฟังก์ชั่นการส่งผ่านรอบ ๆ เคยไตร่ตรองมาก่อน) และในระดับที่น้อยกว่า C ++: อาจจะพยายามใช้อุปกรณ์เสริมของ STL อีกเล็กน้อย แต่ผลกระทบหลักคือฉันรู้สึกสะดวกสบายมากขึ้นเมื่อใช้แผนที่ / ลดโครงสร้างของ TBB และชอบการใช้ประโยชน์ที่ไม่สามารถเปลี่ยนแปลงได้ ในรหัสแบบมัลติเธรด

โดยส่วนตัวถ้าฉันเป็นคุณฉันจะทำเรื่องแนะนำ Scala ในการพัฒนา Java-world ของคุณโดยเฉพาะอย่างยิ่งโดยการแสดงตัวอย่างของมันง่ายขึ้นอย่างมากและผลิตประโยชน์ที่คุณเรียกร้อง สิ่งที่เกิดขึ้นต่อไปคือธุรกิจทั้งหมดของ "ความคิดใหม่" และความคิดใหม่ที่ขับเคลื่อนการเปลี่ยนแปลง ... ซึ่งดูเหมือนว่ามันอาจเป็นปัญหาที่ใหญ่กว่ามาก

ฉันอยากจะแนะนำวิธีการแบบค่อยเป็นค่อยไปโดยใช้ Scala และฉันจะแนะนำให้เริ่มต้นด้วยการอ่านหนังสือของผู้สร้างสกาล่าของ"การเขียนโปรแกรมใน Scala ฉบับที่ 2" หนังสือเล่มนี้เป็นหนังสือที่ยอดเยี่ยมอย่างช้า ๆ แนะนำหนึ่งถึง (FP) การเขียนโปรแกรมการทำงานโดยใช้ Scala และในการแสดงการย้ายไปสู่ ​​FP มันไม่ได้ปฏิเสธ OO ในความเป็นจริงมันใช้ประโยชน์จากมัน ตอนนี้ฉันกำลังผ่านครั้งที่สอง

โดยทั่วไป Scala อนุญาตให้หนึ่งทำ Java / OO "ไม่มีเครื่องหมายอัฒภาค" และจากนั้นหนึ่งสามารถลอง FP เล็กน้อยโดยไม่ต้องไปทั้งหมู ตัวอย่างเช่นในการฝึกตัวเองให้ทำ FP ฉันมักจะเน้นไปที่ความโปร่งใสในการอ้างอิงระดับวิธีการเรียน แต่ให้วิธีการของฉันมีหลาย var-s, ความไม่แน่นอนและความจำเป็นตามที่จำเป็นสำหรับฉันที่จะผ่านครั้งแรกที่ การดำเนินการ จากนั้นฉันมุ่งเน้นที่การทำซ้ำแต่ละวิธีอย่างช้าๆเพื่อย้ายไปยัง FP บริสุทธิ์ และฉันยังใช้ไซต์น้องเพื่อ StackOverflow, CodeReview เพื่อรับความช่วยเหลือเกี่ยวกับการเปลี่ยนแปลงทางจิตใจ / ความคิดของฉัน นี่เป็นตัวอย่างของโพสต์ล่าสุดที่ฉันทำสิ่งนี้

อย่างไรก็ตามโชคดีที่สุดในการเดินทาง FP ของคุณ :)