โปรแกรมเมอร์สามารถเรียนรู้อะไรจากอุตสาหกรรมการก่อสร้าง? [ปิด]

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

หนึ่งในวิธีที่ดีที่สุดในการเรียนรู้ (หรือสอน) คือการวิเคราะห์อุปมาอุปมัย - อุปมาอุปมัยอื่นใดที่สามารถดึงออกมาจากการสร้างได้? (ไม่ว่าจะเป็นการใช้งานทั่วไปในซอฟต์แวร์หรือไม่ก็ตาม)

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

^{[เครดิตกับแนวคิดการเขียนโปรแกรมนำมาจากศิลปะและมนุษยศาสตร์สำหรับความคิด]}

นั่นคือที่มาของรูปแบบการออกแบบ

คนที่ถูกกล่าวหาว่านำแนวคิดไปทั่วโลกก็คือคริสอเล็กซานเดในหนังสือของเขา "เป็นรูปแบบภาษา: เมืองอาคารเครื่องจักรงานก่อสร้าง" 1977 จากนั้นแก๊งสี่ (GoF) หยิบมันขึ้นมาและส่วนที่เหลือคือประวัติศาสตร์

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

การเปรียบเทียบและการอ้างอิงบางอย่างที่ฉันสามารถนึกถึงหรือระลึกถึง:

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

(หากนึกถึงฉันจะเพิ่มพวกเขา)

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

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

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

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

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

สำหรับคำพูดส่วนมากจะมาจากการก่อสร้างอย่างถูกต้องและผิด

Frameworkเป็นสิ่งที่ชัดเจนที่สุดที่ยังไม่ได้ดำเนินการ และมีท่อ

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

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

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

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

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

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

ตอนนี้คนส่วนใหญ่ยังไม่โง่พอที่จะลองสิ่งนี้ในโลกการก่อสร้าง แต่มันเกิดขึ้นตลอดเวลาในโลกของซอฟต์แวร์เพราะผู้คนไม่ได้เชื่อมต่อเหล่านี้:

1. คนที่มีคุณสมบัติในการสร้างโรงสวนที่ดีจริงๆไม่จำเป็นต้องมีคุณสมบัติในการสร้างบ้าน

2. ถ้าคุณรู้ล่วงหน้าว่าคุณกำลังจะสร้างบ้านเป็นระยะ แต่มันก็แค่จะเริ่มเป็นโรงเก็บของในสวนคุณจะทำสิ่งที่แตกต่างและโรงเก็บของในสวนจะมีค่าใช้จ่ายมากขึ้น แผ่นหนาจริง ๆ ตรวจสอบให้แน่ใจว่าคุณมีตัวนำที่ใหญ่พอสำหรับบ้านที่เต็มแล้ว ฯลฯ )

3. ในหลายกรณีการอัปเกรดจากเวทีหนึ่งไปอีกเวทีหนึ่งนั้นเกี่ยวข้องกับการเลิกงานจำนวนมากที่ทำไปก่อนหน้านี้ทำให้มีราคาแพงกว่าที่ควรจะเป็น

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

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

ข้อตกลงเสร็จสิ้นการทำงานและตัดแต่งอยู่ในใจ

ความคิดที่ว่ามันโอเคที่จะเสนอตัวเลือกสุนทรียะบางอย่างเมื่อการตัดสินใจทางโครงสร้างที่สำคัญเสร็จสมบูรณ์

สุภาษิตโบราณ: วัดสองครั้งและตัดครั้งเดียว

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

ข้อ จำกัด ที่มีอยู่ทั้งในการก่อสร้างและการเขียนโปรแกรม

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

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

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

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

ในทางกลับกันเรายังคงค้นพบว่ารูปแบบและการปฏิบัติหลายอย่างของเราต้องการพื้นที่สำหรับการปรับปรุง Singleton เคยเป็นความคิดที่ดีตอนนี้ส่วนใหญ่ที่คิดเกี่ยวกับมันชอบรูปแบบ IoC / DI

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

แน่นอนในทั้งสองสาขาสถาปนิกสามารถวาดสิ่งที่ไม่สามารถนำไปใช้ได้

นั่งร้าน "เป็นโครงสร้างชั่วคราวที่ใช้เพื่อช่วยเหลือผู้คนและวัสดุในการก่อสร้างหรือซ่อมแซมอาคารและสิ่งปลูกสร้างขนาดใหญ่อื่น ๆ " ^{[คำนิยามจากวิกิพีเดีย]}

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

ฉันรู้ว่า บริษัท ก่อสร้างบางแห่งที่ฟาร์มทำงานเพื่อผู้เสนอราคาต่ำสุดทำงานเลอะเทอะปัดสิ่งที่ควรจะเป็นหน้าที่การรับประกันมุ่งเน้นไปที่วันที่ที่มีคุณภาพแล้วคิดกำไรไร้สาระสำหรับผลิตภัณฑ์ "เสร็จสิ้น"

แต่ฉันไม่คิดว่าโปรแกรมเมอร์หรือหน่วยงานที่ปรึกษาได้เรียนรู้อะไรจากการปฏิบัติเหล่านั้น

บักอาจจบลงด้วยราคาแพงอย่างนรกหรือแม้แต่ฆ่าผู้คน?

มีแนวทางพื้นฐานสำหรับโครงการวิศวกรรมที่ซับซ้อนของวินัยใด ๆ :

1. ความสำคัญของการวางแผนภาพพิมพ์สีฟ้าการออกแบบ ฯลฯ
2. ความสำคัญของคณิตศาสตร์พื้นฐาน
3. การนำความคิด / การเรียนรู้มาใช้จากโครงการที่คล้ายกันอื่น ๆ
4. ใช้หน่วยการสร้าง / ส่วนประกอบสำเร็จรูปที่สร้างโดยบุคคลอื่น
5. การแก้ไขปัญหาในช่วงต้นของวงจรชีวิต
   ฯลฯ

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

ล่วงเวลา

แต่ในอุตสาหกรรมก่อสร้างคนงานจะได้รับค่าล่วงเวลา

ใช้มาตรฐานแบบแผนและส่วนประกอบที่สร้างไว้ล่วงหน้า คุณไม่น่าจะเจอปัญหาแบบนี้

ฉันไม่พบอะไรในตลาดที่เหมาะกับซ็อกเก็ตที่เราผลิตขึ้นเอง

เมื่อสิ่งที่คุณมีคือค้อนทุกสิ่งดูเหมือนเป็นเล็บ :)

การบาดเจ็บจากความเครียดซ้ำ ๆ

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