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

ดังนั้นคำถามของฉันคือเป็นคนที่คิดว่าเทคนิคนามธรรมบางอย่างจะฉลาดเกินไปตรงข้ามกับความฉลาดต่อ seหรือมีบางเหตุผลอื่น ๆ สำหรับการคัดค้านหรือไม่

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

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

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

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

หลักการจูบ

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

“ การแก้จุดบกพร่องนั้นยากกว่าการเขียนโค้ดตั้งแต่แรก ดังนั้นถ้าคุณเขียนรหัสอย่างฉลาดที่สุดเท่าที่จะทำได้คุณจะไม่ฉลาดพอที่จะทำการแก้ไข”

Brian Kernighan

คนโง่มองข้ามความซับซ้อน นักปฏิบัตินิยมต้องทนทุกข์ทรมาน ผู้เชี่ยวชาญหลีกเลี่ยง อัจฉริยะลบออก - Alan Perlis

ทางออกที่ดีที่สุดไม่ใช่วิธีที่ฉลาดที่สุดเสมอไป บางครั้งวิธีแก้ปัญหาอย่างง่าย ๆ ก็ดีพอ ๆ กัน

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

หากต้องการอ้างอิง Brian Kernighan:

“ การแก้จุดบกพร่องนั้นยากกว่าการเขียนโค้ดตั้งแต่แรก ดังนั้นถ้าคุณเขียนรหัสอย่างฉลาดที่สุดเท่าที่จะทำได้คุณจะไม่ฉลาดพอที่จะทำการแก้ไข”

ความฉลาดเป็นเครื่องมือ ด้วยตัวมันเองมันไม่เป็นอันตราย มันจะกลายเป็นอันตรายในบริบทที่ไม่จำเป็นเท่านั้น

"เคลฟเวอร์" เมื่อใช้กับโค้ดนั้นมักจะเป็นเพียงคำสละสลวยสำหรับ "ซับซ้อนโดยไม่จำเป็น"

การอ่านโค้ดที่ดีชัดเจนง่ายนั้นยากพอ การอ่านรหัส "ฉลาด" เปรียบเสมือนการศึกษาบทกวีภาษาละตินอีกครั้ง

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

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

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

1. ไม่มีใครสามารถคิดออกปล่อยให้อยู่คนเดียวรักษามัน / แก้ปัญหา
2. คนที่เขียนไม่ได้รู้ว่ามันทำอะไร
3. มันอาจไม่ใช่สิ่งที่ยอดเยี่ยมในการเริ่มต้น
4. ฯลฯ ....

ทุกจุดที่ดี แต่มีแง่มุมเชิงลบของความฉลาดและนั่นคือปัญหาอัตตาเก่า สิ่งนี้ทำให้เกิดปัญหาตามแนวของ

1. คนที่ "ฉลาด" เกินไปที่จะใช้โซลูชันของคนอื่น ทำไมมองหาสิ่งที่คนอื่นทำเมื่อคุณสามารถคิดค้นวิธีการสร้างแมวที่เหมือนกันของคุณเอง?
2. คนที่คิดว่าพวกเขาคิดค้นวิธีแก้ปัญหาที่เจ๋งที่สุดมักจะปฏิเสธที่จะรับข้อมูลใด ๆ
3. ไม่อนุญาตให้ใครแก้ไขโค้ด "ของพวกเขา" แม้ว่าจะมีปัญหาที่ชัดเจนหรือจำเป็นต้องมีการเปลี่ยนแปลงเล็กน้อย
4. ในทางกลับกันพวกเขาคิดว่าพวกเขาฉลาดและต้องใช้เทคนิค "ล่าสุด" เพื่อพิสูจน์ว่าพวกเขาฉลาดแค่ไหน แต่ไม่สามารถจัดการกับมันได้ดีในโครงการส่วนบุคคลหรือรหัสอื่น ๆ ที่ไม่ใช่การผลิต ระบบ.

พวกเราทุกคนมีความผิดในอัตตามากเกินไป แต่เมื่อมันเข้ามาในทีมมันเป็นปัญหา

Good Clever - อัตราส่วนสูงระหว่างบรรทัดที่ฉลาดของโค้ดเทียบกับบรรทัดของทางเลือกที่ไม่ฉลาด 20 บรรทัดของรหัสที่ช่วยให้คุณประหยัดจากการเขียน 20,000 เป็นอย่างยิ่งที่ฉลาด Good Clever เกี่ยวกับการช่วยตัวเองให้ทำงาน

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

ข้อควรทราบ: Bad Clever แทบไม่เคยถูกเรียกว่า "Bad Clever" มันมักจะเดินทางภายใต้นามแฝงว่า "สวยงาม", "สง่างาม", "รัดกุม" หรือ "รวบรัด"

ฉันต้องสงสัยเกี่ยวกับคำจำกัดความของทุกคนที่ฉลาด

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

tl; dr ฉันรู้สึกฉลาดเมื่อในระหว่างการตรวจสอบโค้ดผู้ตรวจสอบของฉันบอกว่า "ว้าวนั่นง่ายกว่าที่ฉันคิดว่ามันจะเป็น" เมื่อเทียบกับ "wtf คือทั้งหมดนี้ .. "

นอกเหนือจากทฤษฎีคำตอบที่ระบุไว้บ่อยครั้งสิ่งนี้ถูกนำมาใช้ในบริบทที่ฉลาดเกินไปสำหรับคนอื่น

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

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

บางครั้งฉันก็ฉลาดว่าฉันผิด

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

หากรหัสที่ฉลาด + จำนวนความคิดเห็นที่จำเป็นในการทำให้มันเป็นรหัสที่เข้าใจได้ <= รหัสที่เรียบง่ายแล้วฉันพูดไปสำหรับรหัสที่ฉลาด ทุกเวลา.

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

ฉันนึกถึงคำพูดที่ฉันเคยเห็นมาจากหลาย ๆ คนเพราะคำพูดที่ดีมักจะเป็น

ในการถอดความ:

บุคคลที่ฉลาดสามารถสร้างคอมเพล็กซ์อย่างง่ายได้ต้องใช้อัจฉริยะเพื่อสร้างคอมเพล็กซ์ที่เรียบง่าย

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

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

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

มีอัลกอริธึมที่รู้จักกันหลายอย่างที่ฉลาด Quicksortคือหนึ่ง IMO

รหัส "ฉลาด" (พร้อมการเสียดสี) มักจะตั้งสมมติฐานเกี่ยวกับตัวแปรที่ตั้งค่าและสถานะของระบบที่ถูกตัดการเชื่อมต่อจากรหัส "ฉลาด" (เมื่อเปิดไฟล์ก่อนหน้านี้การเชื่อมต่อเครือข่ายฐานข้อมูล ฯลฯ ... )

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

"รหัสเคลฟเวอร์" คือโค้ดใด ๆ ที่โปรแกรมเมอร์ต้องคิดอย่างหนักหรือใช้ทักษะขั้นสูงในการเขียน ปัญหาที่เกิดขึ้นโดยไม่คำนึงถึงความจำเป็นในการใช้ "ความฉลาดขอบ" ซึ่งแสดงออกโดย Brian W. Kernighan ที่ดีที่สุด:

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

เพราะสิ่งที่ดูเหมือนว่าความฉลาดให้กับนักพัฒนาในการออกมาของความคิดสร้างสรรค์ก็สามารถผ่านเป็นระเบียบและเพียงแค่เป็นอ่านไม่ได้ , unmaintainableบล็อกปริศนาคลุมเครือสำหรับคนอื่น ๆ

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

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

หากไม่มีเหตุผลก็อาจเป็นได้ทั้งการปรับให้เหมาะสมก่อนวัยอันควร, over-engineering หรือปัญหาประเภท YAGNI หากใช้วิธีอ้อม 15 ระดับในการทำสิ่งที่ง่ายก็มีโอกาสที่คุณจะได้อยู่ในหมวดหมู่ก่อนหน้าเช่นกัน และถ้ามันไม่ได้บันทึกไว้มันก็แค่มีปัญหา

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

หมายเหตุ: เฮ้ฉันได้เขียนบางสิ่งที่ฉันคิดว่าฉลาด แต่นั่นก็ดึง WTF หรือไม่ ออกจาก - หากไม่ใช่ผู้พัฒนาร่วมของฉัน - ปากผู้จัดการของฉัน ต้องมองจากมุมมองของพวกเขา

ฉันมีแนวโน้มที่จะฉลาดแต่ผมมุ่งมั่นที่จะสง่างาม

พัฒนารหัสในขณะนี้ว่าคนอื่น ๆ จะไม่พยายามหลีกเลี่ยงในภายหลัง

นี่คือความเข้าใจของฉันของปัญหาตามประสบการณ์ของฉันและคำตอบอื่น ๆ :

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

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

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

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

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

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

ฉันจำได้ว่าเมื่อฉันใช้ 1 รายการแทน 3 และสร้างฟังก์ชั่นใหญ่ที่ยากต่อการดูแล / เปลี่ยนแปลง

ในโลกปัจจุบันเราไม่ต้องเสียสละโค้ดเพื่อประสิทธิภาพ (ยกเว้น c ++ พวกเขาไม่จำเป็นต้องทำ แต่จะต้อง)

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

ดังนั้นฉลาด == ทำให้สับสน == ไม่ดี :( แต่มันก็ยอดเยี่ยมเพราะฉันใช้มันสำหรับการแก้ปัญหาในทางปฏิบัติเพื่อ จำกัด ปัญหา

การอ้างถึงบริบทและความเข้าใจที่ง่ายขึ้น:

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

สิ่งที่ Brian Kernighan เขียนไว้ในที่นี้หมายถึงการโน้มน้าวใจอย่างชัดเจนและเขาใช้คำว่าฉลาดอย่างไม่เหมาะสม

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

บิด:

A thing that is complex and difficult to follow.

ฉลาด:

Showing intelligence or skill; ingenious

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

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

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

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

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

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

• การพูดคุยของกุยโดแวนรอสุมเกี่ยวกับลูปของเหตุการณ์และวิธีที่เขาเข้าใจพวกเขา
• พนักงานของ GitHub ที่ระบุว่าพวกเขาหลีกเลี่ยงการจ้างคนฉลาดใน Y-Combinator
• การอภิปรายและการเรียนรู้ส่วนใหญ่เกิดขึ้นในชุมชน Python ชุมชน Python มีความสำคัญอย่างยิ่งต่อความคิดใหม่ ๆ แต่ไม่ได้ละทิ้งความคิดใหม่ ๆ ที่พวกเขาไม่เข้าใจและคุณมักจะเห็นคุณลักษณะที่เคยเห็นเป็นครั้งแรกในฐานะที่ซับซ้อนเมื่อเห็นความสับสนวุ่นวายของคุณสมบัติหลัก / แพ็คเกจภาษา
• ประสบการณ์ของฉันเองและความเห็นอย่างมืออาชีพจากการสังเกต 10,000 ฟุตของฉัน ฉันไม่เห็นรายละเอียดที่เฉพาะเจาะจงเพื่อให้ความกระจ่างจากที่นั่นแม้ว่า: (หวังว่าประสบการณ์และการสังเกตของคุณจะบอกคุณในสิ่งเดียวกันและคนอื่น ๆ สามารถแสดงความคิดเห็นด้านล่างเพื่อให้คำตอบนี้ได้บ้าง

อย่าลังเลที่จะเพิ่มการอ้างอิงของคุณเอง! นอกจากนี้โปรดเพิ่มเครื่องหมายจุลภาคในข้อความของฉัน ฉันไม่ได้รีเฟรชความรู้เกี่ยวกับการใช้จุลภาคเป็นภาษาอังกฤษในบางครั้ง ...

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

มันไม่ใช่ความฉลาด มันเป็นความรู้

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

นักพัฒนาที่ฉลาดเป็นสิ่งที่ดี

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

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