บริษัท ซอฟต์แวร์ควรมีทีมงานเฉพาะสำหรับการวิจัยและ / หรือไลบรารียูทิลิตี้หรือไม่?

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

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

ทีมเช่นนี้ควรมีขนาดใหญ่แค่ไหน?

ควรมีสมาชิกถาวรที่ฝึกฝนผู้อื่นหรือควรหมุนเวียนผู้คนด้วย?

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

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

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

ความรู้สึกของฉันคือไม่

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

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

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

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

ฉันขอแนะนำ:

• หมุนทีมระหว่างโครงการ
• จัดงานเลี้ยงอาหารกลางวันทีมอินเตอร์และกลุ่มสนทนา
• โพสต์รีวิวโครงการจะแก้ไขปัญหาได้อย่างไร (ทีมอื่นเข้าร่วม)
• ตั้งค่าพื้นที่ของรหัสการสรุป wiki ซึ่งอาจนำมาใช้ซ้ำได้ (และผู้ที่จะพูดคุยเกี่ยวกับเรื่องนี้)
• คิดเกี่ยวกับการสร้างแรงจูงใจให้กลับมาใช้ใหม่อย่างจริงจังจ่ายจริง ๆ คนพิเศษสำหรับการทำ หากการใช้องค์ประกอบอีกครั้งช่วยประหยัด 5 วันและค่าใช้จ่าย $ 2,000 ทำไมไม่ให้ $ 200 ของสิ่งที่เป็นผลกำไรพิเศษให้กับทีมในตอนกลางคืนเมื่อสิ้นสุดโครงการ (เมื่อคุณตรวจสอบแล้วว่าการบันทึกเป็นของแท้)

ทีมห้องสมุดคงสงสัยว่าค่าใช้จ่ายไม่มีประโยชน์

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

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

นั่นเป็นงานของนั้นสถาปนิก

ความรับผิดชอบหลักของสถาปนิกซอฟต์แวร์ ได้แก่ :

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

อ่านเพิ่มเติมเกี่ยวกับ: - สถาปนิกซอฟแวร์ - สถาปนิกโซลูชั่น - สถาปนิกองค์กร

คำพูดที่ว่า " การกินอาหารสุนัขของคุณเอง " ตอบปัญหานี้ หากสุดยอด rockstar-coder ของคุณให้กำเนิดห้องสมุดที่เขาไม่เคยใช้ในทางปฏิบัติเขาจะพูดได้อย่างไรว่ามันเป็นสิ่งที่ดี

เหตุผลหลักในการพัฒนาฟังก์ชั่นเข้าสู่กรอบคือ

1. มันมีประโยชน์ต่อผู้พัฒนาซอฟต์แวร์
2. มีบางกรณีที่มันมีประโยชน์
3. มันอาจจะมีประโยชน์กับผู้อื่น

เมื่อคุณกด 2 ฟังก์ชันการทำงานจะมีอยู่แล้วคุณจะส่งต่อให้คนอื่นได้อย่างไร

ฉันมาสายนิดหน่อย แต่ฉันรู้สึกเหมือนไม่มีใครพูดถึงเรื่องนี้:

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

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

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

มิฉะนั้นคุณสามารถจบลงด้วยห้องสมุดที่ดีมาก "ในทางทฤษฎี"!

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

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

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

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