การค้นพบสำหรับนักพัฒนาเป็นปัญหาเมื่อใช้หลักการของ SOLID หรือไม่?


10

ฉันทำแอพทางธุรกิจที่นักพัฒนาคนอื่น ๆ ทั้งหมดคุ้นเคยกับการทำแอพพลิเคชั่น CRUD ขั้นพื้นฐานหรือมุ่งเน้นไปที่การสร้างอินเทอร์เฟซที่สวย / ใช้งานได้เพียงอย่างเดียว

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

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

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

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

ฉันได้ทำ googled / binged และ yahoo! d แล้ว แต่ฉันไม่พบปัญหานี้

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

สิ่งเดียวที่ฉันสามารถทำได้คือมีสิ่งเหล่านี้เพราะไม่มีชื่อที่ดีกว่า "Table of Content Class" ที่ไม่ทำอะไรเลยที่ส่งคืนคลาสที่แท้จริง (และจริงๆแล้วส่วนใหญ่เป็นอินเทอร์เฟซ แต่ไม่มี ทราบถึงความแตกต่างหรือความใส่ใจ) ที่ผู้พัฒนารายอื่นสามารถใช้เพื่อทำงานตามที่ต้องการได้ ยังคงจบลงด้วยคลาสที่ใหญ่มาก แต่แทบจะไม่มีพฤติกรรมใด ๆ ในพวกเขา

มีวิธีที่ดีกว่าที่ไม่ต้องการความรู้ที่ใกล้ชิดของระดับกลางที่มีการใช้งาน SOLID จริงหรือไม่?

โดยทั่วไปสิ่งที่ฉันถามคือมีวิธีให้นักพัฒนาประเภท CRUD ยังคงเป็นนักพัฒนา CRUD ในระบบที่ซับซ้อนมาก


8
อาจทำให้นักพัฒนาซอฟต์แวร์ของคุณไม่ได้พึ่งพา IntelliSense ทั้งหมด (หรือเทียบเท่า) เพื่อการค้นพบ บอกชื่ออย่างดี บันทึกสิ่งต่าง ๆ ได้ดี นี่เป็นปัญหาการสื่อสารไม่ใช่ปัญหาทางเทคนิค
Rein Henrichs

อืมม Kinda ยิ่งฉันคิดถึงมันมากเท่าไหร่ฉันก็ยิ่งเชื่อว่ามีโอกาสทางธุรกิจที่ซุ่มซ่อน
ElGringoGrande

2
@ReinHenrichs: หากผู้พัฒนาต้องการอ่านเอกสารมันจะใช้เวลาและประสิทธิภาพจะลดลง ดังนั้นจึงเป็นสิ่งสำคัญที่พวกเขาค้นหาสิ่งที่พวกเขาต้องการสำหรับงานที่ได้รับอย่างรวดเร็ว ไม่จำเป็นต้องพึ่งพาระบบ Intellisense แต่จะง่ายกว่า ทำให้ง่ายแน่นอนปัญหาทางเทคนิค
Jan Hudec

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

@JanHudec ไม่ใช่ "ถ้า" แต่เป็น "เมื่อ" นักพัฒนาจะต้องอ่านเอกสาร หากคุณต้องการให้พวกเขา "ค้นหาสิ่งที่พวกเขาต้องการสำหรับงานที่ได้รับอย่างรวดเร็ว" ทางออกที่ดีที่สุดของคุณคือการมุ่งเน้นที่การทำให้เอกสารมีประสิทธิภาพ อย่าพยายามแก้ปัญหาคน (เช่นการสื่อสาร) ด้วยโซลูชันทางเทคนิค มัน. ทำ. ไม่. งาน.
Rein Henrichs

คำตอบ:


4

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

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

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

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

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

BEGIN_COMMAND_MAP()
    COMMAND_ENTRY( CChangeDeviceState )
    COMMAND_ENTRY( CSetConfiguration )
    ....
END_COMMAND_MAP()

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

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

(*) ฉันไม่ต้องการรับรายละเอียดมากเกินไป แต่จริงๆแล้วฉันมีชุดคำสั่ง "Command" และ "CommandHandler" ความรับผิดชอบนี้แยกจากกันในการจัดการ / เข้าคิว / ลำดับพารามิเตอร์เข้า / ออกจากคลาสที่ "จัดการ" คำสั่งเหล่านั้นจริงๆ


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

0

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

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

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

หากคุณทำสิ่งนี้ถูกต้องคุณจะพบกับสิ่งที่ค้นพบได้มาก

เมื่อต้องการยกตัวอย่างถ้าฉันต้องการการตรวจสอบผู้ใช้ฉันพิมพ์ "MyCo" และให้รายการของเนมสเปซแอปพลิเคชัน ฉันรู้ว่ามีการใช้ฐานข้อมูลผู้ใช้ในแอพทั้งหมดของเราดังนั้นฉันจึงพิมพ์ "Core" จากนั้นฉันจะได้รับรายการประเภทการทำงาน หนึ่งในนั้นคือ "การตรวจสอบความถูกต้อง" เพื่อให้ดูเหมือนเป็นตัวเลือกที่ชัดเจน และภายในการตรวจสอบก็คือ "UserValidator" พร้อมฟังก์ชันการทำงานทั้งหมด

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

แต่สำหรับสิ่งที่ฉันจำไม่ได้มันก็ยังหาได้ง่าย และเมื่อฉันทำฉันสามารถลบคำนำหน้าเนมสเปซได้


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

0

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

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

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


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

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