ในช่วง 20 ปีที่ผ่านมาไม่เคยมีสิ่งใดที่ให้ผลกำไรจากการพัฒนาซอฟต์แวร์จำนวนมากหรือไม่? [ปิด]

ในNo Silver Bullet Fred Brooks สร้างการคาดการณ์ที่หลากหลายเกี่ยวกับอนาคตของวิศวกรรมซอฟต์แวร์โดยสรุปได้ดีที่สุดจาก:

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

เหตุผลของเขาน่าเชื่อถือมาก Brooks เขียนในปี 1986: เขาพูดถูกมั้ย นักพัฒนาซอฟต์แวร์ในปี 2014 ผลิตซอฟต์แวร์ในอัตราที่น้อยกว่า 10 เท่าเร็วกว่าในปี 1986 หรือไม่? โดยการวัดที่เหมาะสม - การเพิ่มผลผลิตมีขนาดใหญ่แค่ไหน?

นักพัฒนาซอฟต์แวร์ในปี 2014 ผลิตซอฟต์แวร์ในอัตราที่น้อยกว่า 10 เท่าเร็วกว่าในปี 1986 หรือไม่?

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

การเพิ่มผลิตภาพเกิดขึ้นจากการผสมผสานของปัจจัยต่างๆ หมายเหตุ: นี่ไม่ใช่รายการที่ครอบคลุม:

1. คอมไพเลอร์ที่ดีขึ้น
2. คอมพิวเตอร์ที่ทรงพลังยิ่งกว่ามาก
3. Intellisense
4. การวางแนววัตถุ
5. การวางแนวการทำงาน
6. เทคนิคการจัดการหน่วยความจำที่ดีขึ้น
7. การตรวจสอบขอบเขต
8. การวิเคราะห์รหัสคงที่
9. การพิมพ์ที่แข็งแกร่ง
10. การทดสอบหน่วย
11. การออกแบบภาษาโปรแกรมที่ดีขึ้น
12. การสร้างรหัส
13. ระบบควบคุมซอร์สโค้ด
14. ใช้รหัสซ้ำ

และอื่น ๆ เทคนิคเหล่านี้ทั้งหมดรวมกันเพื่อให้ได้ผลผลิตเพิ่มขึ้น ไม่มีกระสุนเงินเดียวที่เคยผลิตเพื่อเพิ่มความเร็ว

โปรดทราบว่าเทคนิคเหล่านี้บางอย่างมีมาตั้งแต่อายุหกสิบเศษ แต่เพิ่งสังเกตเห็นการยอมรับและการยอมรับอย่างกว้างขวางเมื่อเร็ว ๆ นี้

คำตอบของ Robert Harvey นั้นดี แต่ฉันคิดว่าเขาละทิ้งสิ่งที่อาจเป็นสาเหตุที่ใหญ่ที่สุดที่โปรแกรมเมอร์เขียนโปรแกรมทำงานได้มากกว่าที่เคยมีมา: ห้องสมุดซอฟต์แวร์ที่มีอยู่อย่างกว้างขวาง

เมื่อฉันเริ่มต้นอาชีพของฉันไม่มี STL, .NET, QT ฯลฯ คุณมี raw C หรือ C ++ และนั่นก็เกี่ยวกับมัน

สิ่งต่าง ๆ ที่ใช้ในการใช้เวลาเป็นวันหรือสัปดาห์หรือการทำงาน (การแยกวิเคราะห์ XML, การเชื่อมต่อ TCP / IP, การสื่อสาร HTTP) สามารถทำได้ด้วยบรรทัดของโค้ด C # จำนวนหนึ่ง นี่คือที่เราได้รับคำสั่งขนาดที่ดีขึ้นในแง่ของผลผลิตโดยรวมของนักพัฒนา

ผลิตภัณฑ์ปัจจุบันของเราใช้กรอบหน้าต่างเชื่อมต่อที่เราซื้อจากผู้จำหน่าย สิ่งนี้ทำให้ฉันมี UI เชื่อมต่อหน้าต่างที่ทำงานได้อย่างสมบูรณ์ในเวลาไม่กี่นาที ฉันครุ่นคิดถึงสิ่งที่จะต้องทำในวันที่ใช้ win32 API

เพื่อประโยชน์ของการโต้แย้งผมไม่เห็นด้วยกับการยืนยันของเฟร็ดบรูคส์

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

ความสามารถในการค้นหาคำตอบสำหรับเกือบทุกปัญหาที่คุณพบได้ทันทีในฐานะผู้พัฒนาทำให้สามารถเพิ่มประสิทธิภาพได้อย่างมาก ไม่ทราบวิธีการเลือกองค์ประกอบที่ n ใน JQuery? นำไปสู่การค้นหาของ Google เพื่อคำตอบของคำถามที่ถูกต้องในกองมากเกิน ไม่ทราบวิธีใช้overflowใน CSS ใช่ไหม ของ Mozilla MDN อยู่ที่นี่ ลืมvirtualคำหลักที่มีความหมายใน C #? Google ช่วยได้อีกครั้ง

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

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

• บนกองซ้อนล้นอย่างเห็นได้ชัด ตัวอย่างเช่นฉันไม่ได้เห็นหนังสือเล่มใดที่กล่าวถึงปัญหานี้

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

• ในรายงานบั๊กเกี่ยวกับซอฟต์แวร์โอเพนซอร์ซ ตัวอย่างเช่นมันมีประโยชน์มากเมื่อเร็ว ๆ นี้เมื่อฉันพยายามใช้ MAAS ของ Ubuntu และเมื่อฉันใช้ PXE คุณไม่พบข้อมูลประเภทนี้ในหนังสือเช่นกัน

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

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

• มันจะเป็นประโยชน์ในระหว่างขั้นตอนการทดสอบและการใช้งานเมื่อเกิดปัญหาจริง

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

มันจะช่วยเพิ่มประสิทธิผลในการทำงาน x10 หรือไม่? ยากที่จะบอก

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

• ในทางกลับกันผลผลิตโดยรวมดีขึ้นตามปัจจัยหลายอย่างเช่นการจัดการโครงการที่ดีขึ้น (Agile, TDD และอื่น ๆ ), การจัดการทีมที่ดีขึ้น ( Radical Managementโดย Stephen Denning มาถึงใจ) เครื่องมือที่ดีกว่า (debuggers, profilers , IDEs, ฯลฯ ), ฮาร์ดแวร์ที่ดีกว่า (ไม่ฉันจะไม่ได้ผลมากถ้าถูกบังคับให้เขียนใน Assembler สำหรับ CPU ที่ช้าและ RAM ที่ จำกัด มาก) เป็นต้น

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

ฉันขอแนะนำว่าแนวโน้มที่ดึงเราไปในทิศทางอื่น (เช่นไปสู่การลดผลิตผล) อย่างน้อยก็แข็งแกร่งเท่ากับแนวโน้มที่คุณถาม ประสบการณ์การใช้เครื่องมือพัฒนาไคลเอนต์ / เซิร์ฟเวอร์เช่น VB6 หรือ PowerBuilder นั้นค่อนข้างใกล้เคียงกับอุดมคติของ "Rapid Application Development" (RAD) คุณต้องวาดแบบฟอร์มของคุณและมี hooks ชัดเจนสำหรับขั้นตอนหรือรหัส SQL ของคุณ

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

การเปลี่ยนไปใช้การพัฒนาเว็บที่ใช้ไคลเอนต์เป็นอย่างมากนั้นเป็นอีกหนึ่งประสบการณ์ที่น่าประทับใจ Microsoft กำลังกลับไปสู่ ​​RAD ในอุดมคติด้วย WebForms แล้วมันก็ตกหลุมรักอย่างรวดเร็ว ผู้พัฒนาคาดหวังว่าจะใช้โครงสร้างพื้นฐานที่ไม่เหมาะสม (เช่น XMLHttpRequest ซึ่งไม่ค่อยได้ใช้สำหรับ XML) และไม่เช่นนั้นจะมีลิงอยู่ในระดับที่ต่ำกว่าความเป็นนามธรรมในความพยายามที่จะทำให้เว็บไซต์โต้ตอบได้มากขึ้น

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

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

เทคโนโลยีก้าวหน้าไปมากและตอนนี้เรามีทุกสิ่งที่ Robert Harvey แจกแจงในคำตอบของเขา แต่:

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

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

• รหัสยังคงมีความซับซ้อนสูงและความซับซ้อนนั้นดูเหมือนจะไม่ลดลงเมื่อใช้เทคโนโลยีใหม่

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

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

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

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

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

ในขณะที่บางคนอาจโต้เถียงกับตัวชี้วัดที่เฉพาะเจาะจง (เช่นมีสิ่งที่ดีขึ้นโดยปัจจัยที่ 9.98?) ฉัน (พูดเป็นสิ่งจับเวลาเก่า) ต้องเห็นด้วยกับความเชื่อมั่นทั่วไปของความคิดเห็น Brooks

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

เทคโนโลยีคอมไพเลอร์ได้รับอนุญาตเกี่ยวกับการปรับปรุง 10 เท่าในโปรแกรมเมอร์ "ผลิตภาพ" เทียบกับปี 1970 เมื่อฟังก์ชั่นตัวเลขหนึ่งที่ผลิตหารด้วยเวลาการเข้ารหัสที่เกิดขึ้นจริง แต่การแพร่กระจายของภาษาการเขียนโปรแกรมและสภาพแวดล้อมใหม่ เวลาในโหมด "ติดตาม" และกิจกรรมการผลิตน้อยลง Apple, Google และ Microsoft ต่างก็พ่น "การอัพเกรด" ใหม่และเข้ากันไม่ได้อย่างมีนัยสำคัญกับสภาพแวดล้อมของพวกเขาในอัตราที่ต่ำกว่าที่จะกระตุ้นให้เกิดการประท้วงในหมู่ผู้ใช้บริการ ... ในทำนองเดียวกัน HTML / CSS / Javascript / อะไรก็ตามที่ซับซ้อนขึ้นเรื่อย ๆ

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

เพิ่ม: ฉันได้รับการคิดเกี่ยวกับเรื่องนี้ตั้งแต่เมื่อวานและโดยเฉพาะอย่างยิ่งการคิดเกี่ยวกับโครงการที่ฉันทำงานจากประมาณปี 1978 จนถึงปี 2008 โครงการนี้ (IBM System / 38 และผู้สืบทอดของมัน) ค่อนข้างไม่เหมือนใครในความพยายามเริ่มต้น สร้างขึ้นเพื่อควบคุมความซับซ้อนของมัน (หนึ่งคือการแบ่งซอฟต์แวร์ออกเป็นสองส่วนเท่า ๆ กันโดยมีส่วนต่อประสาน "เครื่องจักร" ระหว่างกัน) ในบางพื้นที่ที่ฉันทำงานเพื่อนร่วมงานหลายคนของฉันก็ทุ่มเทในการควบคุมความซับซ้อนเช่นเดียวกัน (แม้ว่าเราจะไม่ได้ใช้คำนั้นมากในเวลานั้น) ผลที่ได้คือผลิตภัณฑ์ที่ (ตอนแรก) ค่อนข้างแข็งแกร่งและ "โดน" กับลูกค้าค่อนข้างมากจาก git-go และมันเป็นความสุขที่ได้ทำงานเหมือนเล่นในวงออร์เคสตราที่ผ่านการฝึกฝนมาเป็นอย่างดี

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

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

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

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