หากทีมของฉันมีทักษะต่ำฉันควรลดความสามารถของรหัสของฉันลงหรือไม่ [ปิด]

ตัวอย่างเช่นมีตัวอย่างทั่วไปใน JS เพื่อรับค่าเริ่มต้น:

function f(x) {
    x = x || 'default_value';
}

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

ฉันไม่ควรใช้เคล็ดลับนี้หรือไม่? มันทำให้โค้ดอ่านน้อยลงโดยเพียร์ แต่อ่านได้มากกว่าต่อไปนี้ตาม JS dev ใด ๆ :

function f(x) {
    if (!x) {
        x = 'default_value';
    }
}

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

ดังนั้นฉันควรลดระดับรหัสของฉันหรือไม่หากเพื่อนร่วมทีมของฉันมีระดับต่ำกว่าฉัน

ตกลงนี่เป็นเรื่องของฉันในหัวข้อใหญ่และซับซ้อน

ข้อดีสำหรับการรักษาสไตล์การเขียนโค้ดของคุณ:

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

ข้อเสียสำหรับการรักษารูปแบบการเข้ารหัสของคุณ:

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

ความคิดเห็นส่วนตัวของฉัน

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

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

สิ่งที่สำคัญที่สุดคือการอยู่อย่างสม่ำเสมอ

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

ความคิดเห็นดี

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

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

เรื่องของสไตล์?

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

ในฐานะที่เป็นคำตอบอื่นที่ระบุไว้แล้วให้มันสอดคล้อง

สอนผู้ชายให้ตกปลา ...

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

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

เทคนิค "ฉลาด"

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

หากคุณพบว่าคุณต้องใช้เคล็ดลับที่ชาญฉลาดอย่างน้อยทำตามคำแนะนำต่อไป ...

จูบ

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

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

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

x = x || 'default_value';

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

เมื่อฉันมองไปที่รหัสที่ฉันเห็น "ถ้ามันnullหรือundefinedแล้วตั้งเป็นค่าเริ่มต้นนี้. แม้ว่ามันจะยังปริยายรักษา+0, -0, NaN, falseและ""เป็นค่าที่ไม่เหมาะสม. ฉันจะต้องจำไว้ว่า 3 เดือนนับจากนี้เมื่อความต้องการ เพื่อเปลี่ยนแปลงฉันอาจจะลืมมัน ".

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

ตัวอย่างใหม่ของคุณมีไวยากรณ์ที่คุ้นเคยมากกว่า แต่ก็ยังมีปัญหาข้างต้น

คุณสามารถไปกับ:

function f(x) {
    x = valueOrDefault(x, "default_value");
}

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

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

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

| 0หรือรุ่นลัทธิขนส่งสินค้าที่~~numใช้สำหรับปูพื้นถือว่าเป็นจำนวนเต็มบวกและมีการลงนามแบบ 32 บิต

|| "default" สมมติว่าค่าเท็จทั้งหมดเหมือนกับที่ไม่ผ่านการโต้แย้งเลย

และอื่น ๆ

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

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

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

สิ่งนี้อาจถูกกล่าวถึงแล้วในคำตอบอื่น แต่ฉันต้องการตอบคำถามนี้คำสั่งของฉันเอง

หลักเกณฑ์ทั่วไป

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

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

ตัวอย่างที่เฉพาะเจาะจง

เรามีสคริปต์ Perl จำนวนมากในฐานรหัสของเรา โดยทั่วไปเราใช้ Perl สำหรับการดำเนินการที่ง่ายมากและโค้ดส่วนใหญ่เขียนโดยนักพัฒนาจาวาดังนั้นจึงมีสไตล์คล้ายจาวา เรามีชุดของสคริปต์ Perl และกรอบที่เขียนโดย 'perl guru' ที่มีตั้งแต่ บริษัท ของเรา รหัสนี้ประกอบด้วยรหัส Perl ที่คลุมเครือจำนวนมากและไม่มีนักพัฒนาของเรารวมถึงตัวฉันเองสามารถอ่านรหัส Perl นี้ได้โดยไม่ต้องใช้ความพยายามมาก เรามักจะสาปแช่งเขาเพื่อมัน :)

หากคุณเขียนรหัสที่ดี แต่คุณคิดว่าเพื่อนร่วมงานปัจจุบันหรืออนาคตของคุณอาจมีปัญหาในการติดตามคุณควรเพิ่มความคิดเห็นสั้น ๆ เพื่ออธิบาย

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

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

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

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

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

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

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

อย่าไปทำงานให้กับ Royal McBee Computer Corp เพราะใครจะบอกว่าคุณไม่ใช่โปรแกรมเมอร์ที่ไม่มีประสบการณ์

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

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

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

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

สำหรับผู้เริ่มต้นที่ดูเหมือน JS พื้นฐานสำหรับฉัน

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

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

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

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

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

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

ปัญหาคือคุณต้องการให้แหล่งข้อมูลอ่านได้ดี แต่การอ่านนั้นอยู่ในสายตาของคนดู

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

ด้วยวิธีนี้คุณสามารถพิมพ์และอ่านx = x || 10และโปรแกรมเมอร์คนอื่น ๆ จะอ่านมันเป็น

if (0 == x) { x = 10;}

emacs มีชิ้นส่วนทั้งหมดที่จะทำเช่นนั้นได้อย่างง่ายดาย

แทนที่จะโง่รหัสทำไมไม่ปรับปรุงคุณภาพของทีม? การฝึกอบรมการฝึกสอนการศึกษาและการจ้างงานที่ได้รับการปรับปรุงสามารถทำได้หลายอย่างเพื่อให้มั่นใจว่ามีการปรับปรุงอย่างต่อเนื่อง
Statism รหัสเน่าปฏิเสธที่จะปรับปรุงและคิดค้นเพราะมีคนไม่ต้องการทำงานในการพัฒนาตนเองเพียง แต่ทำให้เกิดปัญหาในบรรทัดและเร็วกว่าในภายหลัง

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