หลักฐานเชิงประจักษ์สำหรับการเลือกกระบวนทัศน์การเขียนโปรแกรมเพื่อแก้ไขปัญหา

วิกิ C2 มีการอภิปรายหลักฐานเชิงประจักษ์สำหรับการเขียนโปรแกรมเชิงวัตถุซึ่งโดยทั่วไปสรุปแล้วไม่มีใครเลยที่จะดึงดูดอำนาจ นี่ถูกแก้ไขครั้งสุดท้ายในปี 2551 การสนทนาที่นี่ดูเหมือนจะทนได้: คำถามว่า OO ล้าสมัยหรือไม่เมื่อการเขียนโปรแกรมเชิงปฏิบัติการเป็นตัวเลือกที่ไม่ดีและข้อดีและข้อเสียของ AOPล้วนได้รับการตอบรับความคิดเห็นของผู้มีส่วนร่วม

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

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

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

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

สำหรับการถ่ายก่อนหน้าดูการแก้ไข 1 ของคำตอบนี้ อย่างไรก็ตามความคิดเห็นและการแก้ไขของคำถามนั้นทำให้ชัดเจนยิ่งขึ้นเกี่ยวกับสิ่งที่คำถามกำลังค้นหาและทำให้ฉันชัดเจนยิ่งขึ้น

ใช่วิศวกรรมซอฟต์แวร์เชิงหลักฐาน (EBSE) เป็นสิ่งหนึ่ง มีที่ดูเหมือนจะเป็นความพยายามที่ไม่กี่ไปยังฐานข้อมูล EBSE เช่นนี้ที่มหาวิทยาลัยเดอร์แฮมและเมล็ดพันธุ์ซึ่งถูกตั้งขึ้นโดยอาจารย์ที่อาชีวะ ความพยายามทั้งหมดเหล่านี้รวมถึงสิ่งที่กล่าวถึงในเอกสารจำนวนหนึ่งที่สามารถพบได้ผ่านเซิร์ฟเวอร์ IEEE XploreหรือACM Digital Library(การสมัครสมาชิกหรือการซื้อที่จำเป็นสำหรับเอกสารจำนวนมากในทั้งสอง) จะขึ้นอยู่กับยาตามหลักฐาน พวกเขาให้ความคิดเห็นวรรณกรรมของข้อมูลเชิงประจักษ์ (การสังเกตและการทดลอง) ที่เผยแพร่ ในความเป็นจริงรวมถึง "การตรวจสอบวรรณกรรม" ในสตริงการค้นหาในการค้นหาสิ่งพิมพ์ใด ๆ ที่ให้ข้อมูลในหัวข้อส่วนใหญ่ - มากกว่า 14000 ครั้งใน ACM และมากกว่า 1,000 ในฐานข้อมูล IEEE (เมื่อ จำกัด เฉพาะหัวข้อการคำนวณเท่านั้น)

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

ดังนั้นแนวคิดนี้มีอยู่ในวิศวกรรมซอฟต์แวร์ Academia ตระหนักถึงแนวคิดที่อิงหลักฐานเชิงประจักษ์และสามารถนำไปใช้กับวิศวกรรมซอฟต์แวร์ได้สำเร็จ

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

ไม่มีทางออก "หมุนข้อเหวี่ยง" ในการเลือกกระบวนทัศน์

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

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

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

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

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

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

ฉันได้อ่านThe Art of Unix Programmingโดย Eric S. Raymond มันมีข้อมูลเชิงลึกทางประวัติศาสตร์ที่น่าสนใจเกี่ยวกับสิ่งต่าง ๆ ที่เราได้รับในขณะนี้ เขาอ้างถึงการศึกษาที่ดีจากซอฟต์แวร์ IEEEที่ใช้หลักฐานเชิงประจักษ์เช่นความหนาแน่นของข้อบกพร่อง นั่นอาจเป็นแหล่งข้อมูลที่ดีหากคุณกำลังมองหาการศึกษาสไตล์วิชาการ

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

เดนนิสริชชี่สนับสนุนการแยกส่วนโดยการบอกทุกคนว่าการเรียกใช้ฟังก์ชั่นนั้นถูกจริงๆในซีทุกคนเริ่มเขียนฟังก์ชั่นขนาดเล็กและการทำให้เป็นโมดูล หลายปีต่อมาเราพบว่าการเรียกใช้ฟังก์ชันยังมีราคาแพงใน PDP-11 และรหัส VAX มักใช้เวลา 50% ในการสอน CALLS เดนนิสโกหกเรา! แต่มันก็สายเกินไป; เราทุกคนติดยา ...

- สตีฟจอห์นสัน

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

ปัญหาที่สองคือ 50% ของผู้พัฒนามีทักษะการเขียนโปรแกรมต่ำกว่าค่าเฉลี่ย ไม่สำคัญว่านักพัฒนาซอฟต์แวร์ของคุณจะทำงานได้อย่างมีประสิทธิภาพมากขึ้นหรือไม่หาก "rabble" พยายามดิ้นรนเขียนซอฟต์แวร์ที่ใช้งานอยู่ให้ซอฟต์แวร์ที่สวยงามและได้รับการออกแบบมาอย่างดี เช่นเดียวกันกับภาษาการเขียนโปรแกรมTMTOWTDIนักพัฒนาซอฟต์แวร์ชั้นนำของคุณยังคงเขียนโค้ดแบบแยกส่วน แต่โคเดอร์ที่มีความสามารถน้อยเขียนเสียงเส้นเนื่องจากไม่มีโครงสร้างที่กำหนดไว้

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

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

มีการแข่งขันเขียนโปรแกรมที่ใช้ระบบคัดเกรดคอมพิวเตอร์และอนุญาตให้คุณเขียนเป็นภาษาต่าง ๆ และโพสต์ผลลัพธ์และสิ่งของทุกประเภท ฉันพนันว่าพวกเขามีข้อมูลที่ดีสำหรับคุณ นี่คือรายการ 8: http://www.makeuseof.com/tag/8-onlineprogramming-contests-challenge-win/

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

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

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

ฉันศึกษาวิธีการพัฒนาซอฟต์แวร์มานานกว่า 30 ปีแล้ว มีหลักฐานตีพิมพ์ที่ดีเกี่ยวกับการเลือกกระบวนทัศน์

ฉันรวบรวมบรรณานุกรม ASCII ขนาดใหญ่ที่สามารถค้นหาได้ ซึ่งรวมถึงเอกสารและบทความ IEEE และ ACM จำนวนมาก ฉันติดแท็กรายการด้วยประเภทของหลักฐานที่มีให้ นี่คือแท็กที่พบบ่อยที่สุด:

...
133 =EXPERIMENT
177 =HISTORY
233 =IDEA
267 =SURVEY
338 =ESSAY
395 =THEORY
454 =ADVERT
491 =EXPERIENCE
500 =DEMO

ตอนนี้ค้นหา PARADIGM และนับแท็ก

  1 =ESSAY
  1 =EXPERIENCE
  1 =HISTORY
  1 =IDEA
  1 =POLEMIC
  1 =SURVEY
  1 =TALK

หากคุณต้องการขุดให้ลึกยิ่งขึ้นhttp://cse.csusb.edu/dick/lab.html และฉันหวังว่ามันจะช่วย ...

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

บทความจากปี 2004 วิศวกรรมซอฟต์แวร์เชิงหลักฐานโดย Kitchenham et al ได้กล่าวถึงประโยชน์ที่จะได้รับอย่างชัดเจนจากแนวทางเชิงหลักฐานและปัญหาที่เกิดขึ้นกับการนำไปใช้ในวิศวกรรมซอฟต์แวร์ ฉันจะไม่พูดคุยด้านผลประโยชน์ที่นี่ (ชัดเจนจากคำถามที่ฉันต้องการที่จะสามารถทำงานด้วยวิธีนี้) แต่ปัญหาที่เกี่ยวข้องเป็นคำตอบสำหรับคำถามที่ฉันถาม

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

ดังนั้นคำตอบที่ฉันตามหาคือ "ไม่" หลักฐานที่ฉันกำลังมองหาอาจไม่มีอยู่จริง ฉันควรเลือกกระบวนทัศน์ของฉันตามเกณฑ์ยอดนิยมที่มีอยู่ในสิ่งที่ฉันรู้ความคิดเห็นที่เจ๋งและความเห็นของผู้เชี่ยวชาญ

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

UPDATE

เพื่อตอบกลับความคิดเห็นที่เกรแฮมทิ้งฉันไว้:
ฉันถือว่าสถาปัตยกรรมโดยคุณหมายถึงกระบวนทัศน์การเขียนโปรแกรม หากคุณกำลังจะใช้ Clojure บางทีคุณควรจ้างทีมโปรแกรมเมอร์ Clojure อย่างไรก็ตามจากการค้นหาอย่างรวดเร็ว Clojure เป็นภาษาที่ใช้ภาษาจาวาจึงเกิดขึ้นเพื่อให้สามารถใช้งานได้ รับข้อมูลที่ฉันจะใช้โปรแกรมเมอร์ Java (เนื่องจากในทางเทคนิคพวกเขาสามารถเขียน Java และมันจะให้ผลลัพธ์เดียวกัน) หรือมองหาโปรแกรมเมอร์ที่ใช้งานได้เช่นนักพัฒนา Haskell ตอนนี้ในแง่ของการเลือกสิ่งที่ดีที่สุดมันขึ้นอยู่กับทีมของคุณ ฉันไม่เคยมีทีมผู้เชี่ยวชาญด้านฐานข้อมูลเชิงสัมพันธ์ที่จัดระเบียบโซลูชันคลาวด์ให้ฉันและฉันจะไม่มีทีมโปรแกรมเมอร์ที่ใช้งานได้สร้างโซลูชัน object orient สำหรับฉัน คุณต้องใช้จุดแข็งของทีมคุณไม่ได้มีวิสัยทัศน์ที่น่ายกย่องที่คุณมีในหัวสำหรับสิ่งที่ทีม "ควร"

กระบวนทัศน์ที่แตกต่างนำไปสู่การแก้ปัญหาที่แตกต่างกัน แบบไหนที่ดีที่สุด 'ขึ้นอยู่กับ:

• การแก้ไขปัญหา
• ทีมพัฒนา
• สภาพแวดล้อมการดำเนินงาน

ฉันรู้ว่าไม่มีการศึกษาที่ชัดเจนเช่นนั้นและแม้ว่าจะมีสิ่งหนึ่งที่ฉันจะไม่เชื่อใจ

นั่นคืองานของสถาปนิก

การแทนที่ภูมิปัญญาของสถาปนิกด้วยข้อสรุปที่ไม่เกี่ยวข้องอาจเป็นสูตรสำหรับภัยพิบัติ

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

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