จะรักษาความสม่ำเสมอของสถาปัตยกรรมแอปพลิเคชันอย่างไรเมื่อทีมเติบโตขึ้น

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

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

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

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

อะไรที่ทำให้คุณมีความพิเศษ

CPU ของฉันบอกว่าใช้งานได้และฉันอยากกลับบ้าน ทำไมคุณถึงรบกวนฉัน

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

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

วิธีที่ดีที่สุดในการทำเช่นนั้นคือสื่อสารล่วงหน้า อย่าบอกฉันว่า "เราไม่ได้ใช้สตริงสำหรับประเภทฐานข้อมูลของเราในร้านนี้" 6 เดือนหลังจากที่ฉันตัดสิน บอกฉันว่ามันถูกฝังอยู่ในเอกสารเป็นเวลา 2 ปีไม่มีเหตุผลที่จะให้ฉันทำอย่างนั้น

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

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

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

ลดสิ่งที่คุณสนใจเกี่ยวกับหลักการพื้นฐานของพวกเขา แทนที่จะตีฉันด้วยกฎ 101 ข้อเพื่อให้ปฏิบัติตาม 10 ข้อที่พวกเขาละเมิดเพื่อให้ฉันรู้ว่ากฎ 102 ควรเป็นของฉันเอง

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

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

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

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

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

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

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

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

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

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

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

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

มาตรฐานที่ยอมรับและตกลงกันจะปรากฏขึ้น ณ จุดที่คุณจัดทำเอกสารและทำให้แน่ใจว่าผู้คนติดตามพวกเขา ซึ่งจะรวมถึงสิ่งต่าง ๆ เช่น "enums ใน DB for ... " ฯลฯ คุณยังสามารถรวมถึงการบันทึกเอกสารที่กรอบการใช้งาน ฯลฯ

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

มีเอาต์พุตจากเครื่องมือที่เขียนลงในเอกสาร 'ดัชนีชี้วัด' เช่น google ชีตที่มีแถวต่อหน่วย (เช่น 'แอปพลิเคชัน' หรือโครงการหรือ api หรืออะไรก็ตาม) โดยมีคอลัมน์สำหรับการวัด / มาตรฐานต่างๆที่ตามมา สิ่งนี้จะทำให้ผู้คนมองเห็นเกี่ยวกับมาตรฐานที่มีอยู่การยอมรับพวกเขาเป็นอย่างดี ฯลฯ และให้ความสงบเรียบร้อย

คุณสามารถอัปเดตคอลัมน์ด้วยตนเองได้เช่นกัน แต่โชคดีที่ทำให้คอลัมน์เหล่านั้นทันสมัยอยู่เสมอ: D

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

1 - สร้างและปฏิบัติตามอนุสัญญาโค้ดเบส

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

2 - ใช้สถาปัตยกรรมซอฟต์แวร์ที่ชัดเจน

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

3 - น้อยกว่าดีกว่า: ภาษากรอบงานและเครื่องมือ

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

4 - ให้ทีมของคุณมีส่วนร่วมในการตัดสินใจออกแบบระบบ

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

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

5 - กฎทั้งหมด

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

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

ฉันเพิ่งเขียนโพสต์บล็อกเกี่ยวกับเรื่องนี้คุณสามารถค้นหาข้อมูลโดยละเอียดเกี่ยวกับหัวข้อเหล่านี้ได้ที่: https://thomasvilhena.com/2019/11/system-design-coherence