ความคิดเห็นเกี่ยวกับรายการที่คุณถกเถียงกันมากที่สุดคืออะไร?


363

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

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

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

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

คำตอบ:


875

โปรแกรมเมอร์ที่ไม่เขียนโค้ดในเวลาว่างเพื่อความสนุกสนานจะไม่มีวันดีเท่าที่ทำ

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

(หมายเหตุ: ฉันไม่ได้พูดว่าโปรแกรมเมอร์ที่ดีไม่ได้ทำอะไรนอกจากการเขียนโปรแกรม แต่พวกเขาทำมากกว่าโปรแกรม 9-5)


769

"วิธีปฏิบัติที่ดีที่สุด" เท่านั้นที่คุณควรใช้ตลอดเวลาคือ "ใช้สมองของคุณ"

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

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


711

"Googling มัน" ไม่เป็นไร!

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

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

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

(แม้ว่าคุณจะได้รับคำตอบจากกบพูดหลอนคุณควรได้รับความช่วยเหลือเหมือนกันทั้งหมด)


710

ความคิดเห็นส่วนใหญ่ในรหัสในความเป็นจริงเป็นรูปแบบของการทำซ้ำรหัสอันตราย

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

ฉันคิดว่าในที่สุดหลายคนก็แค่ล้างพวกมันออกโดยเฉพาะในกล่องดอกไม้

ดีกว่าที่จะจดจ่ออยู่กับการทำให้โค้ดอ่านง่าย refactoring ตามความจำเป็นและลดสำนวนและการเล่นโวหาร

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


693

XML มีค่าเกินจริงอย่างมาก

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

5 เซนต์ของฉัน


678

โปรแกรมเมอร์ทั้งหมดไม่ได้ถูกสร้างขึ้นเท่ากัน

บ่อยครั้งที่ผู้จัดการคิดว่า DeveloperA == DeveloperB เพียงเพราะพวกเขามีประสบการณ์ในระดับเดียวกันและอื่น ๆ ในความเป็นจริงประสิทธิภาพของนักพัฒนารายหนึ่งอาจเป็น 10 เท่าหรือ 100 เท่าของอีกราย

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


614

ฉันล้มเหลวที่จะเข้าใจว่าทำไมคนคิดว่า Java เป็นภาษาการเขียนโปรแกรม "แรก" ที่ดีที่สุดที่จะสอนในมหาวิทยาลัย

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

สำหรับคนอื่นฉันเชื่อว่าคนที่ไม่เคยมีประสบการณ์ในการดีบักการรั่วไหลของหน่วยความจำใน C / C ++ ไม่สามารถชื่นชมสิ่งที่ Java นำมาสู่ตารางได้อย่างเต็มที่

ความก้าวหน้าตามธรรมชาติควรมาจาก "ฉันจะทำสิ่งนี้ได้อย่างไร" ถึง "ฉันจะหาห้องสมุดที่ทำสิ่งนั้นได้อย่างไร" และไม่ใช่วิธีอื่น ๆ


541

หากคุณรู้จักภาษาเดียวไม่ว่าคุณจะรู้ดีแค่ไหนคุณก็ไม่ใช่โปรแกรมเมอร์ที่ยอดเยี่ยม

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

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



488

คำสั่งการพิมพ์เป็นวิธีที่ถูกต้องในการแก้จุดบกพร่องรหัส

ผมเชื่อว่ามันเป็นอย่างดีปรับให้แก้ปัญหารหัสของคุณโดยการทิ้งขยะด้วยSystem.out.println(หรือพิมพ์คำสั่งงานอะไรก็ตามสำหรับภาษาของคุณ) บ่อยครั้งสิ่งนี้เร็วกว่าการดีบักและคุณสามารถเปรียบเทียบผลลัพธ์ที่พิมพ์ออกมากับแอพอื่น ๆ ของแอพ

เพียงให้แน่ใจว่าได้ลบคำสั่งพิมพ์เมื่อคุณไปผลิต (หรือดีกว่าให้เปลี่ยนเป็นงบบันทึก)


467

งานของคุณคือการออกจากงาน

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

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

ที่น่าสนใจฉันพบว่าการมีเป้าหมายนั้นทำให้ฉันมีค่ามากขึ้นสำหรับนายจ้างของฉัน ยิ่งฉันพยายามทิ้งมากเท่าไหร่ฉันก็ยิ่งมีค่ามากขึ้นเท่านั้น


465

1) เรื่องราวของแอปทางธุรกิจ :

ฉันคิดว่ากรอบทั้งหมดของ "Enterprise" คือควันและกระจก J2EE, .NET, เฟรมเวิร์ก Apache ส่วนใหญ่และ abstractions ส่วนใหญ่ในการจัดการสิ่งต่าง ๆ นั้นสร้างความซับซ้อนมากกว่าที่พวกเขาแก้ไข

ใช้ Java หรือ. NET ORM ปกติหรือกรอบ MVC สมัยใหม่ที่คาดคะเนซึ่งอาจทำให้ "วิเศษ" เพื่อแก้ปัญหาที่น่าเบื่อและง่าย คุณต้องเขียน XML สำเร็จรูปน่าเกลียดจำนวนมากซึ่งยากต่อการตรวจสอบและเขียนอย่างรวดเร็ว คุณมี API ขนาดใหญ่ซึ่งครึ่งหนึ่งเป็นเพียงการรวมการทำงานของ API อื่นอินเทอร์เฟซที่เป็นไปไม่ได้ที่จะรีไซเคิลและคลาสนามธรรมที่จำเป็นเท่านั้นเพื่อเอาชนะความยืดหยุ่นของ Java และ C # เราไม่ต้องการสิ่งนั้นมากที่สุด

แอปพลิเคชั่นเซิร์ฟเวอร์ที่แตกต่างกันทั้งหมดที่มีไวยากรณ์ตัวอธิบาย darned ของตัวเองฐานข้อมูลที่ซับซ้อนมากเกินไปและผลิตภัณฑ์กรุ๊ปแวร์เป็นอย่างไร

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

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

2) n-years-of-experience-required:

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

3) หลักสูตรปริญญา "วิทยาศาสตร์คอมพิวเตอร์" ทั่วไป:

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


439

Getters และ Setters ใช้มากเกินไป

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

ฉันไม่ได้อยู่ในความโปรดปรานของเขตข้อมูลสาธารณะ แต่ต่อต้านการทำทะเยอทะยาน / setter (หรือทรัพย์สิน) สำหรับทุกคนแล้วอ้างว่าการทำเช่นนั้นคือการห่อหุ้มหรือซ่อนข้อมูล ... ฮ่า!

UPDATE:

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

ก่อนอื่น: ใครก็ตามที่ใช้พื้นที่สาธารณะควรได้รับโทษจำคุก

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

หลายคนคิดว่า:

private fields + public accessors == encapsulation

ฉันพูดว่าการสร้าง getter / setter pair (โดยอัตโนมัติหรือไม่) สำหรับสาขาของคุณมีประสิทธิภาพตรงข้ามกับการห่อหุ้มที่เรียกว่าคุณกำลังพยายามที่จะบรรลุ

สุดท้ายให้ฉันพูดถึงลุงบ๊อบในหัวข้อนี้ (นำมาจากบทที่ 6 ของ "รหัสสะอาด"):

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



381

ความคิดเห็น: SQL คือรหัส ปฏิบัติต่อมันเช่น

นั่นคือเช่นเดียวกับ C #, Java หรือภาษาออบเจ็กต์ / โพรซีเดอร์ที่โปรดปรานอื่น ๆ ของคุณพัฒนารูปแบบการจัดรูปแบบที่สามารถอ่านและบำรุงรักษาได้

ฉันเกลียดเมื่อฉันเห็นโค้ด SQL ที่มีรูปแบบไม่แน่นอน หากคุณกรีดร้องเมื่อคุณเห็นวงเล็บปีกกาทั้งสองหน้าทำไมหรือทำไมคุณถึงไม่กรี๊ดเมื่อคุณเห็น SQL หรือ SQL ที่จัดรูปแบบฟรีซึ่งบดบังหรือทำให้เงื่อนไขเข้าร่วมยุ่งเหยิง?


354

ความสามารถในการอ่านเป็นสิ่งสำคัญที่สุดสำหรับโค้ดของคุณ

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


342

หากคุณเป็นนักพัฒนาคุณควรจะสามารถเขียนรหัสได้

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

เนื่องจาก Pi สามารถประมาณได้โดยใช้ฟังก์ชัน 4 * (1 - 1/3 + 1/5 - 1/7 + ... ) ด้วยเงื่อนไขเพิ่มเติมที่ให้ความแม่นยำมากกว่าเขียนฟังก์ชันที่คำนวณ Pi ถึงความแม่นยำ 5 ตำแหน่งทศนิยม .

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

เมื่อกำหนดพื้นที่ของวงกลมให้ Pi คูณด้วยรัศมียกกำลังสองให้เขียนฟังก์ชันเพื่อคำนวณพื้นที่ของวงกลม

น่าแปลกที่ผู้สมัครมากกว่าครึ่งไม่สามารถเขียนฟังก์ชั่นนี้ในภาษาใดก็ได้ (ฉันสามารถอ่านภาษายอดนิยมได้ดังนั้นฉันจึงอนุญาตให้พวกเขาใช้ภาษาที่เลือกได้รวมถึงรหัสหลอก) เรามี "นักพัฒนา C #" ที่ไม่สามารถเขียนฟังก์ชันนี้ใน C #

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


แก้ไข:

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

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


330

การใช้สัญกรณ์ฮังการีควรถูกลงโทษด้วยความตาย

ที่ควรจะเป็นความขัดแย้งพอ;)


287

รูปแบบการออกแบบกำลังทำร้ายการออกแบบที่ดีมากกว่าที่จะช่วย

การออกแบบซอฟต์แวร์ IMO โดยเฉพาะอย่างยิ่งการออกแบบซอฟต์แวร์ที่ดีนั้นมีความหลากหลายเกินกว่าที่จะบันทึกในรูปแบบโดยเฉพาะอย่างยิ่งในรูปแบบจำนวนน้อยที่ผู้คนจำได้จริง - และพวกเขาก็จำนามธรรมเกินกว่าที่จะจำได้มากกว่าหนึ่งคน ดังนั้นพวกเขาไม่ได้ช่วยอะไรมาก

ในทางกลับกันคนจำนวนมากเกินไปกลายเป็นคนที่หลงใหลในแนวคิดและพยายามใช้รูปแบบทุกที่ - โดยปกติแล้วในโค้ดผลลัพธ์คุณไม่สามารถหาการออกแบบที่แท้จริงระหว่าง Singletons (ไม่มีความหมายอย่างสมบูรณ์) และ Abstract Factories


274

รหัสน้อยดีกว่ามาก!

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



262

การทดสอบหน่วยจะไม่ช่วยให้คุณเขียนรหัสที่ดี

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

นอกจากนี้นักพัฒนาที่ดีจะทำงานร่วมกันต่ำซึ่งจะทำให้การเพิ่มรหัสใหม่ไม่น่าจะทำให้เกิดปัญหากับสิ่งที่มีอยู่

ในความเป็นจริงฉันจะพูดเรื่องนั้นต่อไป

มากที่สุด "วิธีปฏิบัติที่ดีที่สุด" ในวิศวกรรมซอฟต์แวร์จะมีการให้โปรแกรมเมอร์ที่ไม่ดีจากการทำความเสียหายมากเกินไป

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


256

เขียนวิธีการขนาดเล็ก ดูเหมือนว่าโปรแกรมเมอร์ชอบที่จะเขียนวิธีการ loooong ที่พวกเขาทำสิ่งต่าง ๆ มากมาย

ฉันคิดว่าควรสร้างวิธีการทุกที่ที่คุณสามารถตั้งชื่อ


235

มันก็โอเคที่จะเขียนรหัสขยะนาน ๆ ครั้ง

บางครั้งรหัสขยะที่รวดเร็วและสกปรกก็เป็นสิ่งที่จำเป็นสำหรับการทำภารกิจให้สำเร็จ รูปแบบ ORMs SRP อะไรก็ได้ ... โยน Console หรือ Web App เขียน sql แบบอินไลน์ (ให้ความรู้สึกดี) และทำลายความต้องการ


196

รหัส == ออกแบบ

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


ที่นี่บทความในหัวข้อของรหัสได้รับการออกแบบ


186

การพัฒนาซอฟต์แวร์เป็นเพียงงาน

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

แต่ในรูปแบบที่ยิ่งใหญ่ของสิ่งต่าง ๆ มันเป็นเพียงงาน

มันมีความสำคัญต่ำกว่าหลายสิ่งหลายอย่างเช่นครอบครัวแฟนเพื่อนความสุข ฯลฯ และด้านล่างสิ่งอื่น ๆ ที่ฉันอยากทำถ้าฉันมีเงินสดไม่ จำกัด เช่นขี่มอเตอร์ไซค์เรือยอชต์หรือสโนว์บอร์ด

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


184

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

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


180

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


164

สถาปนิก / นักออกแบบซอฟต์แวร์มีขนาดใหญ่เกินไป

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

เป็นวิธีการที่ขัดแย้ง?

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


152

ไม่มี "หนึ่งขนาดเหมาะกับทุกคน" วิธีการพัฒนา

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

สิ่งที่ผมเคยเห็นที่ถูกขนานนามว่าเป็นแนวทางที่ถูกต้องสำหรับการใด ๆโครงการ - ก่อนที่ข้อมูลใด ๆ ที่เป็นที่รู้จักกันเกี่ยวกับมัน - เป็นสิ่งที่ต้องการการใช้งานของการทดสอบขับเคลื่อนการพัฒนา (TDD) ที่ Domain ขับเคลื่อนการออกแบบ (DDD) วัตถุสัมพันธ์แมป (ออม) , Agile (เมืองหลวง A), การวางแนววัตถุ (OO) ฯลฯ ฯลฯ ครอบคลุมทุกอย่างตั้งแต่วิธีการจนถึงสถาปัตยกรรมไปจนถึงส่วนประกอบ ทั้งหมดนี้มีคำย่อของตลาดที่ดีแน่นอน

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

มันไม่ใช่

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.