วิธีการพัฒนาควรกำจัดความเป็นปัจเจกของนักพัฒนาหรือไม่?

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

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

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

คุณถามผู้สอนว่าทำไมคุณต้องเขียนรายการวิธีการทั้งหมด

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

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

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

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

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

คุณพบข้อบกพร่องของน้ำตกใช่ แต่ทุกอย่างมีจุดแข็งและจุดอ่อน

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

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

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

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

นี่คือจุดที่ถูกต้องทั้งหมด

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

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

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

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

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

นอกจากนี้ฉันอาจไม่คิดว่าทุกฟังก์ชั่นเล็ก ๆ เมื่อออกแบบโปรแกรมพวกเขาอาจมาพร้อมกับการปรับโครงสร้าง

ดังนั้น?

ผู้สอนบอกเราผิดโดยขอให้เราทำรายการทุกฟังก์ชั่นหรือไม่?

ไม่มันเป็นข้อกำหนดทั่วไป

และวิธีการออกแบบเหล่านี้ทำให้นักออกแบบของนักออกแบบ (นักพัฒนา) ใช้วิธีการเขียนโค้ดเพื่อให้เข้าใจได้ดีที่สุดหรือไม่?

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

เลขที่คุณเพิ่งจะสะดุดกับความน่าเบื่อ เอาชนะมันและกลับไปทำงาน

การเขียนโปรแกรมเป็นศิลปะของการทำงานภายใต้ข้อ จำกัด CPU มีชุดคำสั่งที่ จำกัด IO ถูก จำกัด ด้วยการออกแบบของฮาร์ดแวร์ OS API ถูกสร้างขึ้นเพื่อส่งเสริมพฤติกรรมบางอย่างและ จำกัด ผู้อื่น ภาษาระดับสูงมักได้รับการออกแบบมาเพื่อส่งเสริมสำนวนหนึ่งชุดเหนือภาษาอื่น ...

และวิธีการก็ถูกสร้างขึ้นมาเพื่อ จำกัด

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

คุณจริงๆคิดปรารถนาอาจารย์ของคุณจะอ่านผ่านหน้าไม่มีที่สิ้นสุดของ minutia? จากนั้นทดสอบทฤษฎีนั้น: เลิกโปรแกรมและบันทึกแต่ละอะตอม เมื่อโต๊ะทำงานของเขาหย่อนคล้อยใต้น้ำหนักฉันค่อนข้างจะสงสัยว่าคุณจะพบว่าความปรารถนาที่แท้จริงของเขานั้นค่อนข้างแตกต่างจากที่คุณคาดไว้

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

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

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

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

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

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

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

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

ผู้สอน "บอกคุณผิด" หรือไม่?

ฉันคิดอย่างนั้น

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