มีกระบวนทัศน์การเขียนโปรแกรมที่ส่งเสริมการอ้างอิงอย่างชัดเจนกับโปรแกรมเมอร์อื่น ๆ หรือไม่

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

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

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

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

การค้นพบ

มันขาดภัยพิบัติหลายองค์กร เครื่องมือที่เฟร็ดสร้างขึ้นมาใหม่อยู่ที่ไหน ในที่เก็บ Git แน่นอน ที่ไหน?

รูปแบบซอฟต์แวร์ที่คำนึงถึงคือ Model-View-ViewModel สำหรับมือใหม่รูปแบบนี้เป็นปริศนาที่สมบูรณ์ ฉันอธิบายให้ภรรยาฟังว่า "เครื่องมือห้าชิ้นที่ลอยอยู่เหนือโต๊ะคุยกันด้วยพลังลึกลับ" ทำความเข้าใจกับรูปแบบและคุณเข้าใจซอฟต์แวร์

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

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

• การจัดระเบียบโฟลเดอร์
• โครงการอ้างอิง
• เอกสารสำหรับชั้นเรียน (คืออะไร, ทำอะไร, ทำไมมีอยู่, วิธีใช้)
• โครงการโมดูลประกอบเอกสารอะไรก็ตาม

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

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

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

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

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

สถาปัตยกรรม.

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

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

โดยหลักการแล้วกฎเหล่านั้นจะถูกรวมเป็นหนึ่งเดียวด้วยจิตใจ

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

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

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

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

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

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

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

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

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

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

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

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

สรุปแล้ว

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

เพื่อตอบคำถามตามที่มีการโพสต์ไว้ (แทนที่จะให้คำแนะนำสำหรับสถานการณ์เฉพาะของคุณ):

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

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

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

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

รหัส Bespoke ถูกเก็บไว้ให้น้อยที่สุดแน่นอนและถึงแม้ว่าจะต้องยืนยันรูปแบบการเข้ารหัสและการรายงานต่างๆ

ฉันจะสมมติว่าคุณคุ้นเคยกับETL suites แล้ว มีฟังก์ชั่นมากมายที่คุณได้รับฟรีวันนี้ที่ไม่ได้ปรากฏเมื่อตอนที่ฉันอยู่ในเกมเมื่อประมาณสิบปีที่แล้ว

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

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

• หลีกเลี่ยงตัวแปรโกลบอลใช้พารามิเตอร์แทน สิ่งนี้ใช้กับการโทรข้ามภาษาด้วย
• หลีกเลี่ยงการเปลี่ยน / กลายพันธุ์ค่าของตัวแปรให้มากที่สุด สร้างตัวแปรใหม่และใช้เมื่อคุณต้องการเปลี่ยนค่าหากเป็นไปได้
• ทำรหัสโมดูลาร์ ถ้ามันเป็นไปไม่ได้ที่จะอธิบายว่าส่วนใด (ไม่ใช่วิธี) กำลังทำอะไรอยู่ในประโยคอย่างง่าย ๆ แบ่งมันออกเป็นโมดูลที่ตอบสนองเงื่อนไข
• ตั้งชื่อส่วนรหัสของคุณอย่างถูกต้อง เมื่อคุณสามารถอธิบายสิ่งที่ส่วนหนึ่งของรหัสกำลังทำด้วยคำง่ายๆคำเหล่านั้นกลายเป็นชื่อของส่วนนั้น ดังนั้นรหัสจะกลายเป็นเอกสารด้วยตนเองผ่านชื่อของโมดูล / คลาส / ฟังก์ชั่น / ขั้นตอน / วิธีการ ฯลฯ
• ทดสอบรหัสของคุณ ทดสอบว่าเอนทิตีในรหัสของคุณแสดงชื่อที่ถูกต้องในจุดก่อนหน้า
• บันทึกเหตุการณ์ในรหัส อย่างน้อยรักษาบันทึกสองระดับ อันแรกเปิดใช้งานอยู่เสมอ (แม้ในการผลิต) และบันทึกเฉพาะเหตุการณ์สำคัญเท่านั้น และใช้อีกอันเพื่อบันทึกโดยทั่วไปทุกอย่าง แต่สามารถเปิดหรือปิดได้
• ค้นหาและใช้เครื่องมือที่เหมาะสมเพื่อเรียกดูดูแลและพัฒนา codebase ของคุณ แม้แต่ตัวเลือก "ค้นหาทุกอย่าง" อย่างง่ายของ Visual Studio Code ทำให้ชีวิตของฉันง่ายขึ้นมากในบางกรณี