ควรเป็นผู้ดูแลระบบในคอมพิวเตอร์ของตนหรือไม่ [ปิด]

ในสภาพแวดล้อมขององค์กรผู้พัฒนาควรมีสิทธิ์ของผู้ดูแลระบบในคอมพิวเตอร์หรือไม่ ทำไม?

สภาพแวดล้อมทางเทคโนโลยี:

• วินโดว 7
• Visual Studio 2008 และ 2010
• เซิร์ฟเวอร์ SQL

พวกเขาควร? ขึ้นอยู่กับ บริษัท โดยส่วนตัวฉันคิดว่ามันดีตราบใดที่มีกฎบางอย่างที่เข้าใจ

1. การเป็นผู้ดูแลระบบในกล่องของคุณเป็นสิทธิพิเศษที่ไม่ถูกต้อง
   2. การจับไวรัสหลายต่อหลายครั้งจะถูกเพิกถอนอย่างถูกต้อง
   3. การปิดใช้งานตัวแทนของ บริษัท จะได้รับการเพิกถอนอย่างถูกต้อง - AV / สินค้าคงคลัง / การใช้งานซอฟต์แวร์ /
   4. โดยทั่วไปถ้าคุณทำสิ่งที่มีความเสี่ยงเครือข่ายจะถูกเพิกถอนสิทธิ์
2. เครื่องมือใด ๆ ที่คุณติดตั้งจะต้องไม่พึ่งพาโครงการของคุณโดยไม่ได้รับสิ่งเหล่านี้ในรายการที่ได้รับอนุมัติอย่างเป็นทางการ ขอให้อย่าขัดข้องในวันที่ทำการติดตั้งและต้องการติดตั้ง $ random_library บนเซิร์ฟเวอร์ทั้งหมดที่ไม่มีการทดสอบ
3. สำหรับสิ่งใดก็ตามที่นอกเหนือจากแอปพลิเคชั่นปกติที่ติดตั้งทุกที่อื่นการสนับสนุนจะเป็นความพยายามที่ดีที่สุด แผนกช่วยเหลือและ / หรือ sysadmins จะไม่ใช้เวลา 5 ชั่วโมงในการตรวจแก้จุดบกพร่องว่าทำไมคุณถึงมีข้อขัดแย้งของ dll

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

มีทั้งวิทยาศาสตร์และศิลปะในการพัฒนา มันไม่ง่ายเท่ากับ "รู้" สิ่งที่เราต้องการ ถ้าเรามีคำตอบแล้วครึ่งหนึ่งงานของเราก็จะเป็นที่สงสัย; การค้นหาวิธีการที่ถูกต้องมักเป็นการวนซ้ำและอาจเกี่ยวข้องกับเครื่องมือหลายอย่างในลักษณะที่ไม่สามารถคาดการณ์ได้ การขอให้คนกลางติดตั้งสิ่งเหล่านี้ (บ่อยครั้งที่มีเวลาแฝงสูง) เพียงเพื่อหา (ประมาณหนึ่งชั่วโมง) ว่าสำหรับสถานการณ์ของคุณจำเป็นต้องใช้ "super-uber tool addon" เป็นเรื่องโง่

ในขณะที่ VM เหมาะสำหรับการนี้ก็ยังมีจำนวนมากของเครื่องมือในการพัฒนาที่ไม่สามารถเรียกใช้ (ถูกต้องหรือแม้กระทั่งที่ทั้งหมด) ใน VM เพราะตัวเองเป็น VM - และฉันทำในสิ่งที่ไม่ได้หมายถึงชอบ JVM; ฉันหมายถึงเครื่องเต็ม emus / vms เช่นชุดเครื่องมืออุปกรณ์ ความเข้ากันได้มีการปรับปรุง

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

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

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

ในการเป็นนักพัฒนาฉันได้รับสิทธิพิเศษเหนือระดับผู้ใช้พื้นฐาน แต่ต่ำกว่าผู้ดูแลระบบ

ในบางครั้งฉันอาจต้องติดตั้งไลบรารีเพิ่มเติมเพื่อรับแอปพลิเคชันที่ฉันกำลังพัฒนาเพื่อทำงานในสภาพแวดล้อมการผลิตที่กล่าวว่าฉันมีกฎที่เข้มงวดที่ฉันพัฒนาโดย: "สำหรับแอปพลิเคชันใด ๆ ที่ต้องใช้ห้องสมุดบุคคลที่สาม ควรติดตั้งไลบรารีในสภาพแวดล้อม sandbox ก่อนการปรับใช้การผลิตและในบางกรณีก่อนการพัฒนาแอปพลิเคชัน "

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

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

คำเตือน: ฉันเป็นนักพัฒนา

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

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

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

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

สำหรับสภาพแวดล้อมเฉพาะของคุณมีบางสิ่งที่จำเป็นต้องมีสิทธิ์ผู้ดูแลระบบ (ดูสิทธิ์ผู้ใช้และ Visual Studio ) - หากพวกเขาไม่ได้ทำสิ่งเหล่านั้นคุณสามารถตอบคำถาม 2 - 4

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

ฉันคิดว่าคุณกำลังถามคำถามที่ผิดคุณควรจะถาม:

นักพัฒนาซอฟต์แวร์ที่ดีจะทำงานให้กับนายจ้างที่ไม่ให้สิทธิ์ผู้ดูแลระบบบนพีซีของพวกเขาหรือไม่?

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

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

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

IMHO สภาพแวดล้อมการทำงานที่ดีที่สุดที่ฉันเคยเห็นในวันนี้คือที่ที่ทั้งสองกลุ่มถูกแยกออกจากกัน นักพัฒนามีโดเมนของตัวเองในฟอเรสต์ (โดยฝ่ายไอทีควบคุมสิ่งที่โดเมนนี้และผู้ใช้สามารถทำในส่วนที่เหลือของ บริษัท ) และพวกเขาเป็นผู้ดูแลระบบในท้องถิ่นที่มีประสบการณ์ด้วย MCSE ทำหน้าที่เป็นผู้ดูแลโดเมนท้องถิ่น และสามารถทำสิ่งที่พวกเขาต้องการและต้องการใน LAN ท้องถิ่นด้วยนโยบายไอทีเดียว (ไม่มีซอฟต์แวร์ละเมิดลิขสิทธิ์) Corporate IT ไม่รับผิดชอบและไม่สนับสนุน devs และบังคับใช้กฎขององค์กรในระดับสูงเท่านั้น (ไม่มี facebook, สื่อลามกหรือคล้ายกันผ่านไฟร์วอลล์, devs ไม่อนุญาตให้ยุ่งกับ LAN ขององค์กร) และพวกเขาทุกคนมี VPN ที่ใช้ RSA ทำงานจากที่บ้าน ซึ่งทำให้พวกเขาโดยตรงภายใน LAN ของพวกเขา เรียบร้อยใช่ไหม

คำตอบมีแนวโน้มที่จะเป็นอัตนัยและเฉพาะสำหรับแต่ละสถานการณ์ แต่ในกรณีส่วนใหญ่ฉันจะตอบว่าใช่

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

มีอะไรผิดปกติและคุณสามารถล้างและสร้างใหม่ได้ในเวลาไม่กี่นาที

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

ในฐานะนักพัฒนาซอฟต์แวร์มันน่าผิดหวังเมื่อมีบางอย่างไม่ทำงานเพราะเราไม่มีสิทธิ์เข้าถึง

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

ในฐานะที่เป็นนักพัฒนา Java ฉันแทบจะไม่ได้มีความจำเป็นที่จะต้องมีสิทธิผู้ดูแลระบบในเครื่องของฉันอย่างต่อเนื่อง อย่างไรก็ตามมีกรณีที่ถูกต้องตามกฎหมายเมื่อคุณต้องการเข้าถึงการดูแลระบบแบบออนดีมานด์ (.ie. คุณต้องย้ายแล็ปท็อปของคุณข้ามโดเมนที่มีอยู่จริงและคุณต้องเปลี่ยน NIC ของคุณตามลำดับ) นั่นเป็นครั้งเดียวที่ฉันต้องการจริงๆ การเข้าถึงของผู้ดูแลระบบอย่างถาวรและต่อเนื่องในเครื่องของฉัน

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

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

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

มิฉะนั้นจะไม่ จำหลักการของคนที่มีสิทธิ์น้อยที่สุด

มีนักพัฒนาและมีนักพัฒนา หาก "นักพัฒนา" เป็นคนเขียนจาวา JBoss จาวาสำหรับกฎของเอ็นจิน JBoss $ 40 / ชั่วโมงแน่นอนว่าไม่ใช่ หาก "นักพัฒนา" เป็นนักแต่งตัว C / Assembly ที่มีรายรับ $ 350 / ชั่วโมงจะได้รับซอฟต์แวร์ตัดต่อวิดีโอของคุณเพื่อให้ทำงานได้เร็วที่สุดใน GPU แน่นอนว่าใช่

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

นี่ไม่จำเป็นต้องเป็นเรื่องจริง ...

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

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

นักพัฒนาควร (นึกคิด) มีการเข้าสู่ระบบโดเมนที่สอง

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

นี่ควรลดโอกาสของ ItWorksOnMyMachine-itis ที่ปรากฏเป็นครั้งคราว .....

ฉันต้อง (เห็นได้ชัด) ให้เสียงที่ไม่เห็นด้วยและบอกว่าไม่เพียง แต่จะไม่ "heck no" ฉันไม่มีปัญหาในการให้สิทธิ์ผู้ดูแลระบบ devs บน sandboxed VM ที่ไม่มีการเข้าถึงเครือข่าย Zypher คิดว่าถูกต้องแล้ว (แก้ไขตัวหนา):

"1. การเป็นผู้ดูแลระบบบนกล่องของฉันเป็นสิทธิ์ที่ไม่ถูกต้อง" ระบบเหล่านี้เป็นสินทรัพย์ขององค์กรที่ฉันรับผิดชอบในที่สุด เมื่อ Joe Developer ติดตั้งสำเนา Microsoft Bob ของเขาที่ละเมิดลิขสิทธิ์ ("เพราะฉันต้องการมัน") มันจะไม่เป็นเขาที่จะต้องอธิบายว่ามันไม่พบก่อนการตรวจสอบ นักพัฒนาคิดเป็นประจำว่ากฎขององค์กรจะไม่มีผลกับพวกเขา ด้วยการให้ VM แบบแซนด์บ็อกซ์แก่พวกเขาพวกเขาสามารถปฏิบัติตามกฎทั้งหมดที่ทุกคนต้องปฏิบัติตาม (ตั้งแต่ตอนนี้มีเพียง IT เท่านั้นที่สามารถคัดลอกไฟล์ไปยังและจากระบบ) อย่างน่าอัศจรรย์ระบบการขอใช้งานโดยนักพัฒนาอีกครั้งท้องฟ้าไม่ตกอีกต่อไปเมื่อ Joe Developer ทำให้กล่องการพัฒนาของเขายุ่งเหยิง - เขาเพิ่งขอใหม่ (หรือเรียกคืนถ้าเขาขอการสำรองข้อมูล)

นายเดนนี่พูดถึงนักพัฒนาที่ต้องเสียเงินเมื่อพวกเขาต้องรอแอพที่จะติดตั้ง A. สวัสดี ... เวลาของฉันมักจะมีค่าเท่ากับ Joe Developer (ปกติแล้วจะดีกว่าเพราะฉันเก็บ crapware ที่ยังทำงานอยู่เอาไว้จริงๆ) ต้องพูดถึงตลอดเวลาที่ใช้ช่วยผู้พัฒนา Joe debug ผลงานชิ้นเอกชิ้นสุดท้ายของเขา) และ B. เมื่อ dev ไปเกินงบประมาณเพราะพวกเขากำลังรอแอปพลิเคชันและพยายามตำหนิไอที

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

ต้องบอกว่าทั้งหมดนี้ล็อคเดสก์ท็อปของนักพัฒนาค้างหากคุณสามารถแยกนักพัฒนาเส็งเคร็งที่คิดว่าพวกเขามีสิทธิ์รับชมคอลเล็คชั่น Baywatch ของพวกเขาและโกรธเคืองเพื่อเรียนรู้ว่าพวกเขาไม่สามารถติดตั้งเครื่องเล่น babewatch เพื่อดูพวกเขา โอเพ่นซอร์ส ") คุณอาจคลายได้ แต่สำหรับนักพัฒนาที่ยอดเยี่ยมทุกคนพวกเขา "ได้รับ" มันมีอีก 10 ที่ บริษัท ของคุณจะจ้างแอพพลิเคชั่นแนวดิ่ง 200 ล้านดอลลาร์แทนและนั่นคือสิ่งที่คุณต้องระวัง

แก้ไข: เป็นไปได้ค่อนข้างแน่ใจว่านักพัฒนาที่ฉันเคยเห็นนั้นน่าเบื่อผิดปกติ (การสำรวจการเพาะปลูกปัจจุบันเพียง 1 คนเคยได้ยิน stackoverflow เพื่อให้ได้มาตรฐานในระดับหนึ่ง) จุดเริ่มต้นของมุมมองที่ฉันเริ่มต้นคือ "สิ่งที่คุณต้องทำในสิ่งที่ บริษัท จ่ายให้คุณทำ" หากคุณต้องการสิทธิ์ผู้ดูแลระบบคุณจะได้รับ แต่คุณไม่ควร stqart กับพวกเขาและถ้าฉันสามารถให้กล่องที่ตรงไปตรงมาฉันไม่สนใจสิ่งที่คุณทำกับมันและที่ทำงานแล้วเราทั้งสองไปกันได้ดี