ให้การนำเสนอเกี่ยวกับ "รูปแบบโค้ดและรูปแบบการออกแบบ" [ปิด]


9

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

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

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

มีบางอย่างผิดปกติกับรหัสของเรา (PHP) รวมถึง:

  • OO น้อยที่สุด มันได้รับการปรับปรุงเมื่อเร็ว ๆ นี้ แต่ยังมีฟังก์ชั่นระดับโลกมากมาย ฉันใช้เวลาสักครู่เพื่อค้นหาสิ่งต่าง ๆ
  • กำหนดค่าทั่วโลก (ความคิดเห็นที่ฉันเดา) คุณสามารถค้นหา $ GLOBALS ['blah'] กระจัดกระจายได้ในทุก ๆ ไฟล์
  • สไตล์รั้งไม่สอดคล้องกัน ฟังดูน้อย แต่สิ่งนี้จริง ๆ แล้วทำให้เกิดข้อผิดพลาดทางไวยากรณ์ที่จะถูกส่งเมื่อ 5 วันก่อนซึ่งยังไม่ได้รับการแก้ไขเมื่อวานนี้
  • โครงสร้างที่ไม่มีประสิทธิภาพ ฉันสามารถทำการปรับปรุงขั้นพื้นฐานบางอย่างซึ่งลดเวลาในการทำงานในบางพื้นที่ลง 70%

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


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

คำตอบ:


8

ระมัดระวังเป็นอย่างยิ่งโดยใช้รหัสจริงในงานนำเสนอต่อหน้าผู้ที่เขียนรหัสนี้

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

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

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


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

4

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

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


2

"ยังมีฟังก์ชั่นระดับโลกมากมาย"

ก่อนอื่นรับรายการ สมบูรณ์แบบเป็นอุดมคติ

ประการที่สองแบ่งรายการนี้เป็นคลาสที่มีศักยภาพ นึกถึงคำจำกัดความของชั้นเรียน

ในระหว่างการนำเสนอที่เกิดขึ้นจริงให้เลือกชั้นเรียนที่มีศักยภาพที่ใหญ่ที่สุดชัดเจนและชัดแจ้งมากที่สุดและมีข้อโต้แย้งน้อยที่สุดที่จะรับฟังก์ชั่นระดับโลกเหล่านั้น

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

จากนั้นหลังจากคุยเรื่องนี้ถึงจุดที่พวกเขาเข้าใจเพียงแค่ชั้นเรียนนี้และวิธีที่คุณมาถึงเนื้อหา ....

เปิดโปรเจ็กเตอร์

เริ่มพิมพ์

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

รูปแบบการออกแบบและรูปแบบการเขียนโปรแกรม ทั้งหมดในแพ็คเกจเดียว


2

ใน 1 ชั่วโมงคุณจะทำได้ดีในการทำความเข้าใจพื้นฐานขั้นต่ำที่เปลือยเปล่า

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

หัวข้อที่แนะนำ:

  • สไตล์การเข้ารหัส

    • The Zen of OOP ใน PHP: การเข้ารหัสด้วยสไตล์!
    • 5 เหตุผลที่ฟังก์ชั่นทั่วโลกทำให้เกิดโรคมะเร็งรหัส
    • ในชื่ออะไร อนุสัญญาและสามัญสำนึก (หรืออย่าทำให้ฉันคิดว่า)
  • รูปแบบการออกแบบ

    • รูปแบบ GoF บางอย่างในประมวลจริยธรรมของเรา; การแนะนำ
    • รูปแบบเป็นเพียงเครื่องมือไม่ใช่พระวรสาร
    • ดีที่สุดและแย่ที่สุด: รูปแบบและรูปแบบต่อต้าน

หมายเหตุ: การกำหนดค่าส่วนกลางบางครั้งก็ยากที่จะหลีกเลี่ยง วิธีการรักษาอย่างหนึ่งที่ง่ายคือการใส่การอ้างอิงทั้งหมดไว้ในฟังก์ชัน init

ข้อแม้: ฉันรู้ PHP เพียงพอที่จะทำลาย wordpress และทำการแก้ไขเว็บไซต์เล็กน้อย


1

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


0

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

แสดงรหัสที่ไม่ดีถามพวกเขาเกี่ยวกับสิ่งที่ไม่ดี ให้พวกเขาคิดกันสักครู่แล้วค่อยให้ "Aaahaaa!" ช่วงเวลาโดยแสดงให้พวกเขาเห็นกรณีขอบ (ปัญหารั้วรั้วอาจ?) หรือกรณีที่การออกแบบที่ไม่ดีของพวกเขาทรุดตัวลงทุกอย่างอื่น

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

ทำในวิธีที่ตลกขบขันเพื่อดึงดูดพวกเขาแทนที่จะทำให้พวกเขาเบื่อหรือทำให้พวกเขาเข้ารับตำแหน่งการป้องกัน ตัวอย่างเช่นแสดงฟังก์ชั่นที่ใช้งานได้ในสองขั้นตอน (1- ป้อนชื่อภรรยา) (เก็บ 2 รายการในระดับโลก) (ป้อนชื่อสามี 3 ครั้งและใช้ชื่อภรรยาจากทั่วโลกเพื่อจัดเก็บในฐานข้อมูล) (หัวเราะ 4) ผลการซิงโครไนซ์ที่ไม่ดีในผู้ชายที่มีภรรยา 'ใหม่') เป็นเรื่องตลกที่เสนอให้เขียนฟังก์ชันสถิติการหย่าร้าง

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

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

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