ส่วนใดของ Code Complete ที่ยังไม่ได้ทดสอบ [ปิด]

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

ฉันอยากรู้อยากเห็น - มีคนอื่นให้ดูที่สองเมื่อเร็ว ๆ นี้? ฉันคุณเห็นอะไรที่เขาผิดมาก ๆ ไหม?

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

และโปรด - ไม่มีความคิดเห็นเกี่ยวกับ "Demarco / Spewak / Zachman ยืนการทดสอบของเวลา ... " ฉันสนใจเป็นพิเศษใน Code Complete เนื่องจากความกว้างของพื้นดินครอบคลุมและความกว้างของผลกระทบที่มีในสนาม

Code Complete ครอบคลุมแนวคิดที่ไม่มีเวลามากเช่น:

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

ซึ่งมีความเกี่ยวข้องอย่างแน่นอนในวันนี้

แนวคิดบางอย่างที่ได้รับการสนับสนุนใน CC ได้รับการบังคับใช้ทาง syntactically ในภาษาที่ใหม่กว่าตัวอย่างเช่น C # ไม่อนุญาตให้มีการกำหนดตัวแปรในขอบเขตย่อยในลักษณะที่ซ่อนการกำหนดขอบเขตแบบซุปเปอร์ไว้

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

ทั้งหมดบอกจากสิ่งที่ฉันสามารถจำ (และมองอย่างรวดเร็วภายในสำเนาที่น่าเคารพของ CC) ฉันจะบอกว่ามันคุ้มค่าที่จะตรวจสอบ

อย่างไรก็ตามฉันไม่คิดว่ามันจะเกิดขึ้นกับธรรมชาติที่ไร้กาลเวลาอย่างแท้จริงของ The Mythical Man Month MMM กล่าวถึงประเด็นที่ว่าใครทำงานอะไรและทำไมพวกเขาถึงทำงาน รวมถึงค่าใช้จ่ายและความซับซ้อนของการสื่อสาร (มนุษย์) MMM แก้ไขปัญหาที่เป็นพื้นฐานของทุกสิ่งที่เราทำ ในการเปรียบเทียบ CC มุ่งเน้นไปที่ปัญหาเชิงปฏิบัติและในทางปฏิบัติของวิธีที่เราทำ อีกวิธีหนึ่งถ้าโครงการล่าช้ากว่ากำหนดและผู้จัดการตัดสินใจเพิ่มคน 100 คนในทีมการเขียนรหัสที่เข้าใจได้จะไม่สร้างความแตกต่าง

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

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

ความหวังที่ช่วย พวกเขาเป็นสองรายการโปรดของฉันอย่างแน่นอน

โดยรวมแล้วหนังสือยังดีอยู่ อย่างไรก็ตามฉันมีปัญหาเล็กน้อยกับมัน:

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

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