วิธีชักชวนโปรแกรมเมอร์ให้ปฏิบัติตามกฎพื้นฐาน

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

• กำลังคอมมิตการเปลี่ยนแปลง
• ไม่ได้เขียนปัญหาเกี่ยวกับตัวแบบใน View or Controllers
• หลีกเลี่ยงการเข้ารหัส

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

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

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

เพื่อให้สามารถปฏิบัติตามกฎพื้นฐานพวกเขาจำเป็นต้องรู้ว่ากฎคืออะไรและพวกเขาจำเป็นต้องเห็นด้วยกับพวกเขา

วิธีจัดการกับสิ่งนี้คือการสร้างเอกสารแนวทางการเข้ารหัสที่ทุกคนสามารถเห็นด้วย อย่าพยายามบังคับสิ่งนี้กับพวกเขามันจะย้อนกลับมาหากคุณทำ

เพื่อให้ทีมทำงานร่วมกันและเริ่มทำงานกับคำจำกัดความทั่วไปของกฎพื้นฐานของคุณ!

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

แนวทางเหล่านี้ควรเปลี่ยนไปเมื่อใดก็ตามที่ทีมรู้สึกว่ามีบางสิ่งที่ควรเพิ่มหรือชี้แจง

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

มันจะไม่เป็นสวิตช์เวทมนต์ที่คุณสามารถเปิดได้ มันจะเป็นกระบวนการที่ช้าและจะไม่เป็น 100% นั่นคือประสบการณ์ของฉันอย่างไรก็ตาม

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

นี่เป็นกลยุทธ์บางส่วนของฉัน:

กระทำการเปลี่ยนแปลง:

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

นักพัฒนาส่วนใหญ่ที่ฉันรู้มีความสุขมากกว่าที่จะตรวจสอบในรหัสถ้า:

• กระบวนการเช็คอินนั้นง่าย
• กระบวนการซิงโครไนซ์เป็นเรื่องง่าย (แยกจากการเปลี่ยนแปลงจากผู้พัฒนารายอื่น)
• การดูการเปลี่ยนแปลงและการย้ายระหว่างเวอร์ชันเป็นเรื่องง่าย

สิ่งหนึ่งที่ฉันสังเกตเห็นเมื่อเร็ว ๆ นี้คือเช็คอินนั้นบ่อยขึ้นและเจ็บปวดน้อยลงเมื่อเราส่งต่อไปยังเครื่องมือ CM ใหม่ ทีมของเราเป็นผู้บุกเบิก Rational Team Concert ก่อนหน้านี้เคยใช้ Clearcase ฉันไม่ได้ตั้งใจที่จะโฆษณาเครื่องมือ แต่คลื่นเช็คอินสตรีมมิ่งใหม่ (สำหรับฉัน) ที่มีการผสานเล็ก ๆ และรวดเร็วจำนวนมากทำให้การเช็คอินเร็วขึ้นและบ่อยขึ้น

การปล่อยให้นักพัฒนารับผิดชอบการกำจัดความเจ็บปวด CM โดยทั่วไปจะเพิ่มจำนวนการเช็คอินที่เกิดขึ้น

ยึดมั่นในสถาปัตยกรรม - ไม่เขียนปัญหาแบบในมุมมองและตัวควบคุม

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

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

หลีกเลี่ยงการ Hardcoding

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

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

โดยทั่วไปแล้ว

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

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

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

ตรวจสอบรหัส ยอมรับโค้ดที่เขียนได้ดีเท่านั้นซึ่งไม่มีข้อผิดพลาด

อย่างน้อย :

• ทำให้ง่ายขึ้นสำหรับพวกเขาที่จะติดตาม codelines (เครื่องมือเช่น resharper, StyleCop) หากเป็นเรื่องง่ายพวกเขามีแนวโน้มที่จะนำมาใช้

นอกเหนือจากนั้นเลือกสิ่งที่ทำงานตามองค์กรของคุณนักพัฒนาและบทบาทของคุณภายในทีม

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

บทบาทของฉันคือผู้จัดการ แต่ในฐานะทีมเล็กฉันพัฒนาและฉันชอบที่จะจัดการในฐานะโค้ช

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

ฉันจะดูเครื่องมือเหล่านั้นทั้งหมดและฉันยังคงเปิดให้ผู้อื่นที่คุณบอกฉัน

มี 3 วิธีที่เราแก้ไขปัญหานี้:

1. การวิเคราะห์แบบคงที่ของรหัสที่มาเพื่อตรวจสอบปัญหาเกี่ยวกับการเขียนโปรแกรมการประชุม ใช้เครื่องมือเช่นcppcheckและผู้ที่มาจากgrammatech วิกิพีเดียมีรายการดี: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis โดยทั่วไประบบควบคุมแหล่งข้อมูลส่วนใหญ่จะมี hooks ซึ่งคุณสามารถตรวจสอบปัญหาดังกล่าวได้โดยตรงในระหว่างการเช็คอิน สำหรับ CVS ตะขอมองเข้าไปที่ลิงค์นี้: http://goo.gl/F1gd2 ความล้มเหลวในการปฏิบัติตามหมายถึงการเช็คอินที่ล้มเหลวและความล้มเหลวมากกว่า 3 รายการหมายความว่าผู้พัฒนาต้องอธิบายตนเองกับทีม

2. ในระหว่างขั้นตอนการเข้ารหัสตัวเองทำเครื่องหมายปัญหาให้กับนักพัฒนา การมีสคริปต์ที่กำหนดเองที่รวมเข้ากับ IDE ที่คุณเลือกเป็นวิธีที่ยอดเยี่ยมในการทำเช่นนี้ ตรวจสอบลิงค์นี้: http://goo.gl/MM6c4

3. ติดตามกระบวนการที่คล่องตัวและตรวจสอบให้แน่ใจว่าการตรวจสอบโค้ดเป็นส่วนหนึ่งของการวิ่ง

นี่คือแผน 3 ขั้นตอนของฉัน:

1. ไฟโปรแกรมเมอร์
2. จ้างวิศวกรซอฟต์แวร์บางคน
3. ...
4. กำไร!

: D

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

1. อย่าชี้ไปที่พวกเขาเมื่อพวกเขาละเมิดกฎพื้นฐาน
2. รอให้พวกเขาสร้างบั๊กที่พวกเขาไม่สามารถติดตามหรือเผชิญหน้ากับคำขอคุณลักษณะที่พวกเขาไม่สามารถใช้งานได้เนื่องจากรหัสที่ยืดหยุ่น
3. เตือนพวกเขาถึงสิ่งที่คุณพูดไว้ก่อนหน้านี้
4. ปล่อยให้พวกเขาจมน้ำตายเป็นระยะเวลานาน
5. ใช้เวลาในการปรับเปลี่ยนรหัสที่เป็นปัญหาแยกข้อบกพร่อง / ให้อินทราเน็ตเพื่อเชื่อมต่อกับฟังก์ชั่นใหม่ ใช้เวลาอธิบายสิ่งที่คุณทำ

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

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

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

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

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

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

มันค่อนข้างน้อย แต่ฉันทิ้ง Code Complete ไว้ในห้องน้ำสองสามเดือน ไม่แน่ใจว่ามันมีประสิทธิภาพ แต่ดูเหมือนว่าเป็นความคิดที่ดีในเวลานั้น

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

หรือยิงผู้กระทำความผิดที่เลวร้ายที่สุดและปล่อยให้ส่วนที่เหลือเหงื่อออก

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

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

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

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

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

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

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

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