รักษาสาขาที่กำหนดเองหลายร้อยสาขาเหนือสาขาต้นแบบ

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

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

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

ฉันกำลังมองหาวิธีที่มีประสิทธิภาพมากขึ้นในการทำให้สาขาของลูกค้าปล่อยให้ทันสมัยกับสาขาหลักที่จะทำให้ความพยายามน้อยลงในระหว่างการรวม

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

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

โครงสร้างพื้นฐานหลักและฟีเจอร์ที่แชร์ใด ๆ จึงต้องเก็บรักษาและทดสอบเพียงครั้งเดียวเท่านั้น

คุณควรทำสิ่งนี้ตั้งแต่เริ่มต้น หากคุณมีผลิตภัณฑ์ห้าร้อยรายการ (!) การแก้ไขสิ่งนี้จะเป็นงานที่ยิ่งใหญ่ … แต่ไม่มากไปกว่าการบำรุงรักษาอย่างต่อเนื่อง

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

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

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

จากนั้นย้ายไปสู่ปัญหาที่ยากขึ้นโดยใช้รูปแบบกลยุทธ์การฉีดพึ่งพาเป็นต้น

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

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

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

คุณอาจยังคงมี 500 สาขาในเวลาหลายปี แต่ถ้าพวกเขาจัดการได้ง่ายกว่ามากคุณก็จะชนะ

ขึ้นอยู่กับความคิดเห็นโดย br3w5:

• คุณสามารถใช้แต่ละคลาสที่แตกต่างกันระหว่างไคลเอนต์
• ทำ“ xxx_baseclass” ที่กำหนดวิธีการทั้งหมดที่เรียกว่าในชั้นเรียนจากนอกมัน
• เปลี่ยนชื่อคลาสเพื่อให้ xxx เรียกว่า xxx_clientName (เป็นคลาสย่อยของ xxx_baseclass)
• ใช้การฉีดพึ่งพาเพื่อให้มีการใช้คลาสที่ถูกต้องสำหรับแต่ละไคลเอนต์
• และตอนนี้สำหรับความเข้าใจที่ฉลาด br3w5 เกิดขึ้น! ใช้เครื่องมือวิเคราะห์รหัสแบบสแตติกเพื่อค้นหารหัสที่ซ้ำกันในขณะนี้และย้ายไปไว้ในคลาสฐาน ฯลฯ

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

ในอนาคตถามคำถามทดสอบโจเอลในการสัมภาษณ์ของคุณ คุณมีแนวโน้มที่จะไม่เดินเข้าไปในซากรถไฟ

นี่คือวิธีที่เราจะพูดว่า ... จริงๆปัญหาที่เลวร้ายจริงๆที่จะมี "อัตราดอกเบี้ย" ของหนี้ทางเทคนิคนี้จะสูงมากมาก อาจไม่สามารถกู้คืนได้ ...

การรวมกับ "หลัก" มีการเปลี่ยนแปลงที่กำหนดเองเหล่านี้อย่างไร คุณสามารถทำให้พวกเขาเป็นห้องสมุดของตัวเองและมี "แกน" เดียวและลูกค้าแต่ละรายที่มี "Add-on" ของตัวเอง

หรือการกำหนดค่าเล็กน้อยเหล่านี้ทั้งหมดหรือไม่

ฉันคิดว่าทางออกคือการรวมกันของ:

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

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

ฉันยังสงสัยว่าคุณกำลังจะมีปัญหาสำคัญในการแยกและจัดหมวดหมู่รหัสเฉพาะลูกค้าของคุณได้อย่างง่ายดาย

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

นี่เป็นหนึ่งในรูปแบบการต่อต้านที่เลวร้ายที่สุดที่คุณสามารถโจมตีด้วย VCS ใด ๆ

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

สิ่งนี้ช่วยให้คุณสามารถเก็บรหัสหลักของสาขาหนึ่งไว้ด้วยรหัสการผลิตของคุณได้

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

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

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

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

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

ซึ่งหมายความว่า:

1. ชี้แจงความรับผิดชอบการจัดการการเปลี่ยนแปลง: หากลูกค้าต้องการการดัดแปลงบางอย่างใครกำลังขายพวกเขาใครอนุญาตให้พวกเขาและใครเป็นผู้ตัดสินใจว่าจะเปลี่ยนรหัสอย่างไร สกรูจะหมุนไปที่ใดหากบางสิ่งต้องเปลี่ยน?
2. ชี้แจงบทบาทที่อยู่ในทีมของคุณจะได้รับอนุญาตให้ Repos ใหม่และผู้ที่ไม่ได้เป็น
3. พยายามทำให้แน่ใจว่าทุกคนในทีมของคุณเห็นความจำเป็นของรูปแบบที่ให้ความยืดหยุ่นกับซอฟต์แวร์
4. ชี้แจงเครื่องมือการจัดการของคุณ: คุณจะรู้ได้อย่างไรว่าลูกค้ารายใดมีการปรับใช้โค้ดอย่างรวดเร็ว ฉันรู้ว่า "รายชื่อ 500" ฟังดูน่ารำคาญ แต่นี่คือ "เศรษฐกิจเชิงอารมณ์" ถ้าคุณต้องการ หากคุณไม่สามารถบอกการเปลี่ยนแปลงของลูกค้าได้ในเวลาอันรวดเร็วคุณจะรู้สึกว่าหลงและวาดได้ราวกับว่าคุณต้องเริ่มรายการ จากนั้นใช้รายการนั้นเพื่อจัดกลุ่มคุณลักษณะที่คำตอบของผู้อื่นที่นี่แสดงให้คุณเห็น:
   • กลุ่มลูกค้าโดยการเปลี่ยนแปลงเล็กน้อย / สำคัญ
   • จัดกลุ่มตามการเปลี่ยนแปลงที่เกี่ยวข้องกับหัวเรื่อง
   • จัดกลุ่มตามการเปลี่ยนแปลงง่ายต่อการรวมและเปลี่ยนแปลงยากที่จะรวม
   • ค้นหากลุ่มของการเปลี่ยนแปลงที่เท่าเทียมกันที่ทำกับ repos หลายรายการ (ใช่แล้วจะมีบ้าง)
   • อาจสำคัญที่สุดในการพูดคุยกับผู้จัดการ / นักลงทุนของคุณ: จัดกลุ่มตามการเปลี่ยนแปลงที่มีราคาแพงและการเปลี่ยนแปลงราคาถูก

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

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

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

หากเปรียบเทียบความแตกต่างของคำว่าไร้สาระทั้งหมดแล้วสมมติว่าความต้องการทางธุรกิจที่แท้จริง

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

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

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

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

สามารถโหลดปลั๊กอินในเวลาใช้งานหรือสร้างขึ้นในเวลารวบรวม

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

มีบางกรณีที่ปลั๊กอินไม่ดีพอนั่นคือเมื่อต้องมีการปรับแต่งภายในแกนหลักจำนวนมากดังนั้นจำนวนอินเตอร์เฟสปลั๊กอินจะใหญ่เกินไปที่จะจัดการ

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

ตัวอย่างง่ายๆคุณสามารถระบุได้ว่าfooจะรันแบบกำหนดเองก่อนหรือหลังคอร์klass.fooหรือว่ามันจะแทนที่มันหรือว่ามันแรปและสามารถเปลี่ยนอินพุตหรือเอาต์พุต

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

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

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

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

คุณสมบัติที่กำหนดเองมีความหลากหลายแตกต่างกันอย่างไรมีความคล้ายคลึงกันในเชิงบริบทหรือไม่จะเล่นได้มากใน 'ฆ่าเชื้อ' ฐานรหัสผลิตภัณฑ์ของคุณ

มากกว่ารหัสและเวอร์ชันของคุณนี่คือที่ที่การจัดการผลิตภัณฑ์สถาปัตยกรรมผลิตภัณฑ์และสถาปัตยกรรมข้อมูลเข้ามามีบทบาท อย่างจริงจัง.

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

การจัดการที่ดีกว่านี้ต้องมาจากจุดยืน 'ความสามารถ' และไม่ใช่จุดยืนรหัส

คุณ บริษัท และผลิตภัณฑ์ของคุณไม่สามารถเป็นทุกสิ่งสำหรับทุกคน ตอนนี้คุณมีฐานรายได้ที่ดีจากลูกค้า 500 รายแล้วถึงเวลาที่จะสร้างผลงานในสิ่งที่คุณตั้งใจจะเป็น

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

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

คุณจะเป็นCRMหรือERPหรือการประมวลผลคำสั่งซื้อ / จัดส่งหรือ Microsoft Excel?

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

คุณจะต้องมีการจัดการผลิตภัณฑ์ที่แข็งแกร่งและสถาปัตยกรรมข้อมูลคนแมปต่อไปนี้:

• สาขาหลักความสามารถของผลิตภัณฑ์และฐานคุณสมบัติ
• คุณสมบัติส่วนขยายที่กำหนดเองประเภทและรูปแบบต่างๆ
• ความสำคัญและรูปแบบของ 'ฟิลด์ที่กำหนดเอง'

.. เพื่อสร้างแผนที่ถนนของการดูดกลืนและการประสานกันของกลุ่มผลิตภัณฑ์ / สาขาที่หลวมเหล่านี้ในบริบทอันยิ่งใหญ่ของแอปพลิเคชันหลักของคุณ

PS: เชื่อมต่อกับฉันฉันรู้ว่าคนที่สามารถช่วยคุณแก้ไขปัญหานี้ :)

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

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

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

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