มันเป็นเรื่องธรรมดาแค่ไหนที่ทีมจะเขียนทุกอย่างใน บริษัท ? [ปิด]

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

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

คำถามของฉันคือมันเป็นเรื่องธรรมดาสำหรับทีมที่จะเขียนทุกอย่างด้วยตัวเอง? ฉันควรจะกังวลกับทีมที่ทำ?

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

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

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

• ตอบสนองความต้องการของรหัสที่พวกเขาจะเขียนเอง
• มีให้ใช้ภายใต้ใบอนุญาตที่เข้ากันได้กับรูปแบบธุรกิจของ บริษัท
• การทดสอบรวม
• ผ่านการตรวจสอบรหัส

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

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

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

• จะมี API ต่างประเทศสำหรับนักพัฒนาที่คุ้นเคยกับ jQuery
• จะไม่ถูกบันทึกเป็น jQuery อย่างดี
• จะไม่มีผลการค้นหาของ Google ที่เกี่ยวข้องเมื่อพบปัญหาในการใช้ห้องสมุด
• จะไม่เหมือนกับการทดสอบภาคสนามเป็น jQuery

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

คุณได้อัปเดตคำถามของคุณเพื่อถามว่าการสัมภาษณ์ครั้งที่สองเหมาะสมหรือไม่ มันเป็นอย่างแน่นอน

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

หากคุณอธิบายว่าคุณกังวลเกี่ยวกับจุดยืนของพวกเขาในห้องสมุดภายนอกมีผลลัพธ์ที่เป็นไปได้อย่างน้อยสองรายการ:

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

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

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

เพื่อตอบคำถามของคุณมันเป็นเรื่องธรรมดามากกว่าที่คุณคิดและเป็นเหตุผลที่ต้องกังวล

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

ฉันมีคู่ของเพื่อน ๆ ที่มีทั้ง (สั้น ๆ ) กทำงานอยู่ที่บ้านซอฟต์แวร์ที่มีไม่ได้คิดค้นนี่ซินโดรม ดังนั้นความคิดจะออกมี

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

มันไม่ใช่เรื่องธรรมดาที่ฉันอาศัยอยู่และฉันรู้จัก บริษัท มากมายแม้ว่าจะเป็นเพื่อนร่วมงาน ฉันไปไกลเพื่อบอกว่ามันเป็น "ไม่ต้องขอบคุณ" ในทันทีจากฉัน

ฉันจะไม่สำรอกคะแนนที่ดีที่ทำไปแล้ว แต่ฉันจะเพิ่มสิ่งหนึ่ง

พวกเขาจ้างงานยากขึ้นมาก

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

ตอนนี้แน่นอนว่าจะมีคนที่ชอบความท้าทาย แต่ฉันคิดว่าพวกเขาจะอยู่ในชนกลุ่มน้อย

และจะมี บริษัท บางแห่งที่ดำเนินงานเกี่ยวกับ "มาตราส่วนอินเทอร์เน็ต", Amazon, Facebook และอื่น ๆ ซึ่งพวกเขามีความต้องการที่กำหนดเองที่บ้า แต่อีกครั้งที่อยู่ในชนกลุ่มน้อย

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

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

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

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

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

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

บาง บริษัท อนุญาตให้มีอิสระในการสร้างโครงการโอเพ่นซอร์สของคุณเองซึ่งดูเหมือนว่าเหมาะสมกว่า

โดยส่วนตัวฉันจะไม่ไปสถานที่ที่มีวัฒนธรรมแบบนั้น

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

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

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

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

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

บริษัท ใหญ่ ๆ เขียนทุกอย่างเอง

มีข้อดีหลายประการในการเขียนด้วยตัวคุณเอง:

1. คุณรับประกันได้ว่าจะเป็นเจ้าของซอฟต์แวร์ด้วยตัวคุณเอง
2. คุณสามารถคำนวณปริมาณงานที่จะสร้างได้อย่างถูกต้อง
3. การทำซ้ำขั้นตอนของคุณจะเป็นไปได้แม้ว่าในครั้งถัดไป libs จะไม่พร้อมใช้งาน
4. มันลดความต้องการของคุณลง
5. คุณไม่ได้ทำซ้ำในสิ่งที่คนอื่นทำไปแล้ว
6. คุณรับประกันว่าจะมีคนมากพอที่จะรักษามันไว้
7. คุณสามารถแก้ไขซอฟต์แวร์ทุกส่วนได้
8. ขนาดซอฟต์แวร์ถูก จำกัด ด้วยจำนวนทรัพยากรที่คุณมี

นี่คือวิธีที่แต่ละจุดแตกหักถ้าคุณใช้ห้องสมุดคนอื่น:

1. คนอื่นเป็นเจ้าของ lib
2. คุณไม่รู้ว่าความพยายามในการสร้าง lib นั้นมีมากแค่ไหน
3. ผลิตภัณฑ์เวอร์ชันถัดไปของคุณเป็นไปไม่ได้ที่จะสร้างบนแพลตฟอร์มใหม่เนื่องจาก libs เดียวกันไม่สามารถใช้งานได้อีกต่อไป
4. ความสามารถในการปฏิบัติตามข้อกำหนดนั้นขึ้นอยู่กับว่า lib ใช้งานมาหลายปีแล้วหรือไม่
5. คนอื่นยังใช้ lib เดียวกันรับข้อ จำกัด และคุณสมบัติเดียวกัน
6. เนื่องจากคุณไม่ได้สร้าง libs คุณจึงไม่มีคนมากพอที่จะดูแลรักษาซอฟต์แวร์ทั้งหมดในผลิตภัณฑ์ของคุณ
7. Libs เป็นไบนารีไม่สามารถแก้ไขได้ แม้ว่าแหล่งที่มาจะพร้อมใช้งานคุณไม่มีคนมากพอที่จะแก้ไขโค้ดจำนวนมากได้
8. การบำรุงรักษารหัสที่คุณสร้างขึ้น + libs เป็นความพยายามที่มากกว่าที่คุณคาดไว้