ตั้งแต่ต้นปี 2018 ฉันดำรงตำแหน่งหัวหน้า/หัวหน้า/หัวหน้านักพัฒนาในทีม - เรียกมันว่าสิ่งที่คุณต้องการก็ได้ แต่ประเด็นก็คือ ฉันรับผิดชอบทั้งหมดต่อหนึ่งในโมดูลและสำหรับนักพัฒนาทุกคนที่ทำงาน บนนั้น ตำแหน่งนี้ทำให้ฉันมีมุมมองใหม่เกี่ยวกับกระบวนการพัฒนา เนื่องจากฉันมีส่วนร่วมในโครงการมากขึ้นและมีส่วนร่วมในการตัดสินใจมากขึ้น เมื่อเร็วๆ นี้ ต้องขอบคุณทั้งสองสิ่งนี้ ทำให้ฉันตระหนักได้ทันทีว่าการวัดความเข้าใจส่งผลต่อโค้ดและแอปพลิเคชันมากน้อยเพียงใด
ประเด็นที่ฉันต้องการทำคือคุณภาพของโค้ด (และผลิตภัณฑ์ขั้นสุดท้าย) มีความสัมพันธ์อย่างใกล้ชิดกับการรับรู้ของผู้ออกแบบและเขียนโค้ดถึงสิ่งที่พวกเขากำลังทำอยู่
ตอนนี้คุณอาจจะกำลังคิดว่า “ขอบคุณนะแคป แน่นอนว่าเป็นการดีที่จะเข้าใจสิ่งที่คุณเขียนโดยทั่วไป ไม่เช่นนั้นคุณอาจจ้างลิงกลุ่มหนึ่งมากดปุ่มโดยพลการแล้วปล่อยไว้อย่างนั้น” และคุณพูดถูกอย่างแน่นอน ดังนั้น ฉันถือว่าคุณตระหนักดีว่าการมีความคิดทั่วไปเกี่ยวกับสิ่งที่คุณกำลังทำอยู่นั้นเป็นสิ่งจำเป็น สิ่งนี้เรียกได้ว่าเป็นความเข้าใจระดับศูนย์และเราจะไม่วิเคราะห์อย่างละเอียด เราจะดูรายละเอียดว่าคุณต้องเข้าใจอะไรและส่งผลต่อการตัดสินใจของคุณทุกวันอย่างไร หากฉันรู้สิ่งเหล่านี้ล่วงหน้า มันจะช่วยฉันประหยัดเวลาและรหัสที่น่าสงสัยได้มาก
แม้ว่าคุณจะไม่เห็นโค้ดด้านล่างแม้แต่บรรทัดเดียว แต่ฉันก็ยังเชื่อว่าทุกสิ่งที่กล่าวไว้ในที่นี้มีความสำคัญอย่างยิ่งในการเขียนโค้ดคุณภาพสูงและแสดงออกได้ชัดเจน
ความเข้าใจระดับแรก: เหตุใดจึงไม่ทำงาน
นักพัฒนามักจะมาถึงระดับนี้ตั้งแต่เนิ่นๆ ในอาชีพการงาน บางครั้งแม้จะไม่ได้รับความช่วยเหลือจากผู้อื่นก็ตาม อย่างน้อยก็จากประสบการณ์ของผม ลองนึกภาพว่าคุณได้รับรายงานข้อผิดพลาด: ฟังก์ชันบางอย่างในแอปพลิเคชันใช้งานไม่ได้ จำเป็นต้องได้รับการแก้ไข คุณจะดำเนินการอย่างไร?
รูปแบบมาตรฐานมีลักษณะดังนี้:
- ค้นหาส่วนของโค้ดที่เป็นสาเหตุของปัญหา (วิธีการทำเช่นนี้เป็นหัวข้อแยกต่างหาก ฉันกล่าวถึงในหนังสือเกี่ยวกับรหัสเดิม)
- ทำการเปลี่ยนแปลงข้อมูลโค้ดนี้
- ตรวจสอบให้แน่ใจว่าจุดบกพร่องได้รับการแก้ไขแล้วและไม่มีข้อผิดพลาดในการถดถอยเกิดขึ้น
ตอนนี้เรามาดูจุดที่สองกัน - ทำการเปลี่ยนแปลงโค้ด มีสองแนวทางสำหรับกระบวนการนี้ ประการแรกคือเจาะลึกถึงสิ่งที่เกิดขึ้นในโค้ดปัจจุบัน ระบุข้อผิดพลาดและแก้ไข ประการที่สอง: เคลื่อนไหวตามความรู้สึก - เพิ่ม พูด +1 ให้กับคำสั่งหรือลูปแบบมีเงื่อนไข ดูว่าฟังก์ชันทำงานในสถานการณ์ที่ต้องการหรือไม่ จากนั้นลองอย่างอื่น และอื่นๆ ไม่จำกัด
แนวทางแรกถูกต้อง ดังที่ Steve McConnell อธิบายไว้ในหนังสือ Code Complete ของเขา (ซึ่งผมขอแนะนำเป็นอย่างยิ่ง) ทุกครั้งที่เราเปลี่ยนแปลงบางอย่างในโค้ด เราควรจะคาดการณ์ได้อย่างมั่นใจว่ามันจะส่งผลต่อแอปพลิเคชันอย่างไร ฉันกำลังอ้างอิงจากความทรงจำ แต่ถ้าการแก้ไขข้อบกพร่องไม่ทำงานตามที่คุณคาดหวัง คุณควรจะตื่นตระหนกมากและคุณควรตั้งคำถามกับแผนปฏิบัติการทั้งหมดของคุณ
เพื่อสรุปสิ่งที่กล่าวไว้ เพื่อดำเนินการแก้ไขข้อบกพร่องที่ดีโดยไม่ลดคุณภาพของโค้ด คุณจำเป็นต้องเข้าใจทั้งโครงสร้างทั้งหมดของโค้ดและแหล่งที่มาของปัญหาเฉพาะ
ความเข้าใจระดับที่สอง: เหตุใดจึงได้ผล
ระดับนี้เข้าใจได้น้อยกว่าระดับก่อนหน้ามาก ฉันในขณะที่ยังเป็นนักพัฒนามือใหม่ ฉันได้เรียนรู้มันต้องขอบคุณเจ้านายของฉัน และต่อมาก็อธิบายสาระสำคัญของเรื่องนี้ให้ผู้มาใหม่ฟังซ้ำแล้วซ้ำอีก
คราวนี้ ลองจินตนาการว่าคุณได้รับรายงานจุดบกพร่องสองรายงานพร้อมกัน รายงานแรกเกี่ยวกับสถานการณ์ A และรายงานที่สองเกี่ยวกับสถานการณ์ B ในทั้งสองสถานการณ์ มีบางอย่างผิดปกติเกิดขึ้น ดังนั้นคุณจึงต้องจัดการกับจุดบกพร่องแรกก่อน การใช้หลักการที่เราพัฒนาขึ้นเพื่อความเข้าใจระดับ XNUMX คุณจะเจาะลึกลงไปในโค้ดที่เกี่ยวข้องกับปัญหา ค้นหาว่าเหตุใดจึงทำให้แอปพลิเคชันทำงานในลักษณะเดียวกับสถานการณ์ A และทำการปรับเปลี่ยนที่เหมาะสมเพื่อให้ได้ผลลัพธ์ที่คุณต้องการ คาดหวัง . ทุกอย่างเป็นไปด้วยดี
จากนั้นคุณไปยังสถานการณ์ B. คุณทำสถานการณ์ซ้ำเพื่อพยายามกระตุ้นให้เกิดข้อผิดพลาด แต่—เซอร์ไพรส์! — ตอนนี้ทุกอย่างทำงานได้ตามปกติแล้ว เพื่อยืนยันการเดาของคุณ คุณต้องยกเลิกการเปลี่ยนแปลงที่คุณทำในขณะที่แก้ไขข้อบกพร่อง A และข้อผิดพลาด B จะกลับมา การแก้ไขข้อผิดพลาดของคุณช่วยแก้ปัญหาทั้งสองได้ โชคดี!
คุณไม่ได้นับเรื่องนี้เลย คุณได้คิดหาวิธีแก้ไขข้อผิดพลาดในสถานการณ์ A และไม่รู้ว่าเหตุใดจึงใช้งานได้ในสถานการณ์ B ในขั้นตอนนี้ เป็นเรื่องที่น่าสนใจมากที่จะคิดว่าทั้งสองงานเสร็จสมบูรณ์แล้ว นี่ค่อนข้างสมเหตุสมผล: ประเด็นคือเพื่อกำจัดข้อผิดพลาดใช่ไหม แต่งานยังไม่เสร็จสิ้น คุณยังคงต้องค้นหาว่าเหตุใดการกระทำของคุณจึงแก้ไขข้อผิดพลาดในสถานการณ์ B เพราะเหตุใด เพราะมันอาจจะทำงานผิดหลักการแล้วคุณจะต้องมองหาทางออกอื่น นี่เป็นตัวอย่างบางส่วนของกรณีดังกล่าว:
- เนื่องจากโซลูชันไม่ได้รับการปรับแต่งให้เหมาะกับข้อผิดพลาด B เมื่อคำนึงถึงปัจจัยทั้งหมด คุณอาจมีฟังก์ชัน C ที่เสียหายโดยไม่รู้ตัว
- อาจเป็นไปได้ว่ามีจุดบกพร่องตัวที่สามซ่อนอยู่ที่ไหนสักแห่งซึ่งเกี่ยวข้องกับฟังก์ชันเดียวกัน และการแก้ไขข้อบกพร่องของคุณจะขึ้นอยู่กับการทำงานที่ถูกต้องของระบบในสถานการณ์ B ตอนนี้ทุกอย่างดูดี แต่วันหนึ่งจุดบกพร่องที่สามนี้จะถูกสังเกตเห็นและแก้ไข จากนั้นในสถานการณ์ B ข้อผิดพลาดจะเกิดขึ้นอีกครั้ง และจะดีถ้ามีเพียงข้อผิดพลาดนั้น
ทั้งหมดนี้เพิ่มความโกลาหลให้กับโค้ด และสักวันหนึ่งจะต้องปวดหัวกับคุณ - น่าจะเป็นช่วงเวลาที่ไม่เหมาะสมที่สุด คุณจะต้องรวบรวมกำลังใจเพื่อบังคับตัวเองให้ใช้เวลาทำความเข้าใจว่าทำไมทุกอย่างดูเหมือนจะได้ผล แต่มันก็คุ้มค่า
ความเข้าใจระดับที่สาม: เหตุใดจึงได้ผล
ข้อมูลเชิงลึกล่าสุดของฉันเกี่ยวข้องกับระดับนี้อย่างชัดเจน และอาจเป็นสิ่งที่ทำให้ฉันได้รับประโยชน์มากที่สุดหากฉันมาถึงแนวคิดนี้ก่อนหน้านี้
เพื่อให้ชัดเจนยิ่งขึ้น ลองดูตัวอย่าง: โมดูลของคุณจำเป็นต้องทำให้เข้ากันได้กับฟังก์ชัน X คุณไม่คุ้นเคยกับฟังก์ชัน X เป็นพิเศษ แต่คุณได้รับแจ้งว่าเพื่อให้เข้ากันได้กับฟังก์ชันนี้คุณต้องใช้เฟรมเวิร์ก F อื่น ๆ โมดูลที่รวมเข้ากับ X นั้นทำงานตรงกับเขาทุกประการ
โค้ดของคุณไม่ได้ติดต่อกับเฟรมเวิร์ก F เลยตั้งแต่วันแรกที่ใช้งาน ดังนั้นการติดตั้งใช้งานจึงไม่ใช่เรื่องง่าย สิ่งนี้จะส่งผลร้ายแรงต่อบางส่วนของโมดูล อย่างไรก็ตาม คุณทุ่มตัวเองเข้าสู่การพัฒนา: คุณใช้เวลาหลายสัปดาห์ในการเขียนโค้ด การทดสอบ การเปิดตัวเวอร์ชันนำร่อง รับคำติชม แก้ไขข้อผิดพลาดในการถดถอย ค้นพบภาวะแทรกซ้อนที่ไม่คาดคิด ไม่ตรงตามกำหนดเวลาที่ตกลงไว้แต่เดิม เขียนโค้ดเพิ่มเติม การทดสอบ รับการสื่อสารคำติชม แก้ไขข้อผิดพลาดในการถดถอย - ทั้งหมดนี้เพื่อใช้กรอบงาน F
และเมื่อถึงจุดหนึ่งคุณก็ตระหนักได้ทันที - หรืออาจได้ยินจากใครบางคน - ว่าเฟรมเวิร์ก F อาจไม่ทำให้คุณเข้ากันได้กับฟีเจอร์ X เลย บางทีเวลาและความพยายามทั้งหมดนั้นอาจผิดอย่างสิ้นเชิงกับสิ่งนั้น
สิ่งที่คล้ายกันเกิดขึ้นครั้งหนึ่งขณะทำงานในโครงการที่ฉันรับผิดชอบ ทำไมสิ่งนี้ถึงเกิดขึ้น? เนื่องจากฉันมีความเข้าใจเพียงเล็กน้อยว่าฟังก์ชัน X คืออะไร และเกี่ยวข้องกับเฟรมเวิร์ก F อย่างไร ฉันควรทำอย่างไร ขอให้บุคคลที่มอบหมายงานการพัฒนาอธิบายอย่างชัดเจนว่าแนวทางปฏิบัติที่ตั้งใจไว้นำไปสู่ผลลัพธ์ที่ต้องการได้อย่างไร แทนที่จะแค่ทำซ้ำสิ่งที่ทำไปแล้วสำหรับโมดูลอื่นๆ หรือใช้คำพูดของพวกเขาว่านี่คือสิ่งที่ฟีเจอร์ X ต้องทำ
ประสบการณ์ของโครงการนี้สอนให้ฉันปฏิเสธที่จะเริ่มกระบวนการพัฒนาจนกว่าเราจะมีความเข้าใจที่ชัดเจนว่าเหตุใดเราจึงถูกขอให้ทำบางสิ่ง ปฏิเสธไปเลย เมื่อคุณได้รับงาน แรงกระตุ้นแรกคือรีบลงมือทำทันทีเพื่อไม่ให้เป็นการเสียเวลา แต่นโยบาย “ระงับโครงการจนกว่าเราจะได้ลงรายละเอียดทั้งหมด” สามารถลดเวลาที่เสียไปได้ตามลำดับความสำคัญ
แม้ว่าพวกเขาจะพยายามกดดันคุณ แต่เพื่อบังคับให้คุณเริ่มทำงาน แม้ว่าคุณจะไม่เข้าใจเหตุผลในเรื่องนี้ จงต่อต้าน ขั้นแรก หาคำตอบว่าทำไมคุณถึงได้รับมอบหมายงานดังกล่าว และตัดสินใจว่านี่เป็นเส้นทางที่ถูกต้องไปสู่เป้าหมายหรือไม่ ฉันต้องเรียนรู้ทั้งหมดนี้อย่างยากลำบาก - ฉันหวังว่าตัวอย่างของฉันจะทำให้ชีวิตง่ายขึ้นสำหรับผู้ที่อ่านข้อความนี้
ความเข้าใจระดับที่สี่: ???
มีอะไรอีกมากมายให้เรียนรู้ในการเขียนโปรแกรม และฉันเชื่อว่าฉันเพิ่งเริ่มต้นหัวข้อความเข้าใจเท่านั้น คุณค้นพบความเข้าใจระดับอื่นใดอีกบ้างตลอดหลายปีที่ผ่านมาในการทำงานกับโค้ด? คุณตัดสินใจอะไรบ้างที่มีผลกระทบเชิงบวกต่อคุณภาพของโค้ดและแอปพลิเคชัน การตัดสินใจใดที่กลายเป็นเรื่องผิดและสอนบทเรียนอันมีค่าแก่คุณ แบ่งปันประสบการณ์ของคุณในความคิดเห็น
ที่มา: will.com