ทำไมโปรแกรมเมอร์บางคนคิดว่ามีความแตกต่างระหว่างทฤษฎีและการปฏิบัติ? [ปิด]

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

ในทางตรงกันข้ามการพูดกับการเขียนโปรแกรมบางส่วนหรืออ่านบล็อกหรือฟอรั่ฉันมักจะพบความเห็นในวงกว้างที่สามารถนำสูตรมากหรือน้อยดังต่อไปนี้: ทฤษฎีและวิธีการอย่างเป็นทางการสำหรับนักคณิตศาสตร์ / นักวิทยาศาสตร์ในขณะที่การเขียนโปรแกรมเป็นเรื่องเกี่ยวกับการทำสิ่งต่างๆ

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

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

ดังนั้น IMO (ปริมาณที่เหมาะสมของ) ทฤษฎีเป็นหนึ่งในเครื่องมือสำหรับการทำสิ่งต่างๆ

คำถามของฉันคือทำไมโปรแกรมเมอร์บางคนคิดว่ามีความแตกต่างระหว่างทฤษฎี (วิธีการที่เป็นทางการ) และการฝึกฝน

ซอฟต์แวร์วิศวกรรม (ซอฟท์แวร์อาคาร) ถูกมองว่าเป็นเรื่อง ง่ายเมื่อเทียบกับวิศวกรรมโยธา (บ้านอาคาร)?

หรือทั้งสองสาขาแตกต่างกันจริงๆ (นอกเหนือจากซอฟต์แวร์ที่มีความสำคัญต่อภารกิจแล้วความล้มเหลวของซอฟต์แวร์นั้นเป็นที่ยอมรับได้มากกว่าการสร้างความล้มเหลว)

ฉันพยายามสรุปสิ่งที่ฉันเข้าใจจากคำตอบแล้ว

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

ดังนั้นจึงเป็นการยากที่จะกำหนดว่าการออกแบบ / ทฤษฎีในปริมาณที่เหมาะสมในวิศวกรรมซอฟต์แวร์ (น้อยเกินไป -> รหัสยุ่งมากเกินไป -> ฉันไม่สามารถทำให้เสร็จ) เพราะไม่มีกฎทั่วไปและมีเพียง ประสบการณ์จำนวนมากสามารถช่วยได้

ดังนั้นหากฉันตีความคำตอบของคุณอย่างถูกต้องความไม่แน่นอนนี้เกี่ยวกับว่า จำเป็นต้องใช้ทฤษฎีมากแค่ไหนก็มีส่วนทำให้ความรัก / ความรู้สึกเกลียดชังที่ผู้เขียนโปรแกรมบางคนมีต่อทฤษฎี

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

โปรแกรมเมอร์จำนวนมากมีประสบการณ์ที่ไม่ดีกับทฤษฎีที่หลบหนีกลายเป็นอุปสรรคในการทำให้สิ่งต่าง ๆ เสร็จสิ้น (เช่น "ปฏิบัติการ UML" กระบวนการพัฒนาระบบราชการขั้นสูง) ในทางกลับกันการแฮ็กและแพทช์สกปรกสามารถทำให้คุณสวยได้ และตามที่คุณสังเกตในย่อหน้าสุดท้ายของคุณ: ความล้มเหลวมักจะไม่เป็นขั้นสุดท้ายและไม่เป็นปัญหา

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

การพัฒนาซอฟต์แวร์เป็นการออกแบบทั้งหมดสิ่งประดิษฐ์ที่ได้รับการออกแบบนั้นมีขนาดที่ซับซ้อนกว่าบทความที่ผลิตขึ้นมาและแต่ละชิ้นก็มีเอกลักษณ์

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

ในด้านวิศวกรรมแบบดั้งเดิม

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

มี "ฟิสิกส์" ที่ใช้กับซอฟต์แวร์ - ทฤษฎีข้อมูล แต่วิศวกรซอฟต์แวร์ได้รับความรู้เล็กน้อยและไม่มีอะไรที่แน่นอนเลย ทฤษฎีส่วนใหญ่ที่พวกเขาได้รับคือความสามารถในการคำนวณและ big-O

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

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

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

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

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

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

อดทนกับฉันในอันนี้ ฉันมีประเด็น

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

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

ฉันเป็นคนที่น่าสงสารและโชคร้ายและมีพวกคุณหลายคน ฉันขอร้องพวกคุณทุกคน อย่าใช้วิธีง่าย ๆ ออกไป! :)

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

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

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

นอกจากนี้ฉันจะชี้ให้เห็นนอกเหนือจากการตอบสนองที่ยอดเยี่ยมอื่น ๆ อีกมากมายที่มนุษยชาติกำลังทำเทียบเท่ากับ "วิศวกรรมโยธา" เนื่องจากเป็นช่วงเวลาของชาวอียิปต์อย่างง่ายดายดังนั้นเราจึงมีเวลามากที่จะทำให้ทฤษฎีทั่วไปสมบูรณ์แบบ เสร็จแล้ว เราสร้างซอฟต์แวร์มานานกว่า 70 ปีแล้ว (ขึ้นอยู่กับสิ่งที่คุณพิจารณาว่าเป็น "ซอฟต์แวร์" ตัวแรก); ฉันหมายความว่าเราไม่ได้มีเวลาเท่ากันในการพัฒนาประสบการณ์แบบเดียวกัน

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

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

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

ความแตกต่างเป็นหลักเนื่องจากข้อกำหนดที่ทราบ:

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

นอกจากนี้เมื่อพูดถึง "ทฤษฎี" มันมักจะหมายถึงด้านทฤษฎีของวิทยาศาสตร์คอมพิวเตอร์มากกว่าวิศวกรรมซอฟต์แวร์ นี่คือส่วนหนึ่งของวิทยาศาสตร์คอมพิวเตอร์ที่ส่วนใหญ่เกี่ยวกับการค้นหาอัลกอริทึมที่ดีขึ้นและมีประสิทธิภาพมากขึ้นพิสูจน์ว่ามีอะไรบางอย่างหรือเป็นไปไม่ได้ (เช่น P และ NP เป็นต้น) และอื่น ๆ ในขณะที่มันดีที่จะมีสิ่งเหล่านี้อยู่ในใจของคุณพวกเขาไม่ได้เกิดขึ้นในการพัฒนาซอฟต์แวร์บ่อยนัก

เราใช้ห้องสมุดสำหรับสิ่งนั้นมากที่สุด

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

NASA ต้องการซอฟต์แวร์เพื่อควบคุมกระสวยอวกาศในอวกาศดังนั้นระดับกระบวนการทางวิศวกรรมนั้นเข้มงวดกว่าการสร้างเว็บไซต์เพื่อแสดงภาพของจรวด

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

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

แม้แต่วิศวกรโยธาก็รู้ว่าไม่ว่าพวกเขาจะวางทฤษฏีการออกแบบอะไรสักอย่างในที่สุดก็จะทำลายมันดังนั้นพวกเขาจึงจำเป็นต้องพัฒนาแผนฉุกเฉิน

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

เพื่อสรุปPremature optimization is the root of all evil หรือตามที่หัวหน้าของฉันมักจะพูดShipping is a feature!

คำตอบที่ดีมากมายที่นี่ แต่ฉันคิดว่าการเปรียบเทียบระหว่างวิทยาศาสตร์คอมพิวเตอร์และวิศวกรรมโยธามีข้อบกพร่อง

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

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

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

TL; DR : ทฤษฎีและการปฏิบัติมีความแตกต่างในวิศวกรรมซอฟต์แวร์เหมือนกับที่อื่น ๆ การเปรียบเทียบที่เหมาะสมคือวิศวกรรมซอฟต์แวร์: วิศวกรรมโยธา :: วิทยาการคอมพิวเตอร์: ฟิสิกส์ แต่ในทางปฏิบัติมันซับซ้อนกว่านี้เล็กน้อย :)

ดังนั้นคำถามของฉันคือทำไมโปรแกรมเมอร์บางคนคิดว่ามีความแตกต่างระหว่างทฤษฎี (วิธีการที่เป็นทางการ) และการฝึกฝน (ทำสิ่งต่าง ๆ ให้เสร็จสิ้น)?

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

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

ซอฟต์แวร์วิศวกรรม (ซอฟท์แวร์อาคาร) ถูกมองว่าเป็นเรื่องง่ายเมื่อเทียบกับวิศวกรรมโยธา (บ้านอาคาร)?

ฉันไม่แน่ใจว่า "ง่าย" เป็นคำที่ถูกต้อง การขาดหลักฐานที่เป็นรูปธรรมสามารถนำไปสู่การรับรู้ว่าไม่มีการทำงานใด ๆ หรือในทำนองเดียวกันงานที่มีอยู่นั้นสามารถเปลี่ยนแปลงได้ง่าย

หรือทั้งสองสาขาแตกต่างกันจริงๆ (นอกเหนือจากซอฟต์แวร์ที่มีความสำคัญต่อภารกิจแล้วความล้มเหลวของซอฟต์แวร์นั้นเป็นที่ยอมรับได้มากกว่าการสร้างความล้มเหลว)

วิศวกรรมแบบดั้งเดิมและวิศวกรรมซอฟต์แวร์นั้นแตกต่างกันอย่างมากด้วยเหตุผลที่ฉันได้กล่าวไปแล้ว

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

ประสบการณ์ของคุณสอดคล้องกับสิ่งที่คนส่วนใหญ่ที่ฉันรู้จัก (ผู้ออกแบบและเขียนซอฟต์แวร์ที่ซับซ้อนเพียงพอ) จะพูด

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

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

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

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

ดูเหมือนกันสำหรับฉัน คุณสร้างอาคารขนาดใหญ่จากบล็อกมาตรฐานคอนกรีตความแข็งแรงมาตรฐานเหล็กมาตรฐาน คุณสร้างแอปขนาดใหญ่จากไลบรารีมาตรฐาน

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

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

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

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

ไม่มีข้อโต้แย้ง - มีโครงการที่ต้องเริ่มด้วยคณะกรรมการซอฟต์แวร์สถาปนิก 17 คน ในความเป็นจริงเพชรมีน้ำหนักประมาณ 20 กะรัต

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ก่อนอื่นฉันรักคำถามนี้ ฉันเขียนเหมือนคำตอบ 1,000 คำสามคำและพวกเขาทั้งหมดผิดอย่างผิดพลาดเมื่อฉันถึงจุดสิ้นสุด

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

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

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

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

เห็นได้ชัดว่าคุณไม่สามารถใช้รูปแบบที่ได้รับความนิยมและได้รับการยอมรับอย่างดีเช่น MVC เพื่อจัดการข้อกังวลส่วนหน้าบนเว็บโดยเฉพาะโดยไม่ต้องเปลี่ยนวิธีที่คุณจัดการกับมันในบริบทแอพเดสก์ท็อป ในความเป็นจริงฉันจะโต้แย้งคุณควรตระหนักถึงสิ่งที่ทำให้ MVC มีประโยชน์ แต่ไม่ได้พยายามที่จะใช้มันในลักษณะที่เข้มงวดหรือขายส่ง กระบวนทัศน์ของแอปพลิเคชันเว็บมีความโดดเด่นในทุกสิ่งที่ look-me-me ได้รับการจัดการโดยเบราว์เซอร์ของผู้ใช้และข้อมูล / model-ish ทั้งหมดมักจะอยู่ในเซิร์ฟเวอร์ แต่นั่นจะออกจากตัวควบคุมที่ไหน? ทั้งหมดบนเซิร์ฟเวอร์หรือทั้งหมดที่ส่วนหน้า? ใครบางคนต้องเป็นเจ้าของนั้น หรืออาจ MVC ไม่ใช่แบบที่ดีที่สุดสำหรับสถานการณ์ ไม่ใช่สิ่งที่ไม่ดีสำหรับ. NET back end ไม่น่ากลัวในบริบทของวิดเจ็ต UI เฉพาะ

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

Glenn Vanderburg นำเสนอมุมมองที่ยอดเยี่ยมเกี่ยวกับความแตกต่างระหว่างวิศวกรรมซอฟต์แวร์และสาขาวิชาวิศวกรรมแบบดั้งเดิมมากขึ้น: http://www.youtube.com/watch?v=NP9AIUT9nos

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

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

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