มีวิธีการทางวิศวกรรมซอฟต์แวร์สำหรับการตั้งโปรแกรมการทำงานหรือไม่? [ปิด]

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

hype ใหม่คือการเขียนโปรแกรมใช้งานได้ซึ่งสอนในหนังสือและแบบฝึกหัดมากมาย แต่สิ่งที่เกี่ยวกับวิศวกรรมซอฟต์แวร์การทำงาน? ในขณะที่อ่านเกี่ยวกับ Lisp และ Clojure ฉันมาถึงสองข้อความที่น่าสนใจ:

1. โปรแกรมการทำงานนั้นมักจะถูกพัฒนาจากล่างขึ้นบนแทนที่จะเป็นบนลงล่าง ('บน Lisp', Paul Graham)

2. ฟังก์ชั่นโปรแกรมเมอร์ใช้แผนที่ที่ OO-โปรแกรมเมอร์ใช้วัตถุ / คลาส ('Clojure สำหรับ Java โปรแกรมเมอร์', พูดคุยโดย Rich Hickley)

ดังนั้นวิธีการสำหรับการออกแบบอย่างเป็นระบบ (ตามรูปแบบ?) ของการใช้งานคือใน Lisp หรือ Clojure? ขั้นตอนทั่วไปคืออะไรฉันใช้สิ่งประดิษฐ์อะไรฉันจะแม็พสิ่งเหล่านั้นจากพื้นที่ปัญหาไปยังพื้นที่โซลูชันอย่างไร

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

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

  ฟังก์ชันลำดับสูงเหล่านี้มักจะมาพร้อมกับกฎหมายของการเขียนโปรแกรมบางอย่างหรือที่เรียกว่า "ทฤษฎีบทเสรี"

• โปรแกรมเมอร์ที่ใช้งานได้ใช้ไดอะแกรมน้อยกว่าตัวเขียนโปรแกรม OO มาก มากในสิ่งที่จะแสดงในแผนภาพ OO จะแสดงแทนในประเภทหรือใน "ลายเซ็น" ซึ่งคุณควรจะคิดว่าเป็น "ประเภทโมดูล" Haskell ยังมี "class classes" ซึ่งค่อนข้างคล้ายกับประเภทอินเตอร์เฟส

  โปรแกรมเมอร์ที่ใช้งานได้จริงประเภทนั้นคิดว่า "เมื่อคุณได้ประเภทที่ถูกต้องแล้วโค้ดก็จะเขียนเอง"

  ไม่ใช่ภาษาที่ใช้งานได้ทั้งหมดใช้ประเภทที่ชัดเจน แต่หนังสือHow To Design Programsหนังสือที่ยอดเยี่ยมสำหรับการเรียนรู้ Scheme / Lisp / Clojure นั้นอาศัย "การบรรยายข้อมูล" ซึ่งเกี่ยวข้องกับประเภทอย่างใกล้ชิด

ดังนั้นวิธีการสำหรับการออกแบบอย่างเป็นระบบ (ตามรูปแบบ?) ของการใช้งานคือใน Lisp หรือ Clojure?

วิธีการออกแบบใด ๆ ที่อยู่บนพื้นฐานของข้อมูลนามธรรมทำงานได้ดี ฉันคิดว่าสิ่งนี้จะง่ายขึ้นเมื่อภาษามีประเภทที่ชัดเจน แต่ก็ใช้ได้แม้จะไม่มี หนังสือที่ดีเกี่ยวกับวิธีการออกแบบสำหรับประเภทข้อมูลนามธรรมซึ่งปรับให้เข้ากับการเขียนโปรแกรมการทำงานได้อย่างง่ายดายคือAbstraction และ Specification ในการพัฒนาโปรแกรมโดย Barbara Liskov และ John Guttag ฉบับพิมพ์ครั้งแรก Liskov ได้รับรางวัลทัวริงในส่วนของงานนั้น

วิธีการออกแบบอื่นที่ไม่ซ้ำกับ Lisp คือการตัดสินใจว่าส่วนขยายของภาษาใดจะมีประโยชน์ในโดเมนปัญหาที่คุณใช้งานอยู่จากนั้นใช้มาโครที่ถูกสุขลักษณะเพื่อเพิ่มโครงสร้างเหล่านี้ในภาษาของคุณ เป็นสถานที่ที่ดีในการอ่านเกี่ยวกับชนิดของการออกแบบนี้เป็นบทความแมทธิว Flatt ของการสร้างภาษาในแร็กเก็ต บทความอาจอยู่เบื้องหลัง paywall คุณสามารถค้นหาเนื้อหาทั่วไปเพิ่มเติมเกี่ยวกับการออกแบบประเภทนี้ได้โดยค้นหาคำว่า "ภาษาฝังตัวเฉพาะโดเมน" โดยเฉพาะอย่างยิ่งสำหรับคำแนะนำและตัวอย่างเกินกว่าสิ่งที่แมทธิว Flatt ครอบคลุมผมก็อาจจะเริ่มต้นด้วยเกรแฮมในเสียงกระเพื่อมหรือบางทีอาจจะANSI Common เสียงกระเพื่อม

อะไรคือขั้นตอนทั่วไปฉันใช้สิ่งประดิษฐ์อะไร

ขั้นตอนทั่วไป:

1. ระบุข้อมูลในโปรแกรมและการดำเนินการของคุณและกำหนดประเภทข้อมูลนามธรรมที่เป็นตัวแทนของข้อมูลนี้

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

3. หากคุณใช้ภาษาที่ใช้งานได้ให้ใช้ตัวตรวจสอบประเภทก่อนและบ่อยครั้ง หากคุณใช้ Lisp หรือ Clojure แนวทางปฏิบัติที่ดีที่สุดคือการเขียนสัญญาฟังก์ชั่นก่อนรวมถึงการทดสอบหน่วย - เป็นการพัฒนาโดยใช้การทดสอบเป็นส่วนใหญ่ และคุณจะต้องการที่จะใช้สิ่งที่รุ่นของ QuickCheck ได้รับการแจ้งความกับแพลตฟอร์มของคุณซึ่งในกรณีลักษณะของคุณเหมือนว่ามันจะเรียกว่าClojureCheck มันเป็นห้องสมุดที่ทรงพลังอย่างยิ่งสำหรับการสร้างการทดสอบแบบสุ่มของรหัสที่ใช้ฟังก์ชั่นการสั่งซื้อที่สูงขึ้น

สำหรับ Clojure ฉันขอแนะนำให้กลับไปใช้โมเดลเชิงสัมพันธ์แบบเก่าที่ดี Out of the Tarpitเป็นการอ่านที่สร้างแรงบันดาลใจ

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

ประสบการณ์ของฉันมาจากการย้ายจาก Java ไป Clojure ในปีที่ผ่านมา

ตัวอย่างบางส่วน:

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

• การวางแนวทางการบริการในการออกแบบ - ใช้งานได้ดีมากในมุมมองของ FP เนื่องจากบริการทั่วไปเป็นเพียงฟังก์ชั่นที่มีผลข้างเคียง ฉันคิดว่ามุมมอง "จากล่างขึ้นบน" ของการพัฒนาซอฟต์แวร์บางครั้งดำเนินการในโลก Lisp เป็นจริงเพียงหลักการออกแบบ API ที่มุ่งเน้นบริการที่ดีในอีกรูปแบบหนึ่ง

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

• การป้องกัน / การทำซ้ำ - ทำงานได้ดีกับ FP คุณอาจสามารถใช้ต้นแบบกับผู้ใช้งานได้หากคุณเก่งเรื่องเครื่องมือสร้าง / DSL และใช้พวกมันที่ REPL

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

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

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

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

ตอนนี้คุณมีโดเมนที่คุณมีฟังก์ชั่นที่เขียนตามกฎหมายที่ประพฤติตัวดี DSL ในตัวที่เรียบง่าย!

โอ้และคุณสมบัติที่กำหนดคุณสามารถเขียนแบบทดสอบอัตโนมัติแบบสุ่ม (ala QuickCheck) .. และนั่นเป็นเพียงจุดเริ่มต้น

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

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

วิธีหนึ่งคือการสร้าง DSL ภายในภายในภาษาการทำงานของโปรแกรมที่เลือกไว้ "รุ่น" นั้นเป็นชุดของกฎเกณฑ์ทางธุรกิจที่แสดงใน DSL

ดูคำตอบของฉันในโพสต์อื่น:

Clojure aproach แยกความกังวลได้อย่างไร

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

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

นี่ลิงค์ไม่กี่:

http://www.northeastern.edu/magazine/0301/programming.html

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.86.8371

ฉันเพิ่งพบหนังสือเล่มนี้: การสร้างแบบจำลองโดเมนที่ใช้งานได้และปฏิกิริยา

ฉันคิดว่าสอดคล้องกับคำถามของคุณอย่างสมบูรณ์

จากคำอธิบายหนังสือ:

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

มีรูปแบบ "การคำนวณโปรแกรม" / "ออกแบบโดยการคำนวณ" ที่เกี่ยวข้องกับศาสตราจารย์ Richard Bird และกลุ่มพีชคณิตของ Programming ที่ Oxford University (UK) ฉันไม่คิดว่ามันไกลเกินกว่าที่จะพิจารณาวิธีการนี้

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

ฉันได้พบว่าการพัฒนาพฤติกรรมขับเคลื่อนเป็นแบบธรรมชาติสำหรับการพัฒนารหัสอย่างรวดเร็วทั้ง Clojure และ SBCL ข้อได้เปรียบที่แท้จริงของการใช้ประโยชน์จาก BDD ด้วยภาษาที่ใช้งานได้คือฉันมักจะเขียนการทดสอบหน่วยเกรนละเอียดมากกว่าที่ฉันมักจะใช้เมื่อใช้ภาษาเชิงปฏิบัติเพราะฉันทำงานได้ดีขึ้นมากในการย่อยสลายปัญหา

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

ตัวอย่างที่ดีคือ fmap ฟังก์ชันนี้รับฟังก์ชั่นเป็นอาร์กิวเมนต์และนำไปใช้กับ "องค์ประกอบ" ทั้งหมดของอาร์กิวเมนต์ที่สอง เนื่องจากมันเป็นส่วนหนึ่งของคลาสประเภท Functor อาจมีการส่งตัวอย่างของ Functor (เช่นรายการกราฟ ฯลฯ ... ) เป็นอาร์กิวเมนต์ที่สองสำหรับฟังก์ชันนี้ มันจับพฤติกรรมทั่วไปของการใช้ฟังก์ชั่นกับทุกองค์ประกอบของการโต้แย้งที่สอง

ดี,

โดยทั่วไปภาษาการเขียนโปรแกรมฟังก์ชั่นจำนวนมากถูกนำมาใช้ในมหาวิทยาลัยเป็นเวลานานสำหรับ "ปัญหาของเล่นขนาดเล็ก"

พวกเขากำลังได้รับความนิยมมากขึ้นในขณะนี้เนื่องจาก OOP ประสบปัญหากับ "การเขียนโปรแกรม paralel" เนื่องจาก "state" และรูปแบบการใช้งานบางครั้งดีกว่าสำหรับปัญหาในมือเช่น Google MapReduce

ฉันแน่ใจว่าเมื่อผู้ชาย functioanl ชนกำแพง [ลองใช้ระบบที่มีขนาดใหญ่กว่า 1,000,000 บรรทัดของโค้ด] บางคนจะมาพร้อมกับวิธีการทางวิศวกรรมซอฟต์แวร์ใหม่พร้อมคำฉวัดเฉวียน :-) พวกเขาควรตอบคำถามเก่า: จะแบ่งระบบออกเป็นชิ้น ๆ อย่างไรเพื่อที่เราจะ "กัด" แต่ละชิ้นทีละครั้ง? [ทำงานซ้ำ, วิธีการวิวัฒนาการระหว่างกรรม] โดยใช้สไตล์การใช้งาน

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

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

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