อะไรคือความสมดุลที่เหมาะสมระหว่างความสอดคล้องของรหัสและการปรับปรุงรหัส


53

เมื่อเร็ว ๆ นี้ฉันได้พูดคุยกับเพื่อนร่วมงานเกี่ยวกับรูปแบบโค้ด เขาได้โต้แย้งว่าการใช้งาน API และรูปแบบทั่วไปที่คุณใช้ควรคล้ายกันมากที่สุดกับรหัสที่ล้อมรอบหากไม่ได้ใช้ codebase โดยรวมเช่นเดียวกับที่คุณใช้กับการปรากฏตัวของโค้ด . ตัวอย่างเช่นถ้าฉันเพิ่มวิธีไปยังคลาส DAO ใน C # ฉันจะลองใช้ LINQ ที่เหมาะสมเพื่อช่วยให้รหัสของฉันสะอาดและง่ายต่อการบำรุงรักษาแม้ว่าจะไม่มีวิธีการอื่นในชั้นเรียนที่ใช้มันอยู่ อย่างไรก็ตามเพื่อนร่วมงานของฉันจะโต้แย้งว่าฉันไม่ควรใช้มันในกรณีนั้นเพราะมันจะขัดกับสไตล์ที่มีอยู่ของคลาสนั้นและยากที่จะเข้าใจ

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

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

ดังนั้นรูปแบบส่วนใดของรูปแบบโค้ดและขอบเขตที่เราควรวาดเส้นระหว่างการคงเส้นคงวาและการปรับปรุง


14
ดังนั้นคุณภาพของรหัสจะดีขึ้นอย่างไรถ้าทุกคน จำกัด ตนเองในทางที่ "ไม่ดี"?
Izkata


เมื่อคุณเขียน LINQ คุณไม่ได้หมายถึง LINQ กับ SQL หรือไม่ ถ้าใช่ฉันเห็นด้วยกับเพื่อนของคุณ หากคุณกำลังพูดถึง LINQ ฉันไม่เห็นด้วยกับเขา ทุกคนต้องคุ้นเคยกับ LINQ ทุกวันนี้ มันไม่ใช่ทางเลือกของพวกเขา พวกเขาจะได้รับการจ่ายเพื่อให้คุ้นเคย
Piotr Perak

@Peri ฉันหมายถึงพื้นฐาน LINQ - ฉันเดาว่าตัวอย่างของฉันควรเกี่ยวกับการทำงานกับIEnumerables มากกว่า DAO
Robert Johnson

2
ICYMI - การ์ตูน Dilbert ในหัวข้อนี้มาก: dilbert.com/strips/2013-09-21
Jim Bethancourt

คำตอบ:


53

เพื่อให้คำตอบทั่วไปมากขึ้น:

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

  • วิธีการ "ถูกต้อง" มีประโยชน์อย่างไร?

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

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

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

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


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

1
@ จอร์โจขอบคุณสำหรับข้อเสนอแนะ; ฉัน tweaked ภาษาของจุดสุดท้าย

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

+1 ตกลงคำตอบอย่างละเอียดและสมดุล - การพิจารณาสถานการณ์ในหลากหลายสถานการณ์ อีกครั้งความคิดเห็นที่ดีจากจอร์โจ
Robert Johnson

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

26

การอยู่อย่างสม่ำเสมอมีคุณค่าเพียงเล็กน้อยในมุมมองของฉัน การปรับปรุงอย่างต่อเนื่องเป็นสิ่งจำเป็น

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

ฉันควรจะมีความไม่สอดคล้องกันซึ่งบางรหัสยังคงใช้foreachกับ ArrayLists และส่วนอื่น ๆ ใช้ LINQ IEnumerable<T>แทนการเกาะติดกับวิธีการที่เก่าแก่ที่สุดในการทำสิ่งต่าง ๆ จนกว่าจะหมดเวลา

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


3
"เป็นความรับผิดชอบของเพื่อนร่วมงานที่จะต้องรักษาความสัมพันธ์และเรียนรู้วิธีการทำสิ่งต่าง ๆ ": ความเป็นไปได้คือการใช้สำนวนและไลบรารี่ใหม่ในโค้ดใหม่ (โมดูลใหม่) และรักษาสไตล์ที่สอดคล้องกันในรหัสดั้งเดิม
Giorgio

8

ความสอดคล้องของ API มีความสำคัญมากทั้งสำหรับ API สาธารณะและภายใน

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

แบบแผนการตั้งชื่อควรสอดคล้องกันเช่นเดียวกับตัวแปรในท้องถิ่น ฯลฯ

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

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


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

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


6

คำตอบนี้ง่าย

ความสอดคล้องมีความสำคัญยิ่ง

แต่มันมาพร้อมกับข้อแม้ ...

คุณและเพื่อนร่วมงานของคุณกำลังหมกมุ่นอยู่กับความมั่นคงที่ผิดประเภท

การใช้งานจะถูกทิ้ง พวกเขาสามารถซ่อมแซมได้อย่างสมบูรณ์ด้วยองศาความสะดวกที่แตกต่างกันขึ้นอยู่กับคุณภาพและความครอบคลุมของชุดทดสอบ กังวลเกี่ยวกับสิ่งต่าง ๆ เช่น "ควรเป็นทรัพย์สินหรือไม่", "ไม่ควรใช้รหัส LININ แทนที่จะเป็นโครงสร้างระดับล่าง" มีคุณค่าน่าสงสัย มันยากที่จะผูกการวัดใด ๆ กับค่าของความสอดคล้องในระดับการใช้งาน คำถามที่ดีกว่าที่จะถามในระดับนี้คือ "รหัสนี้ทำงานตามที่โฆษณาไว้หรือไม่" TL; DR ความสอดคล้องในการใช้งานเป็นที่ "ใจน้อย" เปิดรับ hobgoblin

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

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

API ไม่ได้ทิ้ง

นี่คือระดับรหัส APIs ทั้งหมด, บริการบนเว็บ, SDK เป็นต้นซึ่งจะต้องต้องสอดคล้องกัน ผลผลิตที่เพิ่มขึ้นจากความสอดคล้องที่หลากหลายนี้มีมากมายมหาศาลด้วยเหตุผลหลายประการ:

การทดสอบการรวม:

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

ผลผลิต

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

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

ข้อสรุป

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

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

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


4

ไม่คุ้นเคยกับ LINQ ใช่ไหม ถ้าเป็นเช่นนั้นรหัสของฉันจะไม่สามารถรักษาได้สำหรับเพื่อนนักพัฒนาของฉันถ้าฉันไม่ได้ใช้?

ภาษา C # ยังคงพัฒนาอยู่ หากผู้คนไม่ได้เรียนรู้การเปลี่ยนแปลงจาก C # 1 พวกเขาจะพลาด:

  • generics
  • partials
  • วิธีการที่ไม่ระบุชื่อ
  • iterators
  • ประเภทที่ทำให้เป็นโมฆะ
  • -คุณสมบัติอัตโนมัติ
  • ประเภทนิรนาม
  • วิธีการขยาย
  • ปลาทะเลชนิดหนึ่ง
  • lambdas
  • วิธีการแบบอะซิงโครนัส

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

Linq ทำให้ชีวิตง่ายขึ้น ใช้ที่ที่คุณสามารถ คุณอาจกระตุ้นให้สมาชิกในทีมของคุณ

ดังนั้นรูปแบบส่วนใดของรูปแบบโค้ดและขอบเขตที่เราควรวาดเส้นระหว่างการคงเส้นคงวาและการปรับปรุง

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


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

@ RobertJohnson ฉันจะชี้ให้เพื่อนร่วมงานของคุณเห็นว่าการบำรุงรักษานั้นสำคัญกว่าความสม่ำเสมอดังนั้นแม้ว่าบางสิ่ง "ขัดกับธัญพืช" ของรหัสที่มีอยู่หากสามารถรักษาได้ดีกว่าคุณควรทำ ฉันสงสัยว่าการใช้ DAO แบบเก่าจะสามารถบำรุงรักษาได้ดีกว่า Linq
Andy

3

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

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

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


1

ฉันคิดว่ามันสำคัญที่จะต้องติดตามสไตล์โค้ดในโครงการเช่น การตั้งชื่ออนุสัญญาเยื้อง ฯลฯ

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

แน่นอนสิ่งเหล่านี้ควรมีเหตุผลที่ดีสำหรับการใช้พวกเขาเช่น ประสิทธิภาพหรือความกะทัดรัดหากเหมาะสม


เครื่องหมายลบคืออะไร
ozz

0

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

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

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

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


-1

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


การลงคะแนนเสียงคืออะไร
Ant

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

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