มีประโยชน์ในการรวบรวมรหัสของคุณตามที่คุณไป?

ฉันเพิ่งได้สัมภาษณ์งานซึ่งพวกเขาให้เวลาฉันหนึ่งชั่วโมงในการเขียนรหัสจริง มันไม่ได้เป็นจำนวนมากอาจน้อยกว่า 100 บรรทัด หลังจากนั้นประมาณ 45 นาทีฉันก็รวบรวมวิ่งแล้วก็ไปทำงาน ฉันอาจใช้เวลา 5-10 นาทีในการรวบรวมข้อผิดพลาดและข้อผิดพลาดเล็กน้อย แต่โดยรวมแล้วมันราบรื่นมาก (บังเอิญฉันได้รับข้อเสนอจากพวกเขา)

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

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

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

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

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

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

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

มีประโยชน์จริงๆหรือไม่ในการรวบรวมเมื่อคุณไปด้วย?

นั่นคือ มันให้ความคิดเห็นย้อนกลับที่สั้นลงซึ่งโดยทั่วไปเมื่อออกแบบ (UI, การเขียนซอฟต์แวร์, การออกแบบภาพ ฯลฯ ... ) เป็นสิ่งที่ดี

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

หากต้องการยืมตัวอย่างของคุณสมมติว่าคุณเขียนโปรแกรมด้วยภาษา C และลืม}บางโปรแกรมที่อยู่ตรงกลางของโปรแกรม

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

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

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

รวบรวมเป็นรูปแบบของการทดสอบโดยเฉพาะอย่างยิ่งในภาษาซึ่งทำให้การใช้งานที่กว้างขวางของประเภทเช่นHaskellหรือML ในภาษาอื่น ๆ เป็นการสแกนวากยสัมพันธ์ที่จะบอกคุณน้อย

ต้องบอกว่า "รวบรวมตามที่คุณไป" ดูเหมือนว่าฉันเป็นนิสัยสถานการณ์ คุณอาจถูกตราหน้าว่าเป็น "กระตุก" อย่างเท่าเทียมกันในการรวบรวมบ่อยกว่าอคติส่วนตัวของผู้สัมภาษณ์ ดูเหมือนว่า nitpicking ไม่มีใครชอบที่จะยอมรับว่าผีตายโหงได้acedทดสอบ; เคล็ดลับเกล็ดของการเจรจาต่อรองเงินเดือน

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

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

ดังนั้นคำถามของฉันคือ: มีสิ่งที่ฉันพลาดหรือไม่?

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

รวบรวมฐานรหัส (ทั้งหมดในเวลาเดียวกัน) เป็นครั้งแรก (คิดว่า "โครงการที่มี 20 ไฟล์") จะบังคับให้คุณเปลี่ยนบริบทจากสิ่งที่คุณกำลังคิด (เช่น "ค่านี้ถูกตั้งค่าเป็น 5 ที่นี่จากนั้นใน for loop blablabla และอัลกอริธึมที่ซับซ้อนให้ค่าที่ถูกต้องในการส่งคืน ") กับปัญหาการคอมไพล์ที่ไม่เกี่ยวข้องกับสิ่งที่คุณกำลังคิดอย่างสมบูรณ์ (ชื่อไฟล์ / โมดูล / ฟังก์ชัน / pre-conditions / syntax / ตัวแปรที่แตกต่างกัน) )

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

มีประโยชน์จริงๆหรือไม่ในการรวบรวมเมื่อคุณไปด้วย?

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

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

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

มันแพร่กระจายโดยชุมชนซอฟต์แวร์เช่นกัน แต่ก็มีเหตุผลที่ดีอยู่เบื้องหลัง

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

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

ฉันจะจินตนาการว่าคนที่ inteviewed คุณได้ข้อสรุปที่คล้ายกัน ("คุณไม่ค่อยมีประสบการณ์ในฐานรหัสขนาดใหญ่")

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

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

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

หากคุณไม่ได้เป็นแฟนของการรวบรวมซ้ำอย่างต่อเนื่องคุณอยู่ใน บริษัท ที่ดี นี่คือ Donald Knuth:

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

จากที่กล่าวมาทั้งหมด ... หากคุณกำลังทำงานในบริบทที่การคอมไพล์เป็นการกระทำที่ฟรีทำไมคุณไม่ทำล่ะ ที่บ้านในโครงการส่วนตัวฉันกด ctrl-S ทุก ๆ 30 วินาทีและทางลัด "คอมไพล์" เกือบทุกครั้งใน IDE ที่รันโค้ดตลอดเวลาผ่านส่วนหน้าของคอมไพเลอร์เพื่อเน้นข้อผิดพลาดแบบเรียลไทม์ ทำไมถึงทานมื้อเที่ยงฟรี

มีข้อดีในการรวบรวมตามที่คุณไป แต่ฉันเห็นด้วยอย่างมากว่าการทำงานเป็นกลยุทธ์การเข้ารหัสที่ใช้ได้

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

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

ฉันเข้าใจถึงประโยชน์ของการทดสอบโค้ดของคุณเมื่อคุณดำเนินการไป แต่ทำไมจึงต้องรวบรวม

แต่คุณจะทดสอบโค้ดของคุณอย่างไรเมื่อคุณไม่คอมไพล์ด้วย?

กรณีที่รุนแรงคือการพัฒนาที่ขับเคลื่อนด้วยการทดสอบ (TDD) เห็นได้ชัดว่า TDD ไม่ทำงานกับกลยุทธ์ของคุณเนื่องจาก TDD หมายถึงรอบสั้นมากของการทดสอบการเขียนรวบรวม (ควรล้มเหลว) เขียนรหัสรวบรวมอีกครั้งเรียกใช้การทดสอบแก้ไขข้อบกพร่องรวบรวมอีกครั้ง refactor รวบรวม -again, run-test และอื่น ๆ ...

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

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

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

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

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

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

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

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

สำหรับการรวบรวมโค้ดโปรแกรมเมอร์ที่มีประสบการณ์เพียงพอจะไม่เป็นปัญหาคอขวด

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

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

การดีบักและทดสอบในทางกลับกันคือสิ่งที่ใช้เวลาสักครู่ ข้อผิดพลาดเกิดขึ้นลอจิกสำหรับทุกประเภทของเหตุผลและผมยังไม่ได้ตอบสนองคอมไพเลอร์ที่จะบอกฉันเกี่ยวกับการย่อยทั้งหมดที่ฉันลืมที่จะเขียนหรือจะสังเกตได้ว่าต้นไม้ไบนารีของฉันไม่ทำงานเพราะผมวางเมื่อมันควรจะได้รับnode->leftnode->right

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

ป.ล. - ถ้าฉันเฝ้าดูโค้ดคุณโดยอ่านมันฉันก็จะจ้างคุณทันที นั่นคือสิ่งที่มืออาชีพทำทุกครั้ง

ไม่มันไม่มีเหตุผลที่จะหยุดยั้งการคอมไพล์จนกว่าคุณจะได้ทำโค้ดในจำนวนที่เพียงพอ (และ 'จำนวนที่เพียงพอ' นั้นขึ้นอยู่กับ coder และโค้ดที่กำลังเขียน)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

จากนั้นก็มีการเขียนโค้ดที่รวบรวม

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

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

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

บริษัท ต่างๆในทุกวันนี้ไม่เพียง แต่สนใจในผลิตภัณฑ์สำเร็จรูปเท่านั้น พวกเขาต้องการรู้ว่ามันเป็น "ภายใต้การควบคุม" มาตลอด สำหรับพวกเขา "การได้รับความสนุกครึ่งหนึ่ง"

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

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

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

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

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

ในการทดสอบชิ้นเล็ก ๆ เหล่านี้คุณต้องรวบรวม

อาจเป็นไปได้ว่าผู้สัมภาษณ์สับสนสถานการณ์นี้ด้วยโปรแกรมขนาดเล็กที่ไม่ได้ออกแบบมาในลักษณะนี้

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

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