จะป้องกันเพื่อนร่วมงานที่แนะนำให้ใช้ความซับซ้อนและนามธรรมได้อย่างไร?

ฉันมีช่วงเวลาที่ยากมากเพราะเพื่อนร่วมงานของฉันดูเหมือนจะแสดง

1. ความพยายามเพิ่มประสิทธิภาพก่อนกำหนด / ไม่จำเป็น
2. การขจัดความซ้ำซ้อนก่อนวัยอันควรด้วย abstractions ที่น่าสงสัย
   ตัวอย่างเช่นเราใช้สถาปัตยกรรม VIPER ที่ปรับเปลี่ยน เขาแนะนำคลาสพื้นฐานสำหรับส่วนประกอบเราเตอร์ (โดยใช้ generics) เป็นส่วนหนึ่งของการนำ viper stack แรกไปใช้โดยไม่ทราบว่าจะทำซ้ำในเราเตอร์อื่น ๆ ตอนนี้เราติดอยู่กับการให้ประเภทUseCaseที่เก็บกรณีการใช้งาน แต่เราเตอร์ส่วนใหญ่ไม่มีหลายกรณีการใช้งานเพียงหนึ่งเดียว
3. คิดค้นวิธีแก้ปัญหาทั่วไปสำหรับคุณสมบัติในอนาคตที่อาจเกิดขึ้นได้
   ตัวอย่างเช่นเขาเขียนผู้จัดการสำหรับการเติมมุมมองตารางเซลล์แบบคงที่เมื่อเรามีเพียงสองหน้าจอเช่นนี้ในแอปและเขาไม่ทราบว่าการออกแบบจะย้ายออกจากรูปแบบแนวตั้งที่น่าเบื่อ UIs ผู้จัดการจึงไม่มีประโยชน์
4. การเลือกเพื่อความซับซ้อนโดยบังเอิญ

ฉันจะต่อสู้กับสิ่งนี้ได้อย่างไรเมื่อเขาแสดงให้เห็นว่ามีอุปสรรคทางภาษาด้วยภาษาอังกฤษที่มีหมัด

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

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

จากทั้งหมดข้างต้นจุดสนใจหลักสองข้อของฉันคือการรีวิวโค้ดและเรื่องราวเล็ก ๆ

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