หากมีคนเสนอข้อความที่ไม่ได้รับการยืนยันเกี่ยวกับแนวทางการพัฒนาซอฟต์แวร์คุณตอบกลับด้วย "การอ้างอิงที่จำเป็น" หรือไม่? [ปิด]

เมื่อเร็ว ๆ นี้ฉันเข้าร่วมบรรยายโดยGreg Wilson (หัวหน้านักวิทยาศาสตร์ของ Software Carpentry) จากนามธรรม:

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

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

วางไว้โผงผางฉันถูกใจง่าย

นี่คือตัวอย่างที่นำมาจากการบรรยาย:

"หากรหัสมากกว่า 25% ต้องการการปรับโครงสร้างใหม่จะสามารถเขียนได้เร็วขึ้น"

ฟังดูน่าเชื่อถือ แต่จริงหรือ? การศึกษาสำรองอยู่ที่ไหน จริงหรือไม่สำหรับทุกภาษา? และอื่น ๆ

ตกลงเป็นไปได้ค่อนข้างมากที่จะนำสิ่งนี้ไปสู่สุดโต่งและไม่เชื่ออะไรโดยใครนอกจากคุณจะได้รับมาจากหลักการแรก ด้วยวิธีนี้คือความบ้าคลั่ง (หรืออาจเป็นคณิตศาสตร์ ;-)) แต่ถ้ามีใครบางคนเข้ามาหาคุณพร้อมกับแถลงการณ์ตามบรรทัดของ "เฮ้การทำสิ่งนี้ใน [เลือกภาษาของช่วงเวลา] เราจะสามารถเพิ่มประสิทธิภาพการทำงานโดย [เลือกหลาย 10]%" คุณมีแนวโน้มที่จะเพียงแค่ ยอมรับหรือคุณจะขอหลักฐานที่พิสูจน์แล้ว?

ถ้าเป็นแบบหลัง (และฉันหวังว่าจะเป็น)

1. คุณจะไปหาหลักฐานนี้จากที่ไหน
2. คุณจะเข้มงวดแค่ไหน

กล่าวโดยย่อหากมีคนเสนอข้อความที่ไม่ผ่านการยืนยันคุณจะตอบกลับด้วย

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

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

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

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

หากมีคนบอกคุณว่า "หากรหัสมากกว่า 2% ต้องการการเปลี่ยนรหัสใหม่มันเร็วกว่าที่จะเขียนใหม่" คุณจะรู้ว่ามันเป็นเท็จได้มากเท่ากับที่มีคนบอกคุณว่า "ถ้ามากกว่า 98% ของรหัสนั้นจำเป็นต้องทำการเปลี่ยนใหม่ เขียนมันเร็วกว่า ". ในกรณีที่จำนวนจริงขึ้นอยู่กับสิ่งที่คุณกำลังทำและรหัสที่เหมาะสมในปัจจุบันคือไกลแค่ไหน

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

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

ไม่ฉันโพสต์ไว้ที่นี่และดูว่าได้รับ upvotes หรือไม่ หลักฐานทางสังคมดีกว่าไม่มีข้อพิสูจน์!

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

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

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

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

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

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

ตัวอย่างจากการบรรยายคือการเรียนรู้แบบ Heuristic กฎของหัวแม่มือและไม่มีอะไรเพิ่มเติม นั่นควรจะชัดเจนโดยปริยาย

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

นั่นหมายความว่าพวกเขาไม่มีค่าใช่หรือไม่ ฉันจะไม่พูดอย่างนั้น

ฮิวริสติกส์เป็นหนึ่งในแนวทางที่เราสามารถนำไปสู่การแก้ปัญหา NP-complete และในหลาย ๆ ด้านวิศวกรรมซอฟต์แวร์เป็นปัญหา NP-Complete

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

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

ในอีกด้านหนึ่งเมื่อผู้ขายอ้างว่า IDE ใหม่บางตัวมีประสิทธิภาพมากกว่า 50% ปฏิกิริยาแรกของฉันคือ bull $% ^ &!

นั่นไม่ใช่สิ่งที่ขึ้นอยู่กับตัวแปรที่จับต้องไม่ได้มากมาย (ตัวแปรที่ไม่มีวิธีการวัดทางวิทยาศาสตร์)

ในความคิดของฉันพวกเขากำลังพูดถึงวิธีการเชิงประจักษ์ในการวัดอารมณ์ สิ่งที่แม้แต่สป็อคก็ไม่สามารถทำได้ =)