ฉันจะพิสูจน์หรือหักล้าง“ วัตถุพระเจ้า” ผิดได้อย่างไร?

สรุปปัญหา:

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

ปัญหาของฉันมาจากระดับเทคนิคฉันรู้ดีในระยะยาว แต่ฉันมีปัญหากับระยะสั้นพิเศษและ 6 เดือนในขณะที่บางสิ่งที่ฉัน "รู้" ฉันไม่สามารถพิสูจน์ได้ด้วยการอ้างอิงและแหล่งอ้างอิงภายนอก ของคนคนหนึ่ง (Robert C. Martin หรือลุงลุง Bob) นั่นคือสิ่งที่ฉันถูกขอให้ทำเพราะฉันได้รับการบอกว่ามีข้อมูลจากบุคคลหนึ่งและมีเพียงคนเดียวเท่านั้น (Robert C Martin) ไม่ดีพอที่จะโต้แย้ง .

คำถาม:

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

การวิจัยที่ฉันได้ทำไปแล้ว:

1. ฉันมีหนังสือหลายเล่มที่นี่และฉันได้ค้นหาดัชนีของพวกเขาสำหรับการใช้คำว่า "god object" และ "god class" ฉันพบว่ามันแทบจะไม่เคยใช้มาก่อนและสำเนาของหนังสือ GoF ที่ฉันมีตัวอย่างไม่เคยใช้มัน (อย่างน้อยตามดัชนีหน้าฉัน) แต่ฉันได้พบมันในหนังสือสองเล่มด้านล่าง แต่ฉันต้องการมากกว่านี้ ฉันสามารถใช้.
2. ฉันตรวจสอบหน้า Wikipedia สำหรับ "God Object"และปัจจุบันเป็นส่วนย่อยที่มีลิงก์อ้างอิงเพียงเล็กน้อยดังนั้นแม้ว่าฉันจะเห็นด้วยเป็นการส่วนตัวว่ามันบอกว่ามันมีไม่มากที่ฉันสามารถใช้ในสภาพแวดล้อมที่ประสบการณ์ส่วนตัวไม่ถูกต้อง หนังสือที่ถูกอ้างถึงนั้นถือว่าเก่าเกินไปที่จะใช้งานได้โดยคนที่ฉันถกเถียงประเด็นทางเทคนิคเหล่านี้พร้อมกับข้อโต้แย้งที่พวกเขาทำคือ "มันเคยคิดว่าไม่ดี แต่ไม่มีใครสามารถพิสูจน์ได้และตอนนี้ซอฟต์แวร์ทันสมัยบอกว่า" พระเจ้า "วัตถุใช้งานได้ดี" ฉันเองเชื่อว่าข้อความนี้ไม่ถูกต้อง แต่ฉันต้องการพิสูจน์ความจริงไม่ว่าจะเป็นอะไร
3. ใน "หลักการเปรียวรูปแบบและการปฏิบัติใน C #" ของ Robert Robert ใน C # "(ISBN: 0-13-185725-8, ปกแข็ง) ที่หน้า 266 ระบุไว้" ทุกคนรู้ว่าชั้นเรียนพระเจ้าเป็นความคิดที่ไม่ดีเราไม่ต้องการ เพื่อรวมสติปัญญาทั้งหมดของระบบไว้ในวัตถุเดียวหรือฟังก์ชั่นเดียวหนึ่งในเป้าหมายของ OOD คือการแบ่งและกระจายพฤติกรรมในคลาสต่างๆและฟังก์ชั่นมากมาย " - และจากนั้นก็กล่าวต่อไปว่าบางครั้งการใช้คลาสพระเจ้าก็ดีกว่าบางครั้ง (อ้างถึงตัวอย่างไมโครคอนโทรลเลอร์)
4. ใน "รหัสสะอาด: คู่มือการทำงานฝีมือซอฟต์แวร์เปรียวของโรเบิร์ตซี" หน้า 136 (และหน้านี้เท่านั้น) พูดถึง "คลาสพระเจ้า" และเรียกมันว่าเป็นตัวอย่างที่ดีของการละเมิดกฎ "คลาสควรมีขนาดเล็ก" เขาใช้เพื่อส่งเสริมหลักการความรับผิดชอบเดี่ยว "เริ่มต้นที่หน้า 138

ปัญหาที่ฉันมีคือการอ้างอิงและการอ้างอิงทั้งหมดมาจากบุคคลเดียวกัน (Robert C. Martin) และมาจากบุคคล / แหล่งเดียวกัน ฉันถูกบอกว่าเพราะเขาเป็นเพียงมุมมองเดียวความปรารถนาของฉันที่จะไม่ใช้ "God Classes" นั้นไม่ถูกต้องและไม่ได้รับการยอมรับว่าเป็นแนวปฏิบัติที่ดีที่สุดในอุตสาหกรรมซอฟต์แวร์ มันเป็นเรื่องจริงเหรอ? ฉันกำลังทำสิ่งผิดพลาดจากมุมมองทางเทคนิคโดยพยายามที่จะรักษาคำสอนของลุงบ๊อบหรือไม่?

God Objects และ Object Oriented Programming and Design:

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

สรุป:

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

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

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

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

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

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

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

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

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

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

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

1. the God Objectเป็นรูปแบบต่อต้านซึ่งระบุว่า

   ในวิศวกรรมซอฟต์แวร์ anti-pattern (หรือ antipattern) เป็นรูปแบบที่ใช้ในการดำเนินงานทางสังคมหรือธุรกิจหรือวิศวกรรมซอฟต์แวร์ที่อาจใช้กันทั่วไป แต่ไม่ได้ผลและ / หรือต่อต้านในทางปฏิบัติ

2. ในการประชุม Google IO ของปี 2009หัวข้อนี้มีการอธิบายบางส่วนเมื่อรูปแบบ MVP ได้รับการอธิบาย มันอาจไม่เกี่ยวข้องกับเป้าหมายของพระเจ้า แต่อาจมอบกระสุนให้คุณ

3. นอกจากนี้การใช้รูปแบบการต่อต้านนี้เป็นการละเมิดหลักการความรับผิดชอบเดี่ยวในการออกแบบเชิงวัตถุซึ่งระบุว่า:

   ทุกชั้นควรมีความรับผิดชอบเดียวและความรับผิดชอบนั้นควรถูกห่อหุ้มทั้งหมดโดยชั้นเรียน บริการทั้งหมดของ บริษัท ควรสอดคล้องกับความรับผิดชอบนั้น

4. ผุรหัสบล็อกยังพูดเกี่ยวกับเรื่องนี้และเกี่ยวกับเรื่องนี้เป็นวิธีการแก้ปัญหา

5. เราไม่สามารถพูดคุยเกี่ยวกับหลักการรับผิดชอบเดียวโดยไม่มีการพูดคุยเกี่ยวกับวัตถุมีเพศสัมพันธ์

   [... ] การมีเพศสัมพันธ์หรือการพึ่งพาเป็นระดับที่แต่ละโมดูลโปรแกรมอาศัยหนึ่งในโมดูลอื่น ๆ

   ในกรณีที่มีระบบที่มีการเชื่อมโยงกันอย่างแน่นหนาอาจทำให้assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency.วัตถุที่มีระดับสูงขึ้นหมายถึงการเกาะกลุ่มกันน้อยลงและในทางกลับกัน วัตถุในพระเจ้าเป็นตัวอย่างที่ดีของการมีเพศสัมพันธ์อย่างแน่นหนาเมื่อพวกเขารู้มากกว่าที่ควรดังนั้นจึงทำให้พวกเขามีความรับผิดชอบมากเกินไปจึง จำกัด การนำมาใช้ซ้ำได้อย่างมาก

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

   ด้วยอาร์กิวเมนต์นี้เราวนกลับไปยังอาร์กิวเมนต์ anti-pattern แต่กระบวนทัศน์นี้เกี่ยวข้องกับรูปแบบการแสดงวัตถุในโลกแห่งความเป็นจริงและสุดท้ายการห่อหุ้มข้อมูล

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

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

โอ้ที่นี่ฉันไปถามคำถามเก่าอีกคำถามหนึ่ง แต่ฉันจะเดาว่าคุณไม่ได้โต้แย้งเรื่องนี้และนี่คือเหตุผล

มันฟังดูเหมือนปัญหาวัฒนธรรม

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

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

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

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

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

ในเหตุการณ์ที่เป็นไปไม่ได้ที่ไม่ใช่ปัญหาทางวัฒนธรรมที่ยากนัก ...

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

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

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

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

คุณสามารถถามลุงบ๊อบเองได้ตลอดเวลา

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

คำอื่น ๆ ที่คุณอาจต้องการเริ่มต้นด้วยเมื่อค้นหาแหล่งที่มาคือ:

• SOLID
• กฎหมายของ Demeter
• Big Ball of Mud

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

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

ฉันจะพิสูจน์หรือหักล้างวัตถุ“ พระเจ้า” ผิดได้อย่างไร?

คุณไม่สามารถ.

การคาดเดาชนิดนี้ไม่สามารถแก้ไขข้อพิสูจน์ทางคณิตศาสตร์ได้และการพิสูจน์ทางคณิตศาสตร์เป็นข้อพิสูจน์ชนิดเดียวที่เป็นเสียง

แม้ว่าคุณจะพยายามแทนที่คำว่าอารมณ์ "ผิด" ด้วยมาตรการเชิงปริมาณของผลกระทบของการใช้วัตถุเทพเจ้าคุณจะพบว่า:

1. มาตรการที่มีอยู่คือน้ำมันดิบ
2. มีการศึกษาที่น่าเชื่อถือน้อยซึ่งมาตรการเหล่านั้นได้รับการวัดปริมาณสำหรับโค้ดที่ผลิตโดยโปรแกรมเมอร์มืออาชีพ
3. มีน้อยหากการศึกษาที่น่าเชื่อถือที่รูปแบบการสร้างภาษาหรือการออกแบบ (ต่อต้าน -) ได้เชื่อมโยงกับมาตรการเหล่านั้น

และนั่นคือการเพิกเฉยต่อปัญหาของการตัดสินใจว่าวัตถุใดเป็นวัตถุ "เทพเจ้า"

ที่ดีที่สุดการศึกษาประเภทนี้สามารถแสดงให้เห็นถึงความสัมพันธ์เชิงประจักษ์เท่านั้น ไม่ใช่หลักฐานของแท้

สิ่งที่คุณกำลังทำจริง ๆ คือการถกเถียงข้อดีข้อเสียของ "เทพเจ้า" ด้วยมุมมองที่เปลี่ยนความคิดเห็นของคนอื่น... และจากนั้นก็ฝึกปฏิบัติในองค์กรของคุณ

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

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

สารสกัดจาก:

(หลัก) แยกการทำงานที่เป็นอิสระที่อาจเกิดขึ้นภายในคลาส [... ] (เล็กน้อย) มันสามารถกีดกันการขยายชั้นเรียนด้วยฟังก์ชันใหม่ [... ]

ฉันไม่แน่ใจว่าทีมของคุณมีความสนใจในด้านวิชาการหรือไม่

จากมุมมองทางจิตวิทยาของการปรับปรุงกระบวนการของคุณอาจเข้าใจผิดว่าเป็นการโจมตีความสามารถของทีม a: "ทีมทำงานได้ไม่ดี" แม้ว่าโปรแกรมจะทำงานได้ตามที่คาดไว้

สิ่งที่คุณต้องการทำคือการรับมือกับผลกระทบด้านลบของ "รหัส spagetti" และ "God objects": ค่าใช้จ่าย explodig เพื่อเพิ่มคุณสมบัติใหม่เนื่องจากการเพิ่มข้อบกพร่องที่เกิดจากด้านข้าง

Beeing เฉพาะเจาะจงมากและถามคำถามแทนที่จะให้คำตอบอาจมีประโยชน์มากกว่า:

manager > Why did implement the new tax-calculation schema took more than 4 weeks
team > because {reason a}
manager > And why was {reason a}?
team > because {reason b}
manager > And why was {reason b}?
...
team > because {reason z}
manager > what could we do to avoid {reason z} ?
team > refactor code