คำนำผู้แปล: หลังจากอ่านบทความนี้แล้ว คุณอาจจะแปลกใจหรือโกรธก็ได้ ใช่ เราก็แปลกใจเหมือนกัน ผู้เขียนไม่เคยได้ยินเกี่ยวกับลำดับชั้นในทีมมาก่อน เกี่ยวกับการกำหนดงานที่มีสถานะ “ทำอย่างรวดเร็วและไม่มีเหตุผล” ใช่แล้ว นี่เป็นข้อความที่แปลกนิดหน่อย แท้จริงแล้วผู้เขียนแนะนำว่าโปรแกรมเมอร์รับหน้าที่เป็นสถาปนิกระบบ - ทำไมคุณถึงต้องการสถาปนิก? แต่การคัดค้านทั้งหมดนี้ไม่ควรทำให้คุณตาบอดต่อสิ่งสำคัญ - เหตุใดเราจึงรับและแปลข้อความนี้ เขาไม่ได้พูดถึงบทบาท ข้อความนี้เป็นเรื่องเกี่ยวกับแนวทางและความตระหนักรู้แบบมืออาชีพ ความจริงก็คือ ตราบใดที่คุณเพียงแค่ “ทำสิ่งที่คุณถูกบอก” โดยไม่คำนึงถึงความหมายของการกระทำของคุณ คุณจะไม่มีวันเป็นโปรแกรมเมอร์ที่ยอดเยี่ยมได้
ปฏิเสธโค้ดที่ไม่จำเป็น สิ่งที่คุณต้องทำคือนำตัวอักษรสามตัวมารวมกันแล้วพูดคำนั้น มาลองทำสิ่งนี้ด้วยกัน: "Nooooo!"
แต่เดี๋ยวก่อน. เราจะทำเช่นนี้ทำไม? ท้ายที่สุดแล้วงานหลักของโปรแกรมเมอร์คือการเขียนโค้ด แต่คุณจำเป็นต้องเขียนโค้ดใดๆ ที่ถูกถามถึงคุณหรือไม่? เลขที่! “การทำความเข้าใจว่าเมื่อใดที่ไม่ควรเขียนโค้ดอาจเป็นทักษะที่สำคัญที่สุดสำหรับโปรแกรมเมอร์” .
เราเตือนคุณ: สำหรับผู้อ่าน "Habr" ทุกคน - ส่วนลด 10 rubles เมื่อลงทะเบียนในหลักสูตร Skillbox ใด ๆ โดยใช้รหัสส่งเสริมการขาย "Habr"
Skillbox แนะนำ: หลักสูตรภาคปฏิบัติ .
การเขียนโปรแกรมเป็นศิลปะของการแก้ปัญหา และคุณเป็นผู้เชี่ยวชาญด้านศิลปะนี้
บางครั้ง ด้วยความพยายามที่จะเริ่มงานให้เร็วที่สุดเท่าที่จะเป็นไปได้ เราไม่ได้คิดอะไรนอกจากทำงานให้เสร็จ และนี่อาจทำให้เกิดปัญหาร้ายแรงยิ่งขึ้นได้
โปรแกรมเมอร์เมินอะไร?
โค้ดทั้งหมดที่คุณเขียนจะต้องสามารถเข้าใจได้สำหรับนักพัฒนารายอื่น และต้องได้รับการทดสอบและแก้ไขจุดบกพร่อง
แต่มีปัญหา: ไม่ว่าคุณจะเขียนอะไรก็ตาม มันจะทำให้ซอฟต์แวร์ของคุณซับซ้อนและอาจทำให้เกิดจุดบกพร่องในอนาคต
ตามคำกล่าวของริช สเครนท์ . นี่คือสิ่งที่เขาเขียน:
“โค้ดไม่ดีเพราะมันเริ่มเน่าและต้องมีการบำรุงรักษาอย่างต่อเนื่อง การเพิ่มคุณสมบัติใหม่มักต้องมีการแก้ไขโค้ดเก่า ยิ่งมีขนาดใหญ่เท่าใด โอกาสที่จะเกิดข้อผิดพลาดก็จะยิ่งสูงขึ้น และจะใช้เวลาในการคอมไพล์มากขึ้นเท่านั้น นักพัฒนารายอื่นต้องใช้เวลามากขึ้นในการคิดออก และหากจำเป็นต้องมีการปรับโครงสร้างใหม่ ก็จะมีชิ้นส่วนที่คุ้มค่าที่จะเปลี่ยนแปลงอย่างแน่นอน โค้ดขนาดใหญ่มักหมายถึงความยืดหยุ่นและฟังก์ชันการทำงานของโปรเจ็กต์ลดลง โซลูชันที่เรียบง่ายและสวยงามเร็วกว่าโค้ดที่ซับซ้อน”
จะรู้ได้อย่างไรว่าเมื่อใดไม่ควรเขียนโค้ด?
ปัญหาคือโปรแกรมเมอร์มักจะพูดเกินจริงเกี่ยวกับจำนวนฟีเจอร์ที่พวกเขาต้องการ เป็นผลให้โค้ดหลายส่วนยังคงสร้างไม่เสร็จหรือไม่มีใครใช้ แต่จะทำให้แอปพลิเคชันซับซ้อนขึ้น
คุณต้องเข้าใจอย่างชัดเจนว่าโครงการของคุณต้องการอะไรและไม่ต้องการอะไร
ตัวอย่างคือแอปพลิเคชันที่แก้ปัญหาได้เพียงงานเดียว นั่นคือการจัดการอีเมล เพื่อจุดประสงค์นี้มีการแนะนำฟังก์ชั่นสองอย่าง - การส่งและรับจดหมาย คุณไม่ควรคาดหวังให้ผู้จัดการเมลกลายเป็นผู้จัดการงานในเวลาเดียวกัน
คุณต้องปฏิเสธข้อเสนออย่างหนักแน่นเพื่อเพิ่มคุณสมบัติที่ไม่เกี่ยวข้องกับงานหลักของแอปพลิเคชัน นี่เป็นช่วงเวลาที่ชัดเจนว่าไม่จำเป็นต้องใช้รหัสเพิ่มเติม
อย่าละสายตาจากแอปพลิเคชันของคุณ
ถามตัวเองเสมอว่า:
— ตอนนี้ควรใช้งานฟังก์ชันอะไร?
- ฉันควรเขียนโค้ดอะไร?
ตั้งคำถามกับแนวคิดที่อยู่ในใจและประเมินข้อเสนอแนะที่มาจากภายนอก มิฉะนั้นโค้ดพิเศษอาจทำให้โปรเจ็กต์เสียหายได้
การรู้ว่าเมื่อใดที่จะไม่เพิ่มสิ่งที่ไม่จำเป็นจะช่วยให้คุณรักษาฐานโค้ดของคุณภายใต้การควบคุมที่มั่นคง
ที่จุดเริ่มต้นของเส้นทาง โปรแกรมเมอร์มีไฟล์ต้นฉบับเพียงสองหรือสามไฟล์เท่านั้น มันง่ายมาก การคอมไพล์และเปิดใช้แอปพลิเคชันต้องใช้เวลาขั้นต่ำ ชัดเจนเสมอว่าจะมองหาที่ไหนและอะไร
เมื่อแอปพลิเคชันขยายออก ไฟล์โค้ดก็จะปรากฏขึ้นมากขึ้นเรื่อยๆ พวกเขากรอกแค็ตตาล็อก แต่ละรายการมีหลายร้อยบรรทัด เพื่อที่จะจัดระเบียบทั้งหมดนี้ได้อย่างถูกต้อง คุณจะต้องสร้างไดเร็กทอรีเพิ่มเติม ในเวลาเดียวกัน การจดจำว่าหน้าที่ใดที่รับผิดชอบต่ออะไรและการกระทำใดที่ทำให้เกิดสิ่งเหล่านั้นกลายเป็นเรื่องยากมากขึ้น การจับแมลงยังต้องใช้เวลามากขึ้น การจัดการโครงการก็มีความซับซ้อนมากขึ้นเช่นกัน ไม่ใช่เพียงคนเดียว แต่นักพัฒนาหลายคนจำเป็นต้องติดตามทุกอย่าง ดังนั้นต้นทุนทั้งตัวเงินและเวลาจึงเพิ่มขึ้น และกระบวนการพัฒนาก็ช้าลง
โปรเจ็กต์นี้กลายเป็นเรื่องใหญ่ในที่สุด และการเพิ่มฟีเจอร์ใหม่แต่ละอย่างต้องใช้ความพยายามมากขึ้นเรื่อยๆ แม้จะเป็นเรื่องเล็กน้อย แต่คุณต้องใช้เวลาหลายชั่วโมง การแก้ไขข้อผิดพลาดที่มีอยู่จะทำให้เกิดข้อผิดพลาดใหม่ และพลาดกำหนดเวลาเผยแพร่แอปพลิเคชัน
ตอนนี้เราต้องต่อสู้เพื่อชีวิตของโครงการ ทำไม
ความจริงก็คือคุณไม่เข้าใจเมื่อคุณไม่ควรเพิ่มโค้ดพิเศษและตอบว่า "ใช่" สำหรับทุกข้อเสนอแนะและแนวคิด คุณเป็นคนตาบอด ความปรารถนาที่จะสร้างสิ่งใหม่ทำให้คุณเพิกเฉยต่อข้อเท็จจริงที่สำคัญ
ฟังดูเหมือนบทหนังสยองขวัญใช่ไหม?
นี่คือสิ่งที่จะเกิดขึ้นหากคุณเอาแต่ตอบตกลง พยายามทำความเข้าใจว่าเมื่อใดที่ไม่ควรเพิ่มโค้ด ลบสิ่งที่ไม่จำเป็นออกจากโครงการซึ่งจะทำให้ชีวิตของคุณง่ายขึ้นมากและยืดอายุของแอปพลิเคชัน
“วันที่ผมมีประสิทธิผลมากที่สุดวันหนึ่งคือตอนที่ผมลบโค้ดไป 1000 บรรทัด”
— เคน ทอมป์สัน
การเรียนรู้ว่าเมื่อใดที่จะไม่เขียนโค้ดเป็นเรื่องยาก แต่มันเป็นสิ่งจำเป็น
ใช่ ฉันรู้ว่าคุณเพิ่งเริ่มต้นเส้นทางของนักพัฒนาและต้องการเขียนโค้ด เป็นเรื่องดี อย่าสูญเสียความประทับใจแรกพบ แต่อย่าละสายตาจากปัจจัยสำคัญเพราะความกระตือรือร้น เราตระหนักทุกอย่างผ่านการลองผิดลองถูก คุณจะทำผิดพลาดและเรียนรู้จากพวกเขาด้วย แต่หากคุณเรียนรู้จากสิ่งที่กล่าวมาข้างต้นได้ งานของคุณก็จะมีสติมากขึ้น
สร้างต่อไป แต่รู้ว่าเมื่อใดควรปฏิเสธ
Skillbox แนะนำ:
- สมัครเรียนออนไลน์ .
- คอร์สออนไลน์ .
- หลักสูตรปีปฏิบัติ .
ที่มา: will.com