ฉันเป็นนักพัฒนาอินดี้ที่ทำงานในโครงการ Android หลายโครงการ ฉันมีปัญหากับการบำรุงรักษาฟังก์ชั่นเดียวกันในโครงการต่างๆ ตัวอย่างเช่นสามแอพของฉันใช้ 2 คลาสเดียวกัน เนื่องจากเป็นโครงการที่แตกต่างกันเมื่อฉันต้องการเปลี่ยนแปลงคลาสเหล่านั้นฉันจึงต้องทำสามครั้ง มีวิธีแก้ไขปัญหาทั่วไปประเภทนี้อย่างง่าย ๆ ไหม?
คำตอบ:
แยกรหัสที่ใช้ร่วมกันออกเป็นห้องสมุดและรวมถึงห้องสมุดในโครงการ
ในฐานะนักพัฒนา Android คุณคงใช้ Java พิจารณาการใช้เครื่องมือการจัดการการพึ่งพาเช่นMavenหรือไอวี
ผลข้างเคียงคือสิ่งนี้จะช่วยรักษาความกังวลแยกจากกันโดยการบังคับใช้แบบแยกส่วน ค่าใช้จ่ายคืออาจต้องทำงานแยกกันบ้าง ประโยชน์คือการบำรุงรักษาที่ดีขึ้นในอนาคต นอกจากนี้หากคุณเคยตัดสินใจคุณสามารถปล่อยห้องสมุดแยกต่างหาก (ทั้งในเชิงพาณิชย์หรือเป็นโอเพ่นซอร์ส) จากแอปพลิเคชันของคุณ
การควบคุมเวอร์ชัน Git Git Submodules
วางโครงการของคุณภายใต้การควบคุมเวอร์ชันโดยใช้ dvcs เช่น git หรือ mercurial เป็นต้นใส่รหัสที่ใช้ร่วมกันใน submodule ใน git ใช้ submodule ในโครงการที่ต้องการ เมื่อคุณอัปเดต submodule สามารถดึงการเปลี่ยนแปลงไปยังโครงการอื่น ๆ ด้วยคำสั่งเดียว
ยังไม่มีใครพูดถึงดาบสองคมดังนั้นฉันจะเพิ่ม 2 เซนต์ของฉัน หากคุณมีหลายโครงการและพวกเขาแบ่งปันรหัสที่สามารถนำกลับมาใช้ใหม่ได้บ้างตามแนวทางปฏิบัติในการเขียนโปรแกรม / หลักการที่ดี (เช่น DRY) คุณควรวางรหัสไว้ในที่เดียวทั่วโลกและจัดโครงสร้างไว้ในลักษณะเดียวกัน โครงการของคุณโดยไม่มีการดัดแปลงใด ๆ กล่าวอีกนัยหนึ่งให้กำหนดอินเทอร์เฟซให้เป็นสามัญและทั่วไปพอที่จะเหมาะกับทุกคน
มีตัวเลือกไม่กี่อย่างสำหรับการทำสิ่งนี้: 1) สร้างโปรเจ็กต์ฐานที่ผู้อื่นพึ่งพา โครงการนี้สามารถสร้างการกระจายแบบไบนารีที่โครงการอื่นใช้ 2) ดึงโมเดลโอเพ่นซอร์สภายในองค์กรของคุณ มีรหัสทั่วไปเป็นสาขารหัสของตัวเองและให้โครงการอื่นดึงรหัสเช่นเดียวกับที่คุณจะนำซอร์สโค้ดจาก OSS ออนไลน์
ตอนนี้นี่คือที่มาของดาบ ...
การวางโค้ดในที่ ๆ ใช้ร่วมกันซึ่งโครงการ / คนอื่น ๆ นั้นขึ้นอยู่กับนั้นอาจจะค่อนข้างแพง สมมติว่าคุณมีรหัสชิ้นหนึ่งและอีก 4 โครงการขึ้นอยู่กับมัน หนึ่งในลูกค้าของคุณที่ใช้โครงการ A พบข้อบกพร่องและคุณต้องทำการแก้ไข คุณรีบแก้ไขและลูกค้ารายนั้นก็มีความสุข แต่คุณเพิ่งแก้ไขรหัสบางส่วนที่ 3 โครงการอื่นขึ้นอยู่กับ คุณได้ทดสอบซ้ำทั้งหมดเพื่อให้แน่ใจว่าไม่มีการเปิดใช้เงื่อนไขขอบ?
รหัสทั่วไปจะต้องถูกสร้างขึ้นอย่างระมัดระวังมากขึ้นและส่วนต่อประสานของโมดูลจะต้องได้รับการออกแบบให้ดียิ่งขึ้นเนื่องจากรหัสนั้นจะต้องรองรับลูกค้าหนึ่งราย แต่ไม่ใช่ 4 รายและแต่ละรหัสอาจใช้รหัสนี้ด้วยความแตกต่างเล็กน้อย
หากโครงการของคุณอยู่ในรอบการเผยแพร่ที่แตกต่างกันคุณจะต้องระมัดระวังให้มากขึ้นเกี่ยวกับการจัดการรหัสทั่วไป คุณไม่สามารถทำการเปลี่ยนแปลงในรหัสทั่วไปได้เพียงเพราะโครงการ B ต้องการฟังก์ชั่นใหม่ถ้าคุณห่างจากการตัดภาพสุดท้ายสำหรับโครงการ C 3 วัน
ฉันไม่ได้บอกว่าห้องสมุดทั่วไปไม่ใช่ทางออกที่ถูกต้อง ฉันเป็นผู้สนับสนุนที่แข็งแกร่งของ DRY และฉันได้สร้างและสนับสนุนรหัสทั่วไปก่อนและดำเนินการต่อไป แค่อยากจะใส่มันลงไปที่นั่นการสร้างรหัสทั่วไปจะมีค่าใช้จ่ายของตัวเอง
หากคุณเป็นคนเดียวที่ใช้รหัสนี้ซ้ำรหัสนี้ก็ไม่เลว หากคุณมีทีมวิศวกรและพวกเขาเริ่มใช้รหัสทั่วไปค่าใช้จ่ายจะมากขึ้น หากผู้อื่นมีส่วนเกี่ยวข้องคาดหวังว่าการวางโค้ดลงในไลบรารีทั่วไปจะใช้เวลานานถึง 3 เท่าเท่าที่จะเป็นไปได้จนถึงจุดที่คุณคิดว่ามันเป็น "สมบูรณ์" คุณจะต้อง a) ทำให้ไลบรารีมีประสิทธิภาพมากขึ้นเพื่อป้องกันเงื่อนไขขอบทุกประเภทและการใช้งานที่ไม่ถูกต้อง b) จัดเตรียมเอกสารเพื่อให้ผู้อื่นสามารถใช้ห้องสมุดและ c) ช่วยให้คนอื่นดีบั๊กเมื่อพวกเขาใช้ห้องสมุดในแบบที่คุณ ยังไม่ได้คาดหวังและเอกสารของคุณไม่ครอบคลุมกรณีการใช้งานเฉพาะ
ข้อเสนอแนะน้อยฉันสามารถนำเสนอ:
นี่เป็นทางออกในอุดมคติและอาจต้องใช้ความพยายามในการทำงาน
หลักการของ DRY ระบุว่าควรมีแหล่งความจริงที่เชื่อถือได้เพียงแหล่งเดียว สิ่งนี้สั่งให้ใช้แหล่งเก็บข้อมูลเดียวสำหรับตรรกะของโปรแกรมทั้งหมดโดยไม่มีการทำซ้ำ จัดระเบียบไฟล์เพื่อส่งเสริมการแบ่งปันและนำเอกสารมาใช้ซ้ำ
ข้อกำหนดในทางปฏิบัติของการสื่อสารในสภาพแวดล้อมแบบกระจายที่มีหลายทีมแสดงให้เห็นว่าควรมีแหล่งเก็บข้อมูลอิสระหลายแห่งหนึ่งแห่งสำหรับแต่ละโครงการหรือการทำงานร่วมกัน
ฉันจะแก้ไขปัญหานี้โดยส่งไปยังสิ่งที่หลีกเลี่ยงไม่ได้: คุณจะต้องใช้ทั้งสองวิธีพร้อมกันและเราจะใช้สคริปต์และระบบอัตโนมัติเพื่อให้ราบรื่นกับความจริงที่ว่าแนวทางนั้นขัดแย้งกัน
:-)
ที่เก็บหนึ่งเดียวจะเป็นแหล่งข้อมูลที่เชื่อถือได้เพียงแหล่งเดียวของคุณ กระบวนการสร้างสำหรับแต่ละโครงการจะคัดลอกไฟล์ทั้งหมดที่ใช้โดยโครงการนั้น (และเฉพาะไฟล์เหล่านั้น) ไปยังตำแหน่งกึ่งกลางจากนั้นสร้างจากตำแหน่งกลางนั้น (พร้อมเพรียงหรือเครื่องมือที่คล้ายกันบางอย่างสามารถใช้ในการย้ายเดลต้าแทนไฟล์ทั้งหมด)
ตำแหน่งกลางเหล่านี้สามารถใช้เป็นสำเนาการทำงานในท้องถิ่นสำหรับชุดที่เก็บรองที่ได้รับหรือที่ต่อเนื่อง สคริปต์การลงรายการบัญชีฮุกบนที่เก็บข้อมูลที่มีสิทธิ์จะอัปเดตตำแหน่งกลางทั้งหมดและตรวจสอบว่ามีการเปลี่ยนแปลงหรือไม่และตรวจสอบว่ามีการเปลี่ยนแปลงหรือไม่และตรวจสอบว่ามีการเปลี่ยนแปลงหรือไม่
วิธีนี้ที่เก็บข้อมูลรองจำนวนมากจะถูกเก็บไว้ในซิงค์กับแหล่งเก็บข้อมูลที่มีสิทธิ์เดียวและกระบวนการสร้างมั่นใจว่าที่เก็บรองมีเอกสารทั้งหมด (อาจแชร์) และไฟล์อื่น ๆ ที่จำเป็นสำหรับการสร้างที่จะประสบความสำเร็จ ในที่สุดและที่สำคัญที่สุดคือการพัฒนาและสร้างกระบวนการรับรองว่าไฟล์จะถูกแก้ไขในที่เดียวและที่เดียวเท่านั้นและสำเนาทั้งหมดจะถูกเก็บไว้อย่างสม่ำเสมอและทันสมัย