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

มีตันของการขัดแย้ง "ทฤษฎี" ทำไมเขียนโปรแกรมการทำงานเป็นความคิดที่ดี (มากเกินไปเพื่อที่จะได้อยู่ในฐานะที่เป็นคำถามเปิดและถูกต้องเพื่อ)

อย่างไรก็ตามส่วนใหญ่ของพวกเขาเป็นข้อโต้แย้งที่ทำจากทฤษฎี ("ความสง่างาม" ฯลฯ ... ) หรือมุ่งเป้าไปที่นักพัฒนา

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

มีข้อโต้แย้งที่น่าสนใจที่จะนำเสนอเพื่อแก้ไขข้อกังวลทางธุรกิจเหล่านั้นเท่าที่จะพิจารณาการยอมรับการเขียนโปรแกรมฟังก์ชั่นเป็นแนวคิด (ไม่ใช่ภาษาใด ๆ ที่เฉพาะเจาะจง) กับการผสมผสานทั่วไปของขั้นตอน / OOP เช่น Java / C ++ / (Perl | Python) .

โดยเฉพาะอย่างยิ่งฉันกำลังมองหาข้อโต้แย้งที่มีปริมาณและ / หรืออยู่บนพื้นฐานของการวิจัยหรือกรณีศึกษา เช่น "จากการอ้างอิงนี้อัตราข้อผิดพลาดของระบบมัลติเธรดใน Lisp / F # คือ 10% ของ Java" หรือ "80% ของผู้สำเร็จการศึกษาชั้นนำที่แสดงความพึงพอใจของเทคโนโลยีที่ต้องการตั้งชื่อฟังก์ชั่นการทำงาน

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

_{psI ฉันรู้ดีว่าคุณสามารถทำอะไรบางอย่างใกล้เคียงกับการเขียนโปรแกรมการทำงานใน Perl, Python และ (อาจจะ) แม้แต่ Java 8 หรือ C ++ 14 แต่นั่นไม่ได้หมายความว่าองค์กรที่ใช้ Perl, C ++ หรือ Java จะรับรองการทำงานของ vs OOP / ขั้นตอนวิธีการแม้ในภาษาเหล่านั้น}

_{สำหรับวัตถุประสงค์ของภาษานี้ "ใหญ่" ถูกกำหนดให้มีขนาดใหญ่พอที่จะมีกลุ่มวิศวกรรม / เครื่องมือเฉพาะด้านการพัฒนาซึ่งกำหนดสิ่งที่นักพัฒนาทั้งหมดได้รับอนุญาตให้ใช้ / ทำ} และอย่างน้อยที่ร้อยของนักพัฒนาในปลายต่ำ

มีข้อโต้แย้งง่าย ๆ อย่างหนึ่งซึ่งอย่างน้อยอาจทำให้ฝ่ายบริหารสนุก

เป็นที่ทราบกันดีว่าคอมพิวเตอร์สมัยใหม่ไม่ได้กลายเป็น "เร็วขึ้น" อย่างที่เคยเป็นเพราะตอนนี้การปรับความถี่ทำได้ถึงขีด จำกัด แล้ว พวกเขาเพิ่มผลผลิตที่มีศักยภาพของพวกเขาโดยการเพิ่มแกน

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

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

ดังนั้นหากความท้าทายคือการเขียนโปรแกรมที่มีประสิทธิภาพมากขึ้นในวิธีที่มีประสิทธิภาพมากขึ้นเราสามารถเปรียบเทียบค่าใช้จ่ายในการฝึกอบรมคนที่จะเขียนโปรแกรมแบบขนานกับค่าใช้จ่ายในการฝึกอบรมคนเพื่อเรียนรู้การเขียนโปรแกรมการทำงาน

เกี่ยวกับภาษาผสม (ซึ่งสนับสนุนรูปแบบการเขียนโปรแกรมทั้งการใช้งานและที่จำเป็น): จากจุดหนึ่งพวกเขาอาจจะมีประโยชน์สำหรับการเปลี่ยนแปลง (ผู้คนอาจเริ่มใช้พวกเขาในแบบ "คุ้นเคย" และค่อยๆเรียนรู้วิธีการใหม่ ๆ ) จากจุดอื่นนี่อาจเป็นพรที่ปลอมตัวเพราะข้อดีที่เป็นไปได้ของการตั้งโปรแกรมการทำงานอาจถูกยกเลิกด้วยรหัสที่เงอะงะของใครบางคน หนึ่งสามารถลดสิ่งนี้ได้โดยการกำหนดแนวทางการเข้ารหัสที่ชัดเจน (ดูเช่น " Effective Scala " โดย Twitter) แม้ว่าการทำตามแนวทางจะต้องมีระดับวุฒิภาวะของทีม จากมุมมองนี้ภาษาที่ใช้งานได้จริงอาจ "ง่ายขึ้น" สำหรับการพัฒนาซอฟต์แวร์เนื่องจากกฎที่เข้มงวดที่พวกเขากำหนดโดยการออกแบบ

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

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

สรุปสาระสำคัญคือ: โน้มน้าวใจสมาชิกในทีมคนอื่นหรือผู้นำทีมของคุณ แต่ไม่ใช่การจัดการระดับสูง!

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

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

1. มีกองทัพของโปรแกรมเมอร์ที่สามารถเขียนรีมของโค้ด Java ธรรมดาได้ นี่ไม่ใช่ความจริงของโปรแกรมเมอร์ Lisp หรือ Haskell (หรือแม้แต่ Scala)
2. ทุกคนใช้ Java ดังนั้นมันจะต้องดี Corrolary: ผู้จัดการไม่จำเป็นต้องเลือก Java และภาษาที่คลุมเครือซึ่งไม่มีใครในโครงสร้างคำสั่งที่เคยได้ยินมา

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

สมมติว่าเป้าหมายของคุณคือการเติบโตในฐานะนักพัฒนาซอฟต์แวร์ทางออกที่ดีที่สุดของคุณคือ

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

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

จากประสบการณ์ของฉัน (ดูถูกเหยียดหยาม) เคยทำงานให้กับร้านที่เราใช้การเขียนโปรแกรมการทำงานและสัมภาษณ์กับคนอื่น ๆ :

1. มี CTO และบุคลากรทางเทคนิคระดับสูงคนอื่น ๆ ที่เคยมีประสบการณ์ในการเขียนโปรแกรมการทำงานและพยายามโน้มน้าวผู้บริหารที่ไม่ใช่ด้านเทคนิคของมัน (และบังเอิญคนเหล่านี้มีคุณสมบัติที่จะตอบคำถามของคุณได้ดีกว่าฉัน)
2. เมื่อคนเหล่านี้ออกจาก บริษัท และถูกแทนที่โดยคนที่ไม่มีความชอบสิ่งนี้จะไปทางทิศใต้ คนใหม่จะตำหนิทุกอย่างที่ผิดพลาด (รวมถึงและโดยเฉพาะอย่างยิ่งความล้มเหลวของตนเอง) ในภาษาการเขียนโปรแกรมแปลก ๆ และกระบวนทัศน์ที่ใช้ในการสร้างสิ่งที่มาก่อน พวกเขาจะทำให้คนที่เหลืออยู่ด้อยลงด้วยทักษะการเขียนโปรแกรมที่ใช้งานได้ผลักพวกเขาออกจาก บริษัท ระบบที่สร้างขึ้นจากภาษาที่ใช้งานจะลดลงโดยไม่มีการทำลาย ในความคิดของฉันสิ่งนี้เป็นความเสี่ยงที่ใหญ่ที่สุดที่ธุรกิจต้องดำเนินการหากพวกเขาใช้ภาษาที่ใช้งานได้และจะต้องไม่ถูกมองข้าม
3. องค์กรต้องมีวัฒนธรรม "การสร้างแทนการซื้อ" เพื่อการทำงาน เนื่องจากการใช้ภาษาที่ใช้งานได้นั้นจะทำให้ตัวเลือก "ซื้อ" น้อยลง
4. มีเกือบตลอดเวลาบางประนีประนอมกับผู้ว่าทางด้านเทคนิคและไม่ใช่เทคนิคของความคิด การประนีประนอมที่พบบ่อยที่สุดเหล่านี้คือภาษาที่ไม่ใช่ JVM นั้นไม่ได้พิจารณา Clojure และ Scala ถูกเสนอ Haskell และ O'Caml เพิ่งจะออกมาทันที

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

• ผลผลิต
  • พนักงานทั้งในปัจจุบันและอนาคต
  • บทบาททั้งหมด (สถาปนิก, ผู้พัฒนา, ผู้ทดสอบ, OPs, ... )
• แพลตฟอร์มที่รองรับ
  • ระบบปฏิบัติการ (ฮาร์ดแวร์?)
• ผู้จัดพิมพ์ของภาษา / แพลตฟอร์ม
  • ใบอนุญาต
• ครบกำหนดของภาษา / แพลตฟอร์ม
  • การสนับสนุน / โดยผู้เผยแพร่และ / หรือชุมชน
  • ห้องสมุด
• การย้ายฐานรหัสปัจจุบัน
  • หรือบูรณาการกับ

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

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

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

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

ขั้นตอนแรกอาจเป็นการเปิดเผยบุคคลและเหตุผลเบื้องหลังการตัดสินใจว่าผู้บริหารระดับสูงควรมีคำพูดในการตัดสินใจทางเทคนิคดังกล่าว แน่นอนฉันเดาได้เฉพาะที่นี่ แต่มีโอกาสมากที่พวกเขาจะมีประวัติการตัดสินใจที่ค่อนข้างเลวร้าย ลองหน้า: นักพัฒนาส่วนใหญ่ไม่ดีในการตัดสินใจ (แม้ทางเทคนิค) ในระดับ บริษัท

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

สิ่งสำคัญในการตัดสินใจเกี่ยวกับสถาปัตยกรรมคือ:

• รวบรวมข้อมูลจากผู้มีส่วนได้เสีย (การจัดการผู้ใช้ผู้ดูแลระบบการขายลูกค้า ... )
• การตัดสินใจขั้นพื้นฐานเกี่ยวกับอินพุตนั้น
• สื่อสารอย่างชัดเจน: การตัดสินใจ (ที่เสนอ) คืออะไร สิ่งที่พวกเขามีความเสี่ยงมุ่งมั่นที่จะบรรเทา; สิ่งที่ขัดแย้งกันคืออะไรและมีความล่าช้าบ้าง: ทำงานได้ดีแค่ไหน

หากคุณทำงานให้กับ บริษัท ขนาดใหญ่ที่มีพนักงาน 10K + พูดเตรียมที่จะเรียนรู้บทเรียนต่อไปนี้

• ความเร็วในการเขียนโค้ดไม่เกี่ยวข้องกับกำไร
• สิ่งต่าง ๆ เช่นการบำรุงรักษาในระดับของทศวรรษคือ
• ปัญหาที่คุณคิดว่าคุณสามารถแก้ปัญหาโดยใช้ภาษาที่ใช้งานได้นั้นไม่ได้เกี่ยวข้องกับกำไร
• ปัญหาเช่นการฝึกอบรมนักพัฒนา 1,000 คนความต้านทานตามธรรมชาติต่อการเปลี่ยนแปลงและการบำรุงรักษารหัสฐานที่เขียนโดยนักพัฒนาที่มีประสบการณ์น้อยกว่า 5 ปีในเทคโนโลยีที่ใช้คือ

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

หากกระบวนการนี้สร้างข้อเสนอแนะเพื่อใช้วิธีการทำงานในบางพื้นที่ที่คุณทำ

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

ข่าวร้ายคือ: ขึ้นอยู่กับขนาดและรูปแบบของ บริษัท ซึ่งอาจใช้เวลาสองสามปีหรือหลายทศวรรษ

ข่าวดีก็คือ: คุณจะได้เรียนรู้มากมายระหว่างทาง

ตั้งแต่ขั้นตอนแรกคือการเริ่มต้นที่จะพูดคุยและโดยเฉพาะอย่างยิ่งฟังผู้บริหารระดับสูงผมอยากแนะนำให้เริ่มต้นด้วยการอ่านเพียงแค่ฟัง

วิธีการหนึ่งที่ดีคือการแสดงให้เห็นว่ามันแสดงผลลัพธ์ที่ดีในอุตสาหกรรมและนำมาใช้

คุณสามารถรับข้อมูลบางส่วนจาก:

• http://www.quora.com/What-companies-use-a-functional-language-as-an-official-language

• http://pchristensen.com/blog/lisp-companies/

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

Google มีลิงค์อื่น ๆ ที่คล้ายกันสำหรับ Haskell, OCaml และอื่น ๆ

คุณมาที่นี่จากทิศทางที่ผิด

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

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

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

นี่เป็นการบอกว่านี่เป็นคำแนะนำที่จะทำให้คนที่มีพื้นฐานด้านเทคนิค (คดีแรก) และคนที่ไม่มี (กรณีที่สอง)

กรณีแรก

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

ตัวอย่างโค้ด 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);
}

เขียนโค้ดเดียวกันโดยคำนึงถึงการใช้งานโปรแกรมในใจ:

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))
    );

จากนั้นถามพวกเขา:

1. โปรแกรมเมอร์สามารถทำผิดในกี่ตัวอย่างแรก? แล้วอันที่สองล่ะ?

2. มันยากแค่ไหนที่จะเห็นความผิดพลาด?

3. การแก้ไขโค้ดทำได้ยากเพียงใด

ปัจจัยทั้งสามนี้มีผลต่อผลผลิตและราคาของผลิตภัณฑ์

กรณีที่สอง

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

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