คำถามติดแท็ก clean-code

ฉันจะบอกได้อย่างไรว่าซอฟต์แวร์ของฉันมีสิ่งที่เป็นนามธรรมมากเกินไปและมีรูปแบบการออกแบบมากเกินไปหรือในทางกลับกันฉันจะรู้ได้อย่างไรว่าควรมีซอฟต์แวร์มากกว่านั้น นักพัฒนาที่ฉันทำงานด้วยกำลังเขียนโปรแกรมต่าง ๆ เกี่ยวกับประเด็นเหล่านี้ บางฟังก์ชั่นเป็นนามธรรมทุกฟังก์ชั่นเล็กน้อยใช้รูปแบบการออกแบบทุกที่ที่เป็นไปได้ คนอื่นรวมถึงฉันพยายามที่จะใช้ประโยชน์ได้มากขึ้นและเขียนโค้ดที่ไม่เหมาะกับทุกรูปแบบการออกแบบ แต่เป็นวิธีที่เข้าใจได้เร็วขึ้นเพราะใช้นามธรรมน้อยกว่า ฉันรู้ว่านี่เป็นการแลกเปลี่ยน ฉันจะบอกได้อย่างไรว่ามีสิ่งที่เป็นนามธรรมเพียงพอในโครงการและฉันจะรู้ได้อย่างไรว่ามันต้องการมาก ตัวอย่างเมื่อเลเยอร์แคชทั่วไปถูกเขียนโดยใช้ Memcache เราจำเป็นต้องจริงๆMemcache, MemcacheAdapter, MemcacheInterface, AbstractCache, CacheFactory, CacheConnector... หรือคือง่ายต่อการรักษาและยังคงรหัสที่ดีเมื่อใช้เพียงครึ่งหนึ่งของชั้นเรียนเหล่านั้นหรือไม่ พบสิ่งนี้ใน Twitter: ( https://twitter.com/rawkode/status/875318003306565633 )

29 design-patterns  architecture  clean-code  abstraction  architectural-patterns 

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

29 code-quality  refactoring  clean-code  technical-debt 

เรียกดูรหัสบางส่วนที่ฉันเขียนฉันเจอโครงสร้างต่อไปนี้ซึ่งทำให้ฉันคิด เพียงแวบแรกดูเหมือนว่าสะอาดเพียงพอ ใช่ในรหัสจริงgetLocation()เมธอดมีชื่อเฉพาะที่มากกว่าเล็กน้อยซึ่งจะอธิบายตำแหน่งที่ได้รับได้ดีกว่า service.setLocation(this.configuration.getLocation().toString()); ในกรณีserviceนี้เป็นตัวแปรอินสแตนซ์ของชนิดที่รู้จักประกาศภายในวิธีการ this.configurationมาจากการถูกส่งผ่านไปในการสร้างคลาสและเป็นตัวอย่างของชั้นเรียนใช้อินเตอร์เฟซที่เฉพาะเจาะจง (ซึ่งเอกสารสาธารณะgetLocation()วิธีการ) ดังนั้นชนิดการคืนค่าของนิพจน์this.configuration.getLocation()จึงเป็นที่รู้จัก โดยเฉพาะในกรณีนี้ก็คือjava.net.URLในขณะที่ต้องการservice.setLocation() Stringเนื่องจากทั้งสองประเภทเป็นสตริงและ URL เข้ากันไม่ได้โดยตรงจึงจำเป็นต้องมีการแปลงบางประเภทเพื่อให้พอดีกับหมุดสี่เหลี่ยมในรูกลม อย่างไรก็ตามตามกฎหมายของ Demeter เป็นที่อ้างถึงในรหัสสะอาด , วิธีฉระดับCเท่านั้นที่ควรจะเรียกวิธีการในCวัตถุที่สร้างขึ้นโดยหรือผ่านอาร์กิวเมนต์ไปที่Fและวัตถุที่จัดขึ้นในตัวแปรเช่นของC อะไรก็ตามที่เกินกว่านั้น (สุดท้ายtoString()ในกรณีเฉพาะของฉันด้านบนเว้นแต่คุณจะพิจารณาวัตถุชั่วคราวที่สร้างขึ้นอันเป็นผลมาจากวิธีการภาวนาตัวเองซึ่งในกรณีนี้กฎหมายทั้งหมดดูเหมือนว่าจะเป็นข้อสงสัย) ไม่ได้รับอนุญาต มีเหตุผลที่ถูกต้องหรือไม่ทำไมการโทรในลักษณะดังกล่าวข้างต้นเนื่องจากมีข้อ จำกัด ในรายการควรจะหมดกำลังใจหรือไม่ได้รับอนุญาต? หรือฉันแค่เป็นคนเก็บไม้จิ้มฟันมากเกินไป? ถ้าผมจะใช้วิธีการURLToString()ซึ่งก็เรียกtoString()บนURLวัตถุ (เช่นที่ส่งกลับโดยgetLocation()) ผ่านไปเป็นพารามิเตอร์และผลตอบแทนผลที่ฉันสามารถห่อgetLocation()โทรในนั้นเพื่อให้บรรลุผลตรงเดียวกัน ได้อย่างมีประสิทธิภาพฉันจะย้ายการแปลงออกไปหนึ่งก้าว มันจะทำให้เป็นที่ยอมรับหรือไม่? ( ดูเหมือนว่าสำหรับฉันอย่างสังหรณ์ใจว่ามันไม่ควรสร้างความแตกต่างในทางใดทางหนึ่งเนื่องจากสิ่งที่ทำคือเคลื่อนย้ายสิ่งต่าง ๆ ไปรอบ ๆ อย่างไรก็ตามตามจดหมายของกฎหมายของ Demeter ตามที่อ้างถึงมันจะเป็นที่ยอมรับตั้งแต่ฉัน จะทำงานโดยตรงบนพารามิเตอร์ของฟังก์ชัน) มันจะสร้างความแตกต่างหรือไม่ถ้าสิ่งนี้เกี่ยวกับสิ่งที่แปลกใหม่กว่าการโทรtoString()แบบมาตรฐาน เมื่อตอบรับโปรดจำไว้ว่าการเปลี่ยนแปลงพฤติกรรมหรือ API ของประเภทที่serviceตัวแปรนั้นไม่สามารถนำไปใช้ได้จริง นอกจากนี้เพื่อเหตุผลของการโต้แย้งสมมติว่าการเปลี่ยนประเภทการส่งคืนของgetLocation()ยังทำไม่ได้

23 language-agnostic  clean-code 

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

22 performance  clean-code  definition 

การทำซ้ำข้อมูลระหว่างการทดสอบและรหัสจริงดีหรือไม่ดี ตัวอย่างเช่นสมมติว่าฉันมีคลาส Python FooSaverที่บันทึกไฟล์ด้วยชื่อเฉพาะลงในไดเรกทอรีที่กำหนด: class FooSaver(object): def __init__(self, out_dir): self.out_dir = out_dir def _save_foo_named(self, type_, name): to_save = None if type_ == FOOTYPE_A: to_save = make_footype_a() elif type == FOOTYPE_B: to_save = make_footype_b() # etc, repeated with open(self.out_dir + name, "w") as f: f.write(str(to_save)) def save_type_a(self): self._save_foo_named(a, "a.foo_file") def save_type_b(self): …

20 unit-testing  coding-style  clean-code 

กฎ 3 ( กฎ 5ในมาตรฐาน c ++ ใหม่): หากคุณต้องการประกาศตัว Destructor ให้คัดลอก Constructor หรือตัวดำเนินการกำหนดค่าด้วยตนเองอย่างชัดเจนคุณอาจต้องประกาศทั้งสามอย่างชัดเจน แต่ในทางกลับกัน " รหัสสะอาด " ของ Martin แนะนำให้ลบตัวสร้างและตัวทำลายที่ว่างเปล่าทั้งหมด (หน้า 293, G12: ความยุ่งเหยิง ): สิ่งที่ใช้เป็นตัวสร้างเริ่มต้นโดยไม่มีการใช้งาน? สิ่งที่มันทำคือถ่วงโค้ดด้วยส่วนที่ไม่มีความหมาย ดังนั้นวิธีจัดการกับทั้งสองความคิดเห็นที่ตรงกันข้าม? ควรใช้ตัวสร้าง / ตัวทำลายที่ว่างเปล่าจริงหรือไม่? ตัวอย่างถัดไปแสดงให้เห็นถึงสิ่งที่ฉันหมายถึง: #include <iostream> #include <memory> struct A { A( const int value ) : v( new int( value ) …

20 c++  clean-code  rule-of-three 

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

19 programming-languages  programming-practices  clean-code 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา นี่คือมากตัวอย่างง่าย นี่ไม่ใช่คำถามเฉพาะภาษาและฉันขอให้คุณเพิกเฉยต่อวิธีการอื่น ๆ ที่สามารถเขียนฟังก์ชันและการเปลี่ยนแปลงที่เกิดขึ้นได้ . สีเป็นประเภทที่ไม่ซ้ำกัน string CanLeaveWithoutUmbrella() { if(sky.Color.Equals(Color.Blue)) { return "Yes you can"; } else { return "No you can't"; } } ผู้คนจำนวนมากที่ฉันได้พบ ReSharper และผู้ชายคนนี้ (ซึ่งความคิดเห็นเตือนฉันฉันกำลังมองหาที่จะถามในขณะนี้) จะแนะนำการ refactoring รหัสเพื่อลบelseบล็อกออกจากนี้: (ฉันจำไม่ได้ว่าคนส่วนใหญ่พูดอะไรฉันอาจไม่ได้ถามอย่างอื่น) string CanLeaveWithoutUmbrella() { if(sky.Color.Equals(Color.Blue)) { return "Yes you can"; } return …

18 coding-style  code-quality  coding-standards  complexity  clean-code 

ฉันสืบทอดฐานรหัสที่มีอยู่สำหรับผลิตภัณฑ์ที่เลอะเทอะอย่างน่ากลัว การออกแบบขั้นพื้นฐานไม่เพียงพอพอสมควรซึ่งน่าเสียดายที่ฉันสามารถทำได้เพียงเล็กน้อยโดยไม่มี refactor ที่สมบูรณ์ (การเชื่อมต่อสูงการทำงานร่วมกันต่ำการทำซ้ำรหัสอาละวาดไม่มีเอกสารการออกแบบทางเทคนิคการทดสอบบูรณาการแทนการทดสอบหน่วย) ผลิตภัณฑ์มีประวัติการสัมผัสกับลูกค้าที่สำคัญ "เงินสดวัว" ที่มีความอดทนน้อยที่สุดสำหรับความเสี่ยงหนี้ทางเทคนิคที่จะทำให้ชาวกรีกหน้าแดงรหัสฐานขนาดใหญ่และความซับซ้อนมากและวิธีการพ่ายแพ้การสู้รบเหนื่อยล้าทีมก่อน ฉัน. ทีมเก่ากระโดดเรือไปยังอีกแผนกหนึ่งเพื่อให้พวกเขามีโอกาสทำลายโครงการอื่น เป็นเรื่องยากมากที่ฉันประสบกับความล้มเหลวทางเทคนิคของโครงการเมื่อเทียบกับความล้มเหลวในการจัดการโครงการ แต่นี่เป็นหนึ่งในกรณีเหล่านั้น สำหรับช่วงเวลาที่ฉันอยู่คนเดียว แต่ฉันมีเวลามากอิสระในการตัดสินใจและทิศทางในอนาคตและความสามารถในการสร้างทีมตั้งแต่เริ่มต้นเพื่อช่วยฉัน คำถามของฉันคือการรวบรวมความคิดเห็นเกี่ยวกับการรีแฟคเจอริ่งผลกระทบต่ำในโครงการเช่นนี้เมื่อคุณมีเวลาว่างระหว่างขั้นตอนการรวบรวมข้อกำหนดการทำงาน มีคำเตือนของคอมไพเลอร์หลายพันคำซึ่งเกือบทั้งหมดเป็นการอิมพอร์ตที่ไม่ได้ใช้ตัวแปรที่ไม่ได้อ่านที่ยังไม่อ่านการตรวจสอบชนิดและการส่งแบบไม่ปลอดภัย การจัดรูปแบบโค้ดนั้นอ่านไม่ได้และเลอะเทอะมากจนดูเหมือนว่า coder ได้รับความทุกข์จากโรค Parkinsons และไม่สามารถควบคุมจำนวนครั้งที่แถบพื้นที่ถูกกดบนบรรทัดที่กำหนด ฐานข้อมูลและทรัพยากรไฟล์เพิ่มเติมมักจะเปิดและไม่เคยปิดอย่างปลอดภัย อาร์กิวเมนต์วิธีที่ไม่มีจุดหมายวิธีการที่ซ้ำกันที่ทำสิ่งเดียวกัน ฯลฯ ในขณะที่ฉันกำลังรอข้อกำหนดสำหรับคุณสมบัติถัดไปฉันทำความสะอาดสิ่งที่มีความเสี่ยงต่ำที่มีผลกระทบต่ำเมื่อฉันไปและสงสัยว่าฉันกำลังเสียเวลาหรือทำสิ่งที่ถูกต้อง จะเกิดอะไรขึ้นถ้าคุณสมบัติใหม่หมายถึงการริปโค้ดที่ฉันใช้ไปก่อนหน้านี้? ฉันจะเริ่มต้นวิธีการแบบ Agile และฉันเข้าใจว่าสิ่งนี้เป็นที่ยอมรับและเป็นเรื่องปกติที่จะมีการปรับโครงสร้างอย่างต่อเนื่องในระหว่างการพัฒนาแบบ Agile คุณสามารถนึกถึงผลกระทบเชิงบวกหรือเชิงลบของฉันที่ทำสิ่งนี้ที่คุณต้องการเพิ่มหรือไม่?

17 language-agnostic  refactoring  clean-code 

ฉันได้พัฒนาซอฟต์แวร์ในช่วงสามปีที่ผ่านมา แต่ฉันเพิ่งตื่นขึ้นมาเมื่อไม่นานมานี้ว่าฉันเป็นคนที่มีแนวปฏิบัติที่ดี สิ่งนี้ทำให้ฉันเริ่มอ่านClean Codeของหนังสือซึ่งทำให้ชีวิตของฉันกลับมาดีขึ้น แต่ฉันพยายามดิ้นรนเพื่อให้เข้าใจถึงวิธีการที่ดีที่สุดในการเขียนโปรแกรมของฉัน ฉันมีโปรแกรม Python ที่ฉัน ... ใช้ argparse required=Trueเพื่อบังคับใช้สองอาร์กิวเมนต์ซึ่งเป็นทั้งชื่อไฟล์ ตัวแรกคือชื่อไฟล์อินพุตส่วนที่สองคือชื่อไฟล์เอาต์พุต มีฟังก์ชั่นreadFromInputFileที่ตรวจสอบก่อนเพื่อดูว่าชื่อไฟล์อินพุตถูกป้อน มีฟังก์ชั่นwriteToOutputFileที่ตรวจสอบก่อนเพื่อดูว่ามีการป้อนชื่อไฟล์เอาต์พุต โปรแกรมของฉันมีขนาดเล็กพอที่จะทำให้ฉันเชื่อว่าการตรวจสอบใน # 2 และ # 3 ซ้ำซ้อนและควรถูกลบออกจึงทำให้ทั้งสองฟังก์ชั่นพ้นจากifสภาพที่ไม่จำเป็น อย่างไรก็ตามฉันก็ถูกชักนำให้เชื่อว่า "การตรวจสอบซ้ำสองครั้งก็โอเค" และอาจเป็นคำตอบที่ถูกต้องในโปรแกรมที่สามารถเรียกใช้ฟังก์ชันได้จากตำแหน่งอื่นที่การแยกวิเคราะห์ของอาร์กิวเมนต์ไม่เกิดขึ้น (นอกจากนี้หากการอ่านหรือเขียนล้มเหลวฉันมีtry exceptในแต่ละฟังก์ชั่นเพื่อเพิ่มข้อความแสดงข้อผิดพลาดที่เหมาะสม) คำถามของฉันคือดีที่สุดที่จะหลีกเลี่ยงการตรวจสอบสภาพซ้ำซ้อนทั้งหมดหรือไม่ ควรตรรกะของโปรแกรมเป็นของแข็งที่ตรวจสอบต้องทำเพียงครั้งเดียว? มีตัวอย่างที่ดีที่แสดงถึงสิ่งนี้หรือการสนทนาหรือไม่? แก้ไข: ขอบคุณทุกคำตอบ! ฉันได้เรียนรู้บางอย่างจากแต่ละคน การได้เห็นมุมมองมากมายทำให้ฉันมีความเข้าใจที่ดีขึ้นเกี่ยวกับวิธีแก้ไขปัญหานี้และกำหนดวิธีการแก้ปัญหาตามความต้องการของฉัน ขอขอบคุณ!

16 clean-code  methodology 

ฉันกำลังอ่านโรเบิร์ตมาร์ตินรหัสสะอาด ฉันคิดว่ามันยอดเยี่ยมและเมื่อเขียนรหัส OO ฉันกำลังเรียนอยู่ในใจ โดยเฉพาะอย่างยิ่งฉันคิดว่าคำแนะนำของเขาในการใช้ฟังก์ชั่นเล็ก ๆ ที่มีชื่อที่มีความหมายทำให้โค้ดของฉันลื่นไหลได้อย่างราบรื่นมากขึ้น สรุปได้ดีที่สุดโดยคำพูดนี้: [W] e ต้องการให้สามารถอ่านโปรแกรมราวกับว่ามันเป็นชุดของย่อหน้า TO แต่ละอันจะอธิบายถึงระดับปัจจุบันของสิ่งที่เป็นนามธรรมและการอ้างอิงที่ตามมาถึงย่อหน้าในระดับถัดไป ( ทำความสะอาดรหัสหน้า 37: "TO วรรค" เป็นย่อหน้าที่เริ่มต้นด้วยประโยคที่เปล่งออกมาใน infinitive "ในการทำ X เราทำตามขั้นตอน Y และ Z" "เพื่อทำ Y เรา ... " ฯลฯ ) ตัวอย่างเช่น: หากต้องการ RenderPageWithSetupsAndTeardowns เราจะตรวจสอบว่าหน้าดังกล่าวเป็นหน้าทดสอบหรือไม่และหากเป็นเช่นนั้นเราได้รวมการตั้งค่าและการฉีกขาดไว้ด้วย ไม่ว่าในกรณีใดเราแสดงผลหน้าเว็บเป็น HTML ฉันยังเขียนรหัสการทำงานสำหรับงานของฉัน ตัวอย่างของมาร์ตินในหนังสืออ่านได้อย่างชัดเจนราวกับว่าเป็นชุดของย่อหน้าและชัดเจนมาก - แต่ฉันไม่แน่ใจว่า "การอ่านเหมือนชุดของย่อหน้า" เป็นคุณสมบัติที่พึงประสงค์สำหรับรหัสการทำงานที่มี . นำตัวอย่างออกจากไลบรารีมาตรฐาน Haskell : maximumBy …

16 design  functional-programming  clean-code 

เรามีสถานที่ค่อนข้างมากในซอร์สโค้ดของแอปพลิเคชันของเราที่คลาสหนึ่งมีวิธีการมากมายที่มีชื่อเดียวกันและพารามิเตอร์ที่แตกต่างกัน วิธีการเหล่านั้นมักจะมีพารามิเตอร์ทั้งหมดของวิธี 'ก่อนหน้า' บวกอีกหนึ่ง มันเป็นผลมาจากวิวัฒนาการที่ยาวนาน (รหัสดั้งเดิม) และความคิดนี้ (ฉันเชื่อ): " มีวิธี M ที่ทำสิ่ง A. ฉันต้องทำ A + B ตกลงฉันรู้ ... ฉันจะเพิ่มพารามิเตอร์ใหม่ให้กับ M สร้างวิธีการใหม่เพื่อย้ายรหัสจาก M ไปยังวิธีใหม่ ด้วยพารามิเตอร์อีกหนึ่งตัวให้ทำ A + B ตรงนั้นแล้วเรียกวิธีการใหม่จาก M ด้วยค่าเริ่มต้นของพารามิเตอร์ใหม่ " นี่คือตัวอย่าง (ในภาษา Java-like-language): class DocumentHome { (...) public Document createDocument(String name) { // just calls another method with …

16 refactoring  clean-code  legacy-code 

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

16 performance  clean-code 

ตัวดำเนินการเพิ่มของคลาส set ส่งคืนบูลีนซึ่งเป็นจริงหากองค์ประกอบ (ซึ่งจะถูกเพิ่ม) ยังไม่มีอยู่และเป็นเท็จ กำลังเขียน if (set.add(entry)) { //do some more stuff } ถือว่าเป็นสไตล์ที่ดีในแง่ของการเขียนโค้ดที่สะอาด? ฉันสงสัยว่าคุณทำสองสิ่งพร้อมกัน 1) การเพิ่มองค์ประกอบและ 2) การตรวจสอบว่ามีองค์ประกอบอยู่หรือไม่

15 java  coding-style  clean-code 

เมื่อเร็ว ๆ นี้ระหว่างการตรวจสอบรหัสฉันพบรหัสซึ่งเขียนโดยเพื่อนร่วมงานคนใหม่ซึ่งมีลวดลายที่มีกลิ่น ฉันสงสัยว่าการตัดสินใจของเพื่อนร่วมงานขึ้นอยู่กับกฎที่เสนอโดยหนังสือ Clean Code ที่มีชื่อเสียง (และอาจเป็นโดยหนังสืออื่นที่คล้ายคลึงกันเช่นกัน) ฉันเข้าใจว่าตัวสร้างคลาสมีหน้าที่รับผิดชอบทั้งหมดในการสร้างวัตถุที่ถูกต้องและหน้าที่หลักของมันคือการกำหนดคุณสมบัติ (ส่วนตัว) ของวัตถุ มันอาจเกิดขึ้นได้ว่าอาจมีการตั้งค่าคุณสมบัติทางเลือกโดยวิธีการอื่นนอกเหนือจากตัวสร้างคลาส แต่สถานการณ์ดังกล่าวค่อนข้างหายาก (แม้ว่าจะไม่จำเป็นต้องผิดหากว่าส่วนที่เหลือของชั้นเรียนคำนึงถึงคุณสมบัติของทรัพย์สินนั้น) สิ่งนี้มีความสำคัญเนื่องจากช่วยให้มั่นใจได้ว่าวัตถุนั้นอยู่ในสถานะที่ถูกต้องเสมอ อย่างไรก็ตามในรหัสที่ฉันพบค่าคุณสมบัติส่วนใหญ่จริง ๆ แล้วถูกตั้งค่าโดยวิธีอื่นนอกเหนือจากตัวสร้าง ค่าที่เป็นผลมาจากการคำนวณถูกกำหนดให้กับคุณสมบัติที่จะใช้ในวิธีการส่วนตัวหลายวิธีตลอดทั้งชั้นเรียน ผู้เขียนดูเหมือนจะใช้คุณสมบัติคลาสราวกับว่าพวกเขาเป็นตัวแปรทั่วโลกที่ควรจะสามารถเข้าถึงได้ทั่วทั้งชั้นเรียนแทนที่จะเป็นพารามิเตอร์ของค่าเหล่านี้กับฟังก์ชั่นที่ต้องการพวกเขา นอกจากนี้วิธีการของชั้นเรียนควรจะเรียกว่าในลำดับที่เฉพาะเจาะจงเพราะชั้นเรียนจะไม่ทำอย่างอื่นมาก ฉันสงสัยว่ารหัสนี้ได้รับแรงบันดาลใจจากคำแนะนำเพื่อให้วิธีการสั้น (<= 5 บรรทัดของรหัส) เพื่อหลีกเลี่ยงรายการพารามิเตอร์ขนาดใหญ่ (พารามิเตอร์ <3) และตัวสร้างที่จะต้องไม่ทำงาน (เช่นการคำนวณบางประเภท ที่จำเป็นสำหรับความถูกต้องของวัตถุ) แน่นอนว่าตอนนี้ฉันสามารถสร้างรูปแบบนี้ได้หากฉันสามารถพิสูจน์ได้ว่าข้อผิดพลาดที่ไม่ได้กำหนดทุกประเภทอาจเกิดขึ้นเมื่อไม่ได้เรียกวิธีการตามลำดับที่เฉพาะเจาะจง อย่างไรก็ตามฉันคาดการณ์ว่าการตอบสนองต่อสิ่งนี้จะเพิ่มการตรวจสอบความถูกต้องซึ่งยืนยันว่าต้องตั้งค่าคุณสมบัติเมื่อมีการเรียกใช้เมธอดที่ต้องการคุณสมบัติเหล่านั้น อย่างไรก็ตามฉันอยากจะเสนอให้เปลี่ยนรหัสทั้งหมดเพื่อให้คลาสกลายเป็นสีน้ำเงินพิมพ์ไปยังวัตถุจริงแทนที่จะเป็นชุดของวิธีการที่ควรเรียกว่า (ขั้นตอน) ตามลำดับที่เฉพาะเจาะจง ฉันรู้สึกว่ารหัสที่ฉันพบมีกลิ่น ในความเป็นจริงฉันเชื่อว่ามีความแตกต่างค่อนข้างชัดเจนว่าเมื่อใดที่จะบันทึกค่าในคุณสมบัติคลาสและเมื่อนำไปใช้เป็นพารามิเตอร์สำหรับวิธีการที่แตกต่างกันในการใช้งาน - ฉันไม่เชื่อจริง ๆ ว่าพวกเขาสามารถเป็นทางเลือก . ฉันกำลังมองหาคำสำหรับความแตกต่างนี้

15 object-oriented  clean-code