สามารถใช้ฟังก์ชั่นแลมบ์ดา \ ในซอฟต์แวร์ทางธุรกิจได้หรือไม่?

ฉันสังเกตเห็นโพสต์ที่นี่ซึ่งแสดงให้เห็นถึงการใช้ฟังก์ชั่นของผู้ได้รับมอบหมาย \ lambda เพื่อแก้ไขช่องโหว่ในความคิดตรงกลางโดยไม่มีการซ้ำซ้อนจำนวนมาก: http://www.markhneedham.com/blog/2009/04/04/functional-c -The หลุม-in-the-กลางรูปแบบ /

ปัญหาน่าจะเป็นที่นักพัฒนารุ่นน้องและคนอื่น ๆ ไม่จำเป็นต้องเข้าใจว่าแนวคิดฟังก์ชั่นตัวชี้ \ มอบหมาย \ lambda คืออะไรซึ่งดูเหมือนว่าจะทำให้การอ่าน (และอาจแก้จุดบกพร่อง) รหัสยากขึ้น

เราควรหลีกเลี่ยงหรือ จำกัด การใช้เครื่องมือนี้อย่างรุนแรงในการเขียนซอฟต์แวร์ธุรกิจโดยเฉพาะในทีมงานขนาดเล็กหรือร้านค้าผู้พัฒนาเพียงผู้เดียวหรือไม่?

หรือเป็นที่ยอมรับที่จะใช้กับความคิดเห็นที่เหมาะสมและคาดหวังว่าเมื่อฉันไม่อยู่ต่อที่นักพัฒนาต่อไปจะเข้าใจหรือเรียนรู้เกี่ยวกับฟังก์ชั่นแลมบ์ดา?

ปัญหาน่าจะเป็นที่นักพัฒนารุ่นน้องและคนอื่น ๆ ไม่จำเป็นต้องเข้าใจว่าแนวคิดฟังก์ชั่นตัวชี้ \ มอบหมาย \ lambda คืออะไร

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

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

ผู้พัฒนาควรทราบวิธีการใช้ภาษาที่พวกเขาอยู่ในจูเนียร์หรือไม่ หากพวกเขาไม่ทำเช่นนั้นให้ไล่พวกเขาออกและหาคนที่ทำหรือฝึกให้พวกเขาทำ

ใช่ใช้พวกเขา

ฉันเป็นนักพัฒนารุ่นน้องและฉันรู้ / เข้าใจ lambdas (และแนวคิดอื่น ๆ ที่คุณพูดถึง) ไม่มีอะไรที่ฉันจะมองข้ามการป้องกันไม่ให้ผู้พัฒนารุ่นเยาว์จากการเรียนรู้แนวคิดเหล่านั้นทั้งหมดในเวลาสั้น ๆ รุ่นน้องอาจมีประสบการณ์ / ความเชี่ยวชาญไม่เท่ากันเมื่อพูดถึงการพัฒนาซอฟต์แวร์จำนวนมากอย่างไรก็ตามแนวคิดเช่น lambdas สามารถเข้าใจได้ง่ายโดยทุกคนที่มีความเข้าใจพื้นฐานของการเขียนโปรแกรมและการเชื่อมต่ออินเทอร์เน็ต นอกจากนี้ดูเหมือนว่าคุณเลือก lambdas เป็นตัวอย่างเมื่อพิจารณาว่าคุณใช้ C # ดูเหมือนว่าคุณไม่ได้เริ่มต้นเรียนรู้ lambdas มากกว่านักพัฒนารุ่นใหม่ (พวกเขาเพิ่งเปิดตัวในปี 2008 ถ้าฉัน จำได้ถูกต้อง)

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

หากพวกเขาแก้ปัญหาที่เหมาะสมกับปัญหาของคุณแล้วคุณควรใช้พวกเขา

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

หากรหัสถูกเขียนอย่างดีพร้อมความคิดเห็นที่เหมาะสมดังนั้นผู้ที่ติดตามควรจะสามารถเรียนรู้จากคุณได้

วางลิงก์ไปยังเอกสารคู่มือ msdn ในความคิดเห็นที่ด้านบนของบล็อกที่ใช้งานแล้วไปข้างหน้า คุณไม่ควรกลัวที่จะใช้เทคโนโลยีใหม่ / ซับซ้อนซึ่งเป็นส่วนหนึ่งของงานนักพัฒนาเพื่อเรียนรู้สิ่งที่พวกเขาไม่รู้

ปัญหาน่าจะเป็นที่นักพัฒนารุ่นน้องและคนอื่น ๆ ไม่จำเป็นต้องเข้าใจว่าแนวคิดฟังก์ชั่นตัวชี้ \ มอบหมาย \ lambda คืออะไร

จากนั้นพวกเขาจำเป็นต้องเรียนรู้พวกเขา ระยะเวลา

1. นี่ไม่ใช่มุมลึกลับของ C # คุณต้องเข้าใจพวกเขาเพื่อใช้ประโยชน์จากห้องสมุด. Net มากมาย
2. นี่ไม่ใช่หัวข้อภาษาลึกลับโดยทั่วไป แทบทุกภาษาในการใช้งานที่เป็นที่นิยมในปัจจุบันมีตัวชี้ฟังก์ชั่นบางส่วนและส่วนใหญ่จะมีการปิด (หรือกำลังจะได้รับเร็ว ๆ นี้ในกรณีของ Java และ C ++)

ใช้เวลาสักครู่เพื่ออธิบายให้พวกเขาฟัง มันไม่ยาก

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

ฟังก์ชั่นตัวชี้ \ มอบหมาย \ แนวคิดแลมบ์ดาฟังก์ชั่น

ควรสังเกตว่าสิ่งเหล่านี้เป็นสามสิ่งที่แตกต่างกัน

สองสถานการณ์ที่เป็นไปได้:

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

b) เพื่อนร่วมงานของคุณ (หรือส่วนใหญ่) จะไร้ความสามารถ ไม่มีวิธีใดที่พวกเขาจะเข้าใจ lambdas, closures, pointers function หรือแนวคิด meta-coding อื่น ๆ ที่คล้ายกันอย่างสมบูรณ์ พวกเขาอาจกำลังพยายามเข้าใจพอยน์เตอร์การอ้างอิงและการเรียกซ้ำ ในสถานการณ์เช่นนี้สิ่งที่ดีที่สุดที่คุณทำได้คือกัดกระสุนใช้วิธีแก้ปัญหาที่เงอะงะ verbose ปราศจากแลมบ์ดาและแปรงถ่านของคุณเพราะคุณควรหางานทำ

นี่คือสิ่งที่ความสอดคล้องสามารถช่วยได้มาก หากคุณใช้มันอย่างสม่ำเสมอด้วยสไตล์เดียวกัน ฯลฯ ผู้อ่านจะต้องเรียนรู้เพียงครั้งเดียวและจากนั้นพวกเขาจะจดจำมันได้ทุกที่

อย่างน้อยก็ในตอนแรกอาจช่วยได้อย่างชัดเจน ตัวอย่างเช่นทั้งสองนี้เทียบเท่า:

doSomething(() => someMethod());

doSomething(someMethod);

private void doSomething(Action someAction) { ... }
private void someMethod() { ... }

... แต่ในกรณีแรกมันชัดเจนถ้าคุณรู้ไวยากรณ์แลมบ์ดาสิ่งที่เรากำลังทำอยู่ แม้ว่าคุณจะไม่รู้จักไวยากรณ์แลมบ์ดา แต่ก็เห็นได้ชัดว่าคุณเห็นสิ่งใหม่และคุณต้องค้นหามัน ในกรณีที่สองมันดูเหมือนว่าคุณกำลังผ่านตัวแปร

ฉันรู้ว่า ReSharper ผลักดันให้คุณเปลี่ยนเป็นกรณีที่สอง แต่ฉันสงสัยว่ามันเป็นความคิดที่ดีเสมอ ในกรณีที่สองคุณต้องรู้ว่าจะใช้เวลาdoSomethingAction

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

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

itemsList.ForEach(item => DoAction(item));
...
public void DoAction(Item item) {
  //...do various things here...
}

ตอนนี้บางทีที่นี่เรากำลังเรียก DoAction เพราะร่างกายของมันยาวเกินกว่าจะพอดีกับแลมบ์ดาเอง ในกรณีนี้การใช้วิธีการขยาย ForEach () ในรายการไม่ได้ให้ประโยชน์กับเรามากกว่าการใช้ลูป foreach ปกติถึงแม้ว่ามันจะบันทึกรหัสสองบรรทัด แต่ฉันคิดว่า แต่ในกรณีพิเศษนี้การใช้ ForEach () อาจทำให้เราหลงไหลในการทำสิ่งที่ใช้รหัสจริงมากขึ้น อาร์กิวเมนต์ที่ผ่านมานั้นไม่จำเป็นต้องเป็นแลมบ์ดาเลย

คุณควรเรียก DoAction แบบนี้:

itemsList.ForEach(DoAction);

ไม่มีแลมบ์ดาเลย กุญแจสำคัญคือการจำสิ่งที่คุณกำลังผ่านเมื่อคุณสร้างแลมบ์ดานิพจน์: ทางลัดบางอย่างเพื่อกำหนดอินสแตนซ์ของผู้ร่วมประชุม ใช่มันมีประโยชน์เช่นการปิด แต่ไม่ควรสูญเสียเว็บไซต์ของสิ่งที่คาดว่าจะเรียกวิธีการ ในกรณีนี้คาดว่าที่อยู่จะเป็นวิธีการที่ตรงกับลายเซ็นของการกระทำ DoAction เป็นวิธีการดังกล่าวอยู่แล้วดังนั้นการสร้างแลมบ์ดานั้นเป็นการเพิ่มวิธีการเรียกเมธอดที่ไม่จำเป็นออกไปโดยสิ้นเชิง

IMHO การเขียนในระดับเทคนิคใด ๆ ที่สูงกว่าระดับเทคนิคของทีมนั้นผิด หากสมาชิกในทีมของคุณไม่พอใจกับการแสดงออกแลมบ์ดาและฟังก์ชั่นและพวกเขาไม่มีเวลาที่จะเรียนรู้มัน (พวกเขาควรใช้เวลากับฐานข้อมูลการปรับแต่งประสิทธิภาพใช้งาน UI ได้มากขึ้นสร้างองค์ประกอบ ฯลฯ ) ขอแนะนำให้ไม่ใช้พวกเขา อย่างไรก็ตามหากพวกเขายินดีที่จะเรียนรู้และมีเวลาว่างหรือพวกเขารู้ความรู้อยู่แล้วทำไมไม่

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