ทีมพัฒนาซอฟต์แวร์มืออาชีพจัดการกับความซับซ้อนของการออกแบบในโครงการที่ไม่สำคัญได้อย่างไร

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

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

ตอนนี้ฉันพบว่าตัวเองเป็นผู้นำในทีม แต่ไม่ได้อยู่ในสภาพแวดล้อมขององค์กร - ฉันทำงานให้กับมหาวิทยาลัยในการพัฒนาซอฟต์แวร์ทางวิทยาศาสตร์ (ใน C ++) สำหรับการใช้งานด้านวิศวกรรม ทันใดนั้นโครงการก็กำลังโต (ค่อนข้างใหญ่) และฉันก็มีปัญหาในการใช้เวลาส่วนใหญ่ ฉันเสียเวลาและความพยายามอย่างมากในสองสิ่งส่วนใหญ่:

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

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

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

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

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

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

ลองนึกภาพว่าคนจนที่มาหลังจากคุณรู้สึกอย่างไร - เขาไม่ได้รับประโยชน์แม้แต่ครั้งเดียวที่รู้ว่ารหัสของคุณทำงานอย่างไร แทนที่จะพยายามถอดรหัสรหัสของคุณคุณควรตรวจสอบเอกสารที่คุณเขียนสำหรับโมดูลที่เป็นปัญหา เอกสารนั้นควรเสนอมุมมองที่ถูกต้องอย่างสมเหตุสมผลว่าโมดูลทำอะไรเพราะอะไร ไม่ใช่ "โมดูลเริ่มต้นด้วยการเริ่มต้นสามอาร์เรย์โดยใช้ triple for loop ... " แต่แทน: "โมดูลนี้ดึงข้อมูลที่รวบรวมโดยเซ็นเซอร์หลักของ Fabulotron จัดเรียงใหม่ในรูปแบบมาตรฐาน Neopolitan (ช็อคโกแลตวานิลลาสตรอเบอร์รี่) และส่งไปยังโมดูลการวิเคราะห์ "

ในโลกที่สมบูรณ์แบบคุณจะมีเอกสารการออกแบบที่กำหนดโมดูลต่าง ๆ ในระบบและอธิบายความรับผิดชอบของแต่ละโมดูลและแต่ละโมดูลของคุณสามารถอ้างอิงกลับไปที่เอกสารนั้นเพื่ออธิบายสิ่งที่พวกเขาทำ: "โมดูลนี้ให้ บริการรวบรวมข้อมูลของ Fabulotron ดังรายละเอียดในส่วนที่ 4.8 ของเอกสารการออกแบบ: http://fabulotron.org/design/section4-8.html " หากคุณไม่มีอะไรเช่นนั้นให้เริ่มเขียนภาพรวมของแต่ละโมดูลขณะที่คุณทำงาน คุณไม่จำเป็นต้องเขียนหนังสือสักสองสามย่อหน้าก็เพียงพอแล้วที่จะให้ความสำคัญกับคุณ

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

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

ฉันหวังว่าจะมี "แผนภาพสถาปัตยกรรม" ที่ฉันสามารถดูว่าสิ่งต่าง ๆ เกิดขึ้นได้อย่างไร

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

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

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

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

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

ประเด็นสำคัญของฉันคือการทดสอบและทำความสะอาดรหัส

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

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

เป็นเวลานานแล้วที่ฉันได้ทำงานกับซอฟต์แวร์วิศวกรรมดังนั้นระยะของคุณอาจแตกต่างกันไปตามคำแนะนำเหล่านี้ โชคดี!

คำตอบคือวิศวกรรมซอฟต์แวร์

นั่นคือสำหรับโครงการขนาดใหญ่ที่คุณทำตามลำดับชุดของการรวบรวมข้อกำหนดการกำหนดกระบวนการข้อกำหนด ฯลฯ นานก่อนที่จะมีการเข้ารหัสจริง

มีวิธีการต่างๆที่ใช้ขึ้นอยู่กับสภาพแวดล้อมและวัฒนธรรม ประเภทธุรกิจขององค์กรมีแนวโน้มที่จะทำตาม " Rational Unified Process " หรือคล้ายกันอัพเริ่มต้นของเทคโนโลยีมักจะมีการเปลี่ยนแปลงในAgileแผนกของรัฐบาลบางแห่งใช้วิธี น้ำตกที่ทำงานหนักเกินไป

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

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

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

โชคดี!

ฉันเชื่อว่าปัญหาของคุณมีสามมิติ

1. โปรแกรมเมอร์-Oriented
2. โปรแกรมเชิง
3. การบำรุงรักษาโปรแกรม - ที่มุ่งเน้น

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

ในกรณีที่มีปัญหาจากโปรแกรมเป็นศูนย์กลางคำแนะนำที่ชั่วร้ายข้อหนึ่งของฉันคือการย้ายไปสู่ระดับที่สูงขึ้นของนามธรรมมากกว่า C ++ เช่นการเรียนรู้ภาษาใหม่เช่น Python หรือ Haskell (Python ค่อนข้างง่ายต่อการเรียนรู้และถ้าคุณมีนักคณิตศาสตร์ที่ดี Haskell เยี่ยมมาก) การย้ายไปสู่ระดับที่สูงขึ้นของสิ่งที่เป็นนามธรรมจะทำให้ขนาดรหัสของคุณลดลงง่ายต่อการเข้าใจและบำรุงรักษาในระยะยาวและการเปลี่ยนแปลงอย่างรวดเร็ว ดังนั้นคุณสามารถมีรหัส 10 บรรทัดแทนที่รหัส 50 บรรทัดต้นฉบับ นอกจากนี้การมีคนที่มีความเชี่ยวชาญในการเขียนโปรแกรมคอมพิวเตอร์จะช่วยได้แน่นอน เมื่ออยู่ในมหาวิทยาลัยคุณอาจมีส่วนร่วมกับนักเรียนไม่กี่คนใน GUI และอินเทอร์เฟซเพื่อให้คุณมีสมาธิมากขึ้นในการทำงาน ฉันยังแนะนำหนังสือออกแบบซอฟต์แวร์ C ++ ขนาดใหญ่โดย John Lakos(มันค่อนข้างเป็นหนังสือเล่มใหญ่คุณสามารถเป็น Python โปรแกรมเมอร์ที่เชี่ยวชาญในเวลาที่คุณอาจเอาไปอ่านหนังสือ)

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

• ฟรี Mind - ซอฟต์แวร์ทำแผนที่ความคิด
• Trac - โปรแกรมบั๊กซอฟต์แวร์ที่ง่ายและรวดเร็วและ wiki
• MoinMoin - วิกิด่วนเพื่อเปิดใช้งานการแบ่งปันความรู้เกี่ยวกับโปรแกรม

แม้ว่าเคล็ดลับข้างต้นจะทำให้เกิดการเรียนรู้ที่คุ้มค่าในระยะยาว และสุดท้ายการเขียนโปรแกรมก็ง่ายกว่า Photonic Engineering (ไม่ใช่การเขียนโปรแกรม C ++)

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

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