บริษัท สั่งให้เปลี่ยน IDE เป็นธงสีแดงหรือไม่ [ปิด]

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

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

เพื่อให้ชัดเจน: เราเป็นทีม JS ที่ใช้ Backbone และ Eclipse เพียงไม่เข้าใจโค้ด Backbone ได้ดี ซึ่งหมายความว่าผู้ที่อยู่ในทีมที่ใช้ a / good / IDE (PHP Storm) ต้องกลับไปทำสิ่งที่ค้นหามากมาย - ค้นหา - โอ้ - รอ - - - - - - - - - - - - สาม - ขั้นตอน - ชนิดที่ผ่านมา แทนที่จะเป็นเพียง ctrl + การคลิกและการใช้ย้อนหลัง / ไปข้างหน้า - อาจลดประสิทธิภาพการผลิตลงด้วยการพูด 15% และความเพลิดเพลิน 50% ...

นี่เป็นธงสีแดงหรือไม่? ดูเหมือนว่าจะควบคุมและบอกผู้พัฒนา (ไม่ใช่ MS) ตามอำเภอใจและไร้เหตุผลว่า IDE หรือเครื่องมือชุดใดที่จะใช้หากมีการตัดสินและมีประสิทธิภาพแล้ว

"ตอนนี้คำสั่งซื้อโดยไม่มีการพูดคุยลงมาให้ทุกคนเปลี่ยนมาใช้ Eclipse"

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

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

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

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

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

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

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

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

แต่ถ้าคุณเปรียบเทียบมันกับการพยายามมีประสิทธิภาพมากที่สุดมันก็ไม่คุ้มค่าจริงๆ

ใช่มันเป็นธงสีแดงเล็กน้อยที่ฝ่ายบริหารพิจารณาว่าเป็นตัวตัดสินที่ดีกว่าว่าเครื่องมือใดที่คุณจะมีประสิทธิภาพมากกว่าที่คุณเป็น

มันไม่ใช่ธงสีแดงในตัวมันเอง

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

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

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

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

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

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

หากคุณใช้ maven หรือสิ่งที่คล้ายกันมันไม่สำคัญว่า IDE ที่คุณใช้งานอยู่ อาจมีบางกรณีที่มีการเชื่อมโยงกับ IDE ที่เฉพาะเจาะจงเช่น eclipse หากมีปลั๊กอินที่คุณต้องพึ่งพา

ฉันคิดว่าคุณควรเลือก IDE ของคุณเอง IDE ที่คุณทำงานได้ดีที่สุดอย่างไรก็ตามเนื่องจากฉันได้กล่าวไปแล้วว่ามีบางกรณีที่ใช้ IDE มาตรฐานได้ดี

ฉันจะติดตั้ง IDE "mandated" แต่จะยังคงทำงานส่วนใหญ่ของฉันในสิ่งที่ฉันต้องการ IDE - มันไม่เหมือนใครสามารถบอกได้ว่า IDE ถูกใช้เพื่อแก้ไขไฟล์ต้นฉบับ

ในหน้า IDE เทียบกับเครื่องมือแก้ไข ... สำหรับเกือบทุกภาษาฉันต้องการ IDE (IntelliJ) อย่างยิ่งเพราะมีมากกว่าที่คุณสามารถแก้ไขได้ มีบางสิ่งที่ฉันเปลี่ยนกลับเป็น ST2 หรือ Emacs สำหรับ แต่สำหรับการเข้ารหัสแบบวันต่อวันแม้ว่าฉันจะชอบ ST2 / Emacs มากแค่ไหน IDE ก็ชนะเกือบทุกครั้ง

ทุกทีมที่ฉันเคยมีนั้นมี IDE และบรรณาธิการมากมาย: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - มันไม่เคยเป็นปัญหาเลย ไม่เคย

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

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

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

ในร้านทับทิมของเรามีคำแนะนำที่ดีในการใช้ IDE ส่วนใหญ่ของทีมสนุกกับ (RubyMine) เพราะเรารู้ว่ามันทำงานได้ดีและเราสามารถสอนทางลัดอื่น ๆ ได้เป็นต้น

นักพัฒนามีอิสระที่จะใช้ IDE ที่แตกต่างกัน แต่เราต้องการให้พวกเขามีทักษะที่แข็งแกร่งในการแก้ไขนั้นหากพวกเขาเลือก หากเราเห็นใครบางคนดิ้นรนเพื่อนำทางโครงการของพวกเขาหรือแก้ไขข้อความใน FooEdit ที่กำหนดเองของพวกเขา RubyMine สำหรับพวกเขา

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

การถูกบังคับให้สร้างมาตรฐานให้กับ IDE ดูเหมือนจะเป็นความคิดที่แย่มาก

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

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

นี่คือธงสีแดงขนาดใหญ่ บริษัท ทุกแห่งมีความคิดที่โง่ ๆ เช่นนั้น แต่ถ้าธงสีแดงอื่น ๆ มาต่อให้ออกไป

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

ฉันเพิ่งจะใช้คำสั่งเพื่อย้ายไปยัง Eclipse เพื่อหมายความว่าคุณควรมีการตั้งค่า Eclipse ในกรณีที่จำเป็น แต่ทำงานต่อในตัวแก้ไขที่คุณชื่นชอบ (คุณอาจต้องย้ายไปที่ Eclipse ทีละน้อยหาก บริษัท ของคุณเริ่มปรับใช้เครื่องมือเจ๋ง ๆ ภายใน Eclipse)

ธงสีแดง: ฉันจะรอถ้ามีคำสั่งไม่ลงตัวเช่นนี้อีกเล็กน้อยก่อนที่จะเป็นกังวล

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

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

ต้องบอกว่าคุณยังสามารถไปได้ไกลด้วยทีมคู่ที่หลวม ทีมพัฒนาของ Github มีประมาณ 50 คนและพวกเขาทำผิดกฎทุกข้อในหนังสือเรียนการจัดการธุรกิจ พวกเขาดูเหมือนจะทำถูกต้องทั้งหมด ข้อบกพร่องได้รับการแก้ไข (ในที่สุด) คุณสมบัติเพิ่มเข้ามา ไฟดับ

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

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

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

แต่แน่นอนว่ายังมีข้อดีที่จะให้ทั้งทีมใช้เครื่องมือเดียวกัน การแชร์ configs, skripts, plugins และสิ่งของอื่น ๆ ซึ่งไม่สามารถทำได้ด้วยชุดเครื่องมือที่หลากหลาย

ในทางกลับกัน…บิตสุดท้ายนั้นไม่จำเป็นถ้าทุกคนใช้ซอฟต์แวร์ที่ต้องการของเขาหรือเธอ ;)

คุณสามารถ "ใช้" Eclipse ขณะที่ยังพิมพ์อยู่ใน SublimeText2

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

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

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

ในโครงการความปลอดภัยที่สูงขึ้นยังมีข้อกังวลว่า IDEs เก็บไฟล์ชั่วคราวไว้ที่ใดและข้อมูลใดที่ถูกจัดเก็บระหว่างเซสชัน

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

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

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

ค่าสถานะสีแดงนั้นไม่มากนักที่ IDE / ตัวแก้ไขเดียวถูกบังคับใช้กับนักพัฒนาทุกคน แต่การตัดสินใจครั้งนี้และโดยเฉพาะอย่างยิ่งการตัดสินใจที่จะใช้ IDE / ตัวแก้ไขนั้นไม่ได้ทำโดยนักพัฒนาทั้งหมดและอาจไม่มี พวกเขา!?!

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

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