การออกแบบระบบใหม่สำหรับ Scala

ดวงจันทร์จำนวนมากหลายครั้งแล้วที่ฉันทำปริญญาโทของฉันในวิศวกรรมซอฟต์แวร์เชิงวัตถุ ฉันครอบคลุมทุกอย่าง: การเริ่มต้นโครงการ, ความต้องการ, การวิเคราะห์, ออกแบบ, สถาปัตยกรรม, การพัฒนา, ฯลฯ หนังสือเล่มโปรดของฉันตลอดเวลาคือการพัฒนาซอฟต์แวร์เชิงวัตถุ, แนวทางประสบการณ์ (IBM-1996) หนังสือที่สร้างขึ้นโดยกลุ่มผู้เชี่ยวชาญที่แท้จริงของเวลาของพวกเขา มันอธิบายวิธีการทำงานของผลิตภัณฑ์เป็นศูนย์กลางเพื่อการวิเคราะห์เชิงวัตถุการออกแบบและการพัฒนา

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

การออกแบบและการพัฒนาสูญเสียไปอย่างสนุกและฉันกำลังจะออกจากอุตสาหกรรมไอทีทั้งหมดไปกับฉัน

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

ฉันชอบการออกแบบระบบ ฉันเป็นสถาปนิกที่สำคัญมากกว่าโปรแกรมเมอร์ ฉันรักการวิเคราะห์การออกแบบการคิดการโต้เถียงการปรับปรุง - ฉันรักการออกแบบที่เรียบง่ายสะอาดและกรอบ

เราจะออกแบบโซลูชัน Scala บริสุทธิ์ได้อย่างไร

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

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

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

ไม่ออกแบบเช่น / กระบวนการ / วิธีการแก้ปัญหาที่มีอยู่หรือว่ามันเป็นเวลาที่จะคิดค้นหรือไม่

ฉันไม่สามารถตอบคำถามนี้ได้จริงๆ แต่ให้ฉันเสนอความคิด

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

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

แผนภาพระดับ UML นั้นมีความสอดคล้องกับ Scala มากกว่า ใช่ mixins ไม่ได้ผ่านมาดี แต่นั่นเป็นสิ่งที่อาจจะ "tweaked" มากกว่าการซ่อมแซม แต่ฉันคิดว่ามันอาจจะขาดจุด

พิจารณาอีกครั้งว่าทำไมสกาล่ามี "วัตถุที่โง่" หากคุณเขียนคลาสเคสโดยไม่มีเมธอด:

case class NewInvite(user: User, league: League)

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

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

UML โผล่ออกมาจาก "Bubble Wars" ในช่วงปลายยุค 80 และต้นยุค 90 มันเป็นการประนีประนอมต่อสัญกรณ์เสมอไม่ใช่วิธีการออกแบบ จำนวนแคลอรี่ที่เกิดจาก UML นั้นเป็นผลมาจากวิธีการออกแบบที่บอกว่า "ขั้นตอนที่ 1: วาดโมเดลคลาส"

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

ความรับผิดชอบ

CRC ทำงานได้ดีสำหรับ Scala เช่นเดียวกับภาษา OO อื่น ๆ ซึ่งก็บอกได้ว่ามันทำงานได้ดีมาก! การสร้างแบบจำลองการจัดสรรความรับผิดชอบโดยนักแสดงมนุษย์และเข้าใจความร่วมมือของพวกเขายังคงทำงานได้ดี

ในขนาดใหญ่คุณยังควรออกแบบด้วยวัตถุ ขอบเขตของวัตถุเป็นขอบเขตของการห่อหุ้ม รักษาสถานะที่ไม่แน่นอนและรายละเอียดการใช้งานภายในขอบเขตของวัตถุเหล่านั้น คลาส Case สร้างวัตถุอินเทอร์เฟซที่ดีดังนั้น Vanilla collection และโครงสร้างข้อมูล

การทำความเข้าใจการใช้งาน

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

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

การเป็นตัวแทนและสัญกรณ์

ดังนั้นภายในโครงสร้างการออกแบบนี้คุณยังต้องขจัดความคิดออกจากหัวของคุณและแบ่งปันกับคนอื่น

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

ลองศึกษาเทคนิคการเขียนโปรแกรมอย่างละเอียด

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

เราจะออกแบบโซลูชัน Scala บริสุทธิ์ได้อย่างไร

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

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

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

โดยสรุปประเด็นหลักของฉันคือคุณไม่ควรพยายาม "ออกแบบโซลูชันสกาล่าบริสุทธิ์" คุณควรออกแบบโซลูชันด้วยวิธีที่เป็นธรรมชาติและเข้าใจง่ายที่สุดเท่าที่จะเป็นไปได้และมันก็เกิดขึ้นได้ว่า Scala เป็นเครื่องมือที่มีความยืดหยุ่นอย่างไม่น่าเชื่อที่สามารถช่วยคุณปรับใช้โซลูชันเหล่านั้นได้หลายวิธี เมื่อสิ่งที่คุณรู้คือค้อนปัญหาทุกอย่างจะเริ่มดูเหมือนเล็บดังนั้นโปรดสำรวจวิธีการต่าง ๆ ที่คุณมี อย่าพยายามปิดขั้นตอนการออกแบบเพื่อทำตามขั้นตอน X, Y และ Z เพื่อไม่ให้คุณพลาดโอกาสจาก A ถึง W

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

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

ฉันขอแนะนำให้เรียนรู้เคล็ดลับหรือสองอย่างจากชุมชนโปรแกรมการทำงานอื่น ๆ เช่น Haskell และ Scheme ไม่ใช่ความรู้ด้านการออกแบบทั้งหมดที่ถ่ายโอนไปยัง Scala แล้ว

คำถามคือ: เราจะออกแบบโซลูชัน Scala บริสุทธิ์ได้อย่างไร

คำตอบที่ชอบ

1. เราใช้ XYZ เพราะ ....
2. เราใช้ ABC แต่ก็เป็นเช่นนั้น ....
3. เราเริ่มใช้ XYZ แต่พบว่า ABC น่าจะดีกว่าเพราะ ...

จะระบุถึงการมีวุฒิภาวะหรือการยอมรับที่มีอยู่โดยทั่วไปของชุดเครื่องมือหรือโซลูชันดังกล่าว

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

จะปลอดภัยไหมถ้าจะบอกว่าเรารู้คำตอบของคำถามทางเลือก:

"... ถึงเวลาประดิษฐ์หรือยัง?"

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

คุณสามารถลงคะแนนคำตอบของฉันถ้าคุณไม่เห็นด้วย ฉันจะเอามันเหมือนผู้ชาย

ฉันจะไม่แยกความแตกต่างระหว่างภาษาฉันจะทำเช่นเดียวกันในจาวา อย่างไรก็ตามฉันมาจากโรงเรียน OO มากกว่าการทำงาน (พีชคณิต Haskell หนึ่งหรือหนึ่งเสียงกระเพื่อม) การออกแบบแอพ Haskell นั้นแตกต่างจาก Scala หรือ Clojure จริงๆ นอกจากนี้การออกแบบแอป Scala.js นั้นแตกต่างกันเนื่องจาก DOM ที่ไร้รัฐ - มันยากที่จะต่อสู้กับส่วนที่แออัดของแอปของคุณที่จำเป็น เมื่อเวลาผ่านไปฉันได้ทำตามวิธี OO ในขณะที่พยายามที่จะกำจัดรัฐและความไม่แน่นอนให้มากที่สุด หากฉันเป็นแฟนตัวพิมพ์ใหญ่หรือแฟนตัวยงแอพของฉันอาจดูแตกต่างออกไป

1. การตัดสินใจเลือกเทคโนโลยีและการออกแบบที่สำคัญเช่นความรับผิดชอบของลูกค้า / เซิร์ฟเวอร์ลักษณะการกระจาย - เราจำเป็นต้องมีข้อมูลอยู่หรือไม่? สิ่งที่เหมาะกับใบสมัครของเราดีที่สุด? (แน่นอนยังไม่ใช่ห้องสมุดหรือกรอบ)

2. เริ่มต้นด้วยApp.scalaไฟล์เพียงไฟล์เดียวที่ฉันกำหนดประเภทคีย์ (ลักษณะและคลาสเคส) และบทบาท - มีการไตร่ตรองและคิดอย่างมากในขณะที่เป็น AFK มันง่ายมากที่จะเล่นกับมันในขณะที่มันอยู่ในไฟล์เดียว แม้แต่ตัวต้นแบบก็อาจกลายเป็นหากเป็นแอพพลิเคชั่นที่เรียบง่าย ฉันอุทิศเวลาให้กับช่วงเวลานี้มากเพราะไม่มีสิ่งใดสำคัญไปกว่าการมีต้นแบบที่ถูกต้องที่สุดและโปร่งใสและเป็นไปได้ ทุกอย่างช่วยให้เราพิจารณาอย่างแม่นยำยิ่งขึ้นและเพิ่มโอกาสในการประสบความสำเร็จ

3. ตอนนี้เมื่อเราได้พิสูจน์ความถูกต้องของการแก้ปัญหาของเราเรามีวิสัยทัศน์ที่ชัดเจนและปัญหาที่อาจเกิดขึ้นได้รับการเปิดเผยแล้วก็ถึงเวลาแล้วที่ต้องคิดว่าห้องสมุดหรือวิธีการของบุคคลที่สามประเภทใดที่จะนำเข้ามา พวกเราจะทำให้นักแสดงที่เป็นรัฐเหล่านี้หรือไม่เราต้องการความยืดหยุ่นของ Akka .. หรือไม่? เราใช้ Rx สำหรับสตรีมเหล่านี้หรือไม่ เราใช้อะไรสำหรับ UI ดังนั้นเราจะไม่เสียสติไปหลังจากมีคุณสมบัติแบบโต้ตอบ 10 แบบ

4. แบ่งApp.scalaไฟล์ออกเป็นหลาย ๆ อันเพราะลักษณะและคลาสใหม่ ๆ ปรากฏขึ้นและใหญ่ขึ้น อินเทอร์เฟซของพวกเขาควรบอกเกี่ยวกับบทบาทของพวกเขา ตอนนี้ก็ถึงเวลาคิดเกี่ยวกับการใช้คลาสประเภทและความแตกต่างของ ad-hoc ที่เป็นไปได้ ดังนั้นใครก็ตามที่เรียกใช้ส่วนต่อประสานของคุณจะต้องมีความยืดหยุ่นสำหรับพวกเขา ประเด็นก็คือการใช้งานฟังก์ชั่นทั่วไปเท่านั้นโดยทิ้งรายละเอียดไปยังผู้โทร บางครั้งสิ่งที่คุณพยายามนำไปใช้อาจเป็นทัวริงที่สมบูรณ์แบบดังนั้นคุณควรจัดเตรียมวิธีสำหรับผู้โทรเพื่อใช้งานแบบเจาะจงด้วยตัวเองแทนที่จะทำการซ้อนการร้องขอคุณสมบัติใน GitHub สิ่งนี้ยากที่จะเพิ่มในภายหลัง จะต้องมีการคิดผ่านจุดเริ่มต้นมาก เช่นเดียวกับการออกแบบ DSL

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

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

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

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

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