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

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

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

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

อย่างไรก็ตามนี่เป็นเรื่องปกติหรือไม่ ในความคิดของฉันฉันทำผลงานเทียบเท่ากับทีมนักพัฒนาทั้งหมด

ฉันเป็นคนงี่เง่าเมื่อฉันคาดหวังว่าสิ่งต่าง ๆ ในตอนแรกจะแตกต่างกันอย่างไร

ฉันเดาว่าโพสต์นี้ได้กลายเป็นเรื่องอื้อฉาวใหญ่ แต่โปรดบอกฉันว่ามันไม่เหมือนกันสำหรับนักพัฒนาทุกคน

PS เงินเดือนของฉันเกือบเท่ากันถ้าไม่ต่ำกว่าแคชเชียร์ที่ซุปเปอร์มาร์เก็ต

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ป.ล. เงินเดือนของฉันใกล้เคียงกันถ้าไม่ต่ำกว่าพนักงานแคชเชียร์ที่ซุปเปอร์มาร์เก็ต

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

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

มีความคิดเพิ่มเติมเล็กน้อยที่ฉันมีในหัวข้อนี้

1. ทำในสิ่งที่คุณรัก. หากคุณไม่รักให้เตรียมตัวสำหรับความพยายามที่จะค้นหาว่าคุณอาจรักมันคืออะไร

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

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

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

มุ่งเน้นไปที่ความสามารถและทักษะที่คุณกำลังเติบโต ... สิ่งเหล่านี้จะนำคุณผ่านโอกาสต่อไปในอาชีพของคุณ

คุณกำลังจัดการกับปัญหาต่าง ๆ ที่นี่ ... เริ่มต้นด้วยสิ่งที่ชัดเจน ...

เป็นปกติหรือไม่

ไม่มีทาง. แต่ ... มันเป็นเรื่องธรรมดาเหรอ? น่าเสียดายใช่

เกี่ยวกับแห้ว Bug-Fixing

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

Surface สำหรับบั๊กและค่าใช้จ่ายเพิ่มเติม

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

เสียงรบกวน / หมอกในบันทึกของคุณ

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

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

คุณสามารถทำบางสิ่งเกี่ยวกับมันได้หรือไม่

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

โครงการจากนรก

รหัส Crap, กลุ่มโปรแกรมเมอร์, การทำสำเนา, สถาปัตยกรรม Crap

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

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

ยินดีต้อนรับสู่วิศวกรรมซอฟต์แวร์อุตสาหกรรมจริง!

และคุณรู้ว่าอะไรสนุก บ่อยครั้งที่มันเลวร้ายลงในโลกการพัฒนาเว็บ สนุก! :)

มีโครงการ & คำขอมากเกินไปไม่มีเวลาและมือเพียงพอ

ปัญหาอยู่ที่นี่อาจใน:

• การจัดการของคุณ (อาจจะไม่รู้ตัว) เหยียดหยามคุณ ,
• เพื่อนร่วมงานของคุณ (อาจจะไม่รู้ตัว) เหยียดหยามคุณ ,
• ของคุณ (อาจจะไม่รู้) ไม่ครอบคลุมตูดของคุณและการต่อสู้การต่อสู้ของคุณพอ

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

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

เรื่องเล็ก ๆ น้อย ๆ ส่วนตัวที่นี่:ฉันได้ฝึกงานเมื่อสองสามปีก่อนและในวันสุดท้ายของฉันเมื่อฉันได้รับการประเมินเจ้านายของฉันบอกฉันแม้จะพอใจกับผลงานโดยรวมของฉันมากผู้จัดการคนหนึ่งรู้สึกว่าฉัน มีการขนถ่ายบางส่วน "ไม่สนุกมากงาน" ในฝึกงานอีกเมื่อพวกเขาคาดว่าฉันจะรับพวกเขา ฉันรู้สึกเสียใจที่ทำให้พวกเขารู้สึกท้อแท้และด้วยความคิดที่ว่าฉันดูเหมือนว่าฉันกำลังหย่อนยานเมื่อความตั้งใจของฉันตรงข้ามกับที่แน่นอน: ฉันพยายามที่จะคว้างานที่หนักกว่านี้ - การดึงปัญหา. ฉันรู้น้อยว่าถ้าฉันอยู่ในตำแหน่งของเขาฉันจะเบื่อกับการขาดความท้าทายและอาจรู้สึกถึงวิธีที่เขาทำ ประเด็นคือคุณต้องสื่อสารเพื่อให้แน่ใจว่าไม่มีใครทำสมมติฐานที่ผิดพลาดเกี่ยวกับ 3 สิ่งที่แตกต่างกันมาก:

• คุณสามารถทำอะไร ,
• สิ่งที่คุณต้องการที่จะทำ ,
• และสิ่งที่คุณยินดีที่จะทำ

ดังนั้นจึงเป็นความผิดของคุณบางส่วนที่ทำให้มันกลายเป็นแบบนี้ แต่มันเป็นเรื่องปกติมันเป็นบทเรียนที่ทุกคนต้องเรียนรู้ มันถือในตัวอักษรสองตัว: N - O

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

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

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

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

คำขอเปลี่ยนแปลง 180 องศา

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

"คำขอเปลี่ยนแปลง 180-degress" ในขณะที่คุณเรียกพวกเขาอย่างสวยงามและอย่างชัดเจนนั้นเป็นสัญญาณที่ชัดเจนว่าความต้องการนั้นเลือนหายไปจากการเดินทางและไม่มีใครพยายามอย่างหนักพอที่จะสกัดพวกเขาและล้างออกตามกาลเวลา

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

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

หากไม่มีขอบเขตไม่มีข้อกำหนดที่ชัดเจนเมื่อสิ้นสุดการอภิปราย

อีเมลโอเวอร์โหลด

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

• การพูดคุยกับคนหน้าเพื่อใบหน้า ,
• พูดคุยกับผู้คนทางโทรศัพท์
• พูดคุยกับผู้คนผ่าน IM
• พูดคุยกับผู้คนผ่านทางอีเมล

อีเมลเป็นสิ่งที่ดีสำหรับการติดตามรับการยืนยันสำหรับการส่งบันทึก

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

นี่คือวิศวกรรมซอฟต์แวร์ บ่อยครั้งจะมีประสิทธิผลมากขึ้นเมื่อคุณไม่พิมพ์บนแป้นพิมพ์และสามารถลดขนาดของอึที่คุณต้องรับมือด้วย

การทำงานที่มีค่าของทีม

คุณทำสิ่งที่คุ้มค่ากับการทำงานของทีมหรือไม่? อาจจะ.

คุณทำสิ่งที่คุ้มค่ากับการทำงานของทีมหรือไม่? อาจจะไม่.

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

ฉันเป็นคนงี่เง่าเมื่อฉันคาดหวังว่าสิ่งต่าง ๆ ในตอนแรกจะแตกต่างกันอย่างไร

ไม่มี ใหม่สำหรับงานปาร์ตี้ มันเหมือนกับการแขวนหรือความสัมพันธ์ครั้งแรก คุณจะได้รับมัน

ฉันเดาว่าโพสต์นี้ได้กลายเป็นเรื่องอื้อฉาวใหญ่ แต่โปรดบอกฉันว่ามันไม่เหมือนกันสำหรับนักพัฒนาทุกคน

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

ป.ล. เงินเดือนของฉันใกล้เคียงกันถ้าไม่ต่ำกว่าพนักงานแคชเชียร์ที่ซุปเปอร์มาร์เก็ต

ฉันทำเงินเดือนที่เหมาะสมกับงานที่ดูเหมือนว่าเส็งเคร็ง ไม่ใช่ตัวเลขบนเช็คที่นับ แต่เป็นบริบท สิ่งที่คุณทำอายุที่คุณอาศัยและทำงาน ฯลฯ ...

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

มันง่าย:

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

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

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

• คุณสามารถวัดด้วยตัวคุณเองถ้าคุณทำมากกว่าเพื่อนหรือไม่
• คุณสามารถยืนหยัดอยู่ได้ถ้าพวกเขาบอกว่าคำขอของคุณไม่เป็นธรรม

นอกจากความคิดเห็นของคนอื่น:

1. ใช่เป็นเรื่องปกติที่พนักงานระดับเริ่มต้นจะได้งานที่ไม่มีใครต้องการทำ

2. คุณควรเห็นสิ่งนี้ว่าเป็นปัจจัยเสริมสำหรับอาชีพในอนาคตของคุณ

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

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

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

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

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

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

• ดูแลงานในมือของคุณเอง (Kanban) เมื่องานใหม่มาถึงจุดสิ้นสุดและบอกเวลาที่คาดว่าจะแล้วเสร็จ

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

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

• ไม่มีการสลับโครงการระหว่างวัน วันนี้คุณแค่ทำงานกับโปรเจ็กต์ X และคุณจะเริ่มงานอื่นสำหรับ Y ในวันพรุ่งนี้

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

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

ลองทำบทง่ายๆ มีผู้จัดการและโครงการสาม (ซาเวียร์กับโครงการ X, อีวอนน์กับโครงการ Y และ Zed กับโครงการ Z) คุณมีงานในมือเป็นเวลาสองสัปดาห์ 5 วันสำหรับ X และ 5 วันสำหรับ Y

• Z ขอให้คุณทำงานบางอย่าง (1 วัน)
• คุณตอบกลับว่าจะดำเนินการภายใน 11 วัน
• Z ตอบว่ามันเป็นงานง่ายและไม่ควรใช้เวลามากกว่าหนึ่งวัน (สังเกตว่า Z ใช้แรงกดดันเล็กน้อย)
• คุณตอบว่าคุณกำลังทำงานให้กับ X และใหม่กว่าสำหรับ Z คุณสามารถทำงานของเธอหลังจากนั้น
• Z ตอบคุณควรทำงานของเขาในทันที (เพิ่มแรงกดดันละเมิดโดยตรงของดินแดน X และ Y)
• คุณตอบว่าการทำหน้าที่ของเธอจะทำให้ X และ Y ล่าช้าออกไปเขาควรถามพวกเขาก่อน คุณยัง CC X และ Y

ตอนนี้มีสองปลาย:

• ผู้จัดการจะเริ่มเห่ากันและกันอีเมลจำนวนมากอาจมีการประชุม ... คุณควรอยู่ห่าง ๆ และให้ผู้ชนะมอบหมายงานให้คุณ

• จะไม่มีอะไรเกิดขึ้น Z จะถามคุณสองวันต่อมาว่างานของเขาอยู่ที่ไหน คุณตอบว่าคุณกำลังทำงานให้กับ X ในปัจจุบันและเขาไม่ได้พูดถึงอะไรเกี่ยวกับโครงการ Z อีกครั้ง CC X

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

เจ็ดปีที่ผ่านมาผมทำผลงานการบำรุงรักษาสวยมาก 100% ในขณะที่เขียนบทความเกี่ยวกับเรื่อง: ศิลปะของการเขียนโปรแกรมการบำรุงรักษา ส่วนหนึ่งคุณอาจพบว่ามีประโยชน์:

1. ไปชอบมัน

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

ปัญหาของคุณดูเหมือนว่าบางสิ่งบางอย่างที่คุณได้ยินบ่อยขึ้นเกี่ยวกับ แต่ดูเหมือนว่ามันจะเป็นงานที่ได้อย่างง่ายดายสามารถพอดีกับThe Daily WTF

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

นอกจากนี้คุณยังอาจต้องการอ่านสตีฟ McConnell หนี้ทางเทคนิค เขามีประเด็นที่น่าสนใจ ในการคุยเทคโนโลยี Google, เคน Swaber พูดเกี่ยวกับการพัฒนาซอฟต์แวร์เปรียว ส่วนที่ดีคือเรื่องราวที่คล้ายกับของคุณ เขาพูดเกี่ยวกับโครงการซอฟต์แวร์ที่ได้กลายเป็น "braindead" หลังจาก 10 ปีของการเขียนโปรแกรมโดยโปรแกรมเมอร์ต่าง ๆ โดยที่ไม่เคยทำใด ๆrefactoring ฉันคิดว่าถ้าคุณเห็นวิดีโอนี้คุณจะเห็นความคล้ายคลึงกันมากมายกับสิ่งที่คุณอธิบาย

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

ฉันเข้าหาปัญหาที่คล้ายกันได้อย่างไร:

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

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

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

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

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

การเขียนโปรแกรมการบำรุงรักษาไม่ควรหมายถึงการทำให้รหัสไม่ดี

ฉันได้รับอีเมลนี้เมื่อห้าปีที่แล้วจากหนึ่งในเพื่อนของฉัน

Email body:    

วิศวกรฝึกหัดคนใหม่ที่เข้าร่วมถามเจ้านายของเขาว่า "ความหมายของการประเมินคืออะไร"

บอส: "คุณรู้จักความหมายของการลาออกหรือไม่"

ฝึกงาน: "ใช่ฉันทำแล้ว"

บอส: "งั้นให้ฉันทำให้คุณเข้าใจว่าการประเมินคือการเปรียบเทียบกับการลาออก"

Comparison study: Appraisal and Resignation
|---------------------------------+----------------------------------| 
|       Appraisal                 |       Resignation                |
|---------------------------------+----------------------------------|
|     In appraisal meeting they   |    In resignation meeting they   | 
|     will speak only about your  |    will speak only about your    |
|     weakness, errors and        |    strengths, past achievements  |
|     failures.                   |    and success.                  | 
|---------------------------------+----------------------------------|
|     In appraisal you may need to|    In resignation you can easily |
|     cry and beg for even 2%     |    demand (or get even without   | 
|     hike.                       |    asking) more than 10-20% hike.|
|                                 |                                  |
|---------------------------------+----------------------------------| 
|     During appraisal, they will |    During resignation, they will |
|     deny promotion saying you   |    say you are the core member of|
|     didn't meet the expectation,|    team; you are the vision of   | 
|     you don't have leadership   |    the company how can you go,   |
|     qualities, and you had      |    you have to take the project  |
|     several drawbacks in our    |    in shoulder and lead your     | 
|     objective/goal.             |    juniors to success.           |
|---------------------------------+----------------------------------|
|     There is 90% chance for not |    There is 90% chance of getting|
|     getting any significant     |    immediate hike after you put  |
|     incentives after appraisal. |    the resignation.              |
|---------------------------------+----------------------------------|

Trainee: "ใช่แล้วนายพอฉันเข้าใจอนาคตของฉันแล้วสำหรับการประเมินฉันจะต้องลาออก ... !!!"

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

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

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

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

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

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

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

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

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

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

หมายเหตุ: ฉันรู้สึกว่าการระบุแหล่งที่มาของคำตอบนี้ควรไปที่ Jeff Atwood เพราะฉันเชื่อมโยง 3 บทความของเขา

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

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

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

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

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

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

1. คุณมีหลักฐานว่าการปรับโครงสร้างจะประหยัดเงิน ร่างข้อเสนอสำหรับโครงการการเปลี่ยนโครงสร้างและแสดงให้เห็นว่าธุรกิจสามารถประหยัดเวลาและเงินได้มากเพียงใด สรุปสิ่งที่คุณต้องการเปลี่ยนแปลงกับโค้ดและสิ่งที่ต้องใช้เวลานานเท่าใด

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

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

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

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

โชคดี.

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

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

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

ขอให้โชคดีและฉันหวังว่าคุณและเพื่อนร่วมงานของคุณจะเข้าใจแรงโน้มถ่วงหรือความพยายามของคุณ!

ประสบการณ์ส่วนตัว

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

หลังจากเลิกกับมันมาสองปีแล้วฉันก็ลาออกและพบงานเขียนโค้ดอีกสองสามเดือนต่อมาซึ่งเหมาะกับฉันอย่างสมบูรณ์แบบ

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

เงินเดือน

หากคุณต้องการเงินมากขึ้นคุณมักจะได้รับมัน ฉันสามารถต่อรองเงินเดือนของฉันภายในไม่ถึงสองปีเพื่อเพิ่มขึ้น 33%

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

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

เนื่องจากฉันยังไม่สามารถแสดงความคิดเห็นได้เพราะฉันเป็นคนแฝงตัวในไซต์ Stack Exchange นี้ฉันจะเพิ่มข้อมูลที่นี่

1. เมื่อคุณเพิ่งเริ่มต้นเงินเดือนของคุณจะไม่เป็นตัวเอกเว้นแต่คุณจะไปทำงานกับ บริษัท ใหญ่ ๆ อย่าง Microsoft, Amazon หรืออะไรทำนองนั้น แต่มันไม่ควรเป็นของพนักงานขายของชำ! อย่าทนกับสิ่งนั้นเป็นเวลานานรับประสบการณ์ในการทำสิ่งที่คุณทำและเดินหน้าต่อไปเมื่อมีโอกาสที่ดีกว่า

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

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

4) ถ้าคุณไม่มีความสุข ชีวิตสั้นเกินไปที่จะจัดการกับคนโง่

ทั้งหมดที่ดีที่สุด

คุณเริ่มใช้ตัวติดตามปัญหาเพื่อติดตามรายการสิ่งที่ต้องทำของคุณ

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

นอกจากนี้หากพวกเขาจ้างนักพัฒนาที่สอง (หรือคุณออกและตอนนี้การแทนที่ของคุณใช้ภาระงานของคุณ) สิ่งนี้จะช่วยในการจัดการภาระงานและคุณจะสามารถหลีกเลี่ยงการก้าวเท้าซึ่งกันและกัน

วิธีเดียวที่จะทำลายโซ่นี้ได้คือการพัฒนาโครงสร้างพื้นฐานใหม่ที่ออกแบบมาเพื่อความยืดหยุ่นและได้รับการทดสอบอย่างเต็มหน่วย + การรวมเข้าด้วยกัน

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

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

ในระยะยาวสามารถลดเวลาในการพัฒนาแอพพลิเคชั่นใหม่และลดเวลาการบำรุงรักษาแอพพลิเคชั่นที่มีอยู่ในอนาคตลงอย่างมาก

การพัฒนาใหม่จะต้องมีการอุทิศอย่างน้อย 80% (ควรมากกว่า) โดยมีทีมงานมากกว่าหนึ่งที่นักพัฒนาคนหนึ่ง (จิตใจสองสามคนดีกว่าหนึ่ง) นักพัฒนาทั้งหมดจะต้องสามารถคิดอย่างสร้างสรรค์และทำลายแนวคิดที่มีอยู่

ลองกำหนดและออกแบบระดับสูงเช่นโครงสร้างพื้นฐานใหม่จากนั้นให้คำจำกัดความกับเพื่อนและการจัดการ

จากสภาพการทำงานของคุณขอให้นำทีมโครงสร้างพื้นฐานใหม่ที่เกี่ยวข้องกับปัญหาเหล่านี้ (ตามคำจำกัดความและการออกแบบของคุณ) และนำนักพัฒนาใหม่มาบำรุงรักษาสิ่งเก่าในขณะที่คุณช่วยเหลือพวกเขาหากจำเป็น (สูงสุด 10-20% ของ เวลา). หากฝ่ายบริหารเห็นด้วยกับความคิดคุณสามารถขอให้เจรจาใหม่ข้อกำหนดของคุณ เตรียมพร้อมที่จะหางานใหม่หากพวกเขาปฏิเสธ (จำไว้ว่างานของคุณต้องใช้ทักษะความรู้และประสบการณ์คุณไม่ใช่เรื่องง่ายที่จะเปลี่ยนเมื่อพวกเขาจ่ายเงินให้คุณเชื่อ)

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

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

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

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

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

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

คำตอบคือพยายามและอธิบายในแง่ที่สามารถเข้าใจได้

• มันก็เหมือนกับการเปลี่ยนถ่ายน้ำมัน พวกเขาไม่ด่วน .... แต่ต้องทำอย่างสม่ำเสมอไม่น้อย
• ทาสีให้เป็นสนิมและมันจะดูดี จนกว่าจะมีเลือดออก
• สร้างโต๊ะหลังคาลานหลังคาใหม่โดยไม่ต้องสนับสนุน strengthing อาจใช้งานได้สักพัก จากนั้นมันจะยุบและทำร้ายผู้คนและคุณจะต้องรับผิดชอบ
• a / c ยอดเยี่ยม หน่วยหน้าต่างเหมาะสำหรับห้องหนึ่งหรือสองห้อง พยายามใส่เครื่องปรับอากาศแบบหน้าต่างจำนวน 146 เครื่องในอาคารห้องเก็บของและคุณจะมีปัญหา ...
• การสอนเด็ก 5 คนเป็นเรื่องปกติ 10 ก็ไม่ได้แย่เกินไป แต่มีข้อ จำกัด อยู่ ลองสอนเด็ก 75 คนอย่างไม่เป็นทางการและคุณจะเห็นสิ่งนี้

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

ในที่สุดก็รู้ว่าเรื่องนี้เป็นเรื่องปกติและมาตรฐาน 20 ปีที่ผ่านมาก่อนเปรียว tdd, bdd และ refactoring กลายเป็นบรรทัดฐานมากขึ้น คุณอาจจะพูดคุยกับคนอาวุโสที่ตอบกลับทันทีว่า "ฉันทำได้ดีแล้วและทำงานได้ดี blah, blah, blah" ม้าและรถม้าทำงานได้ดีเมื่อ 150 ปีก่อน ในด้านเทคโนโลยีเทคนิคจาก 20 ปีที่แล้วล้าสมัยเหมือนการขนส่งจาก 150 ปีที่แล้ว หากพวกเขาปฏิเสธการปรับนี้ เพิ่งรู้ว่าพวกเขาจะไม่จ้างนักพัฒนาเทคโนโลยีในปัจจุบันที่เหมาะสม พวกเขาจะได้รับสิ่งที่เลวร้ายที่สุดและมันจะทำร้ายธุรกิจของพวกเขาอย่างมาก หากพวกเขาพึ่งพาเทคโนโลยีและไม่สามารถปรับตัวได้พวกเขาจะล้มเหลวและท้ายที่สุดอาจเป็นรางวัลที่ดีที่สุดสำหรับคุณ มัน'

ดูเหมือนว่าการจัดการของคุณพื้นฐานไม่เคารพคุณหรือเข้าใจภาระงานของคุณ

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

นอกจากนี้คุณควรทำอย่างน้อย 2x (อย่างน้อย) สิ่งที่พวกเขาจ่ายให้คุณ

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

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

การเป็นฮีโร่ในทีมหนึ่งจะทำให้คุณเบื่อหน่าย

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

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

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

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

นี่เป็นปัญหาการจัดการโครงการ ใช้การจัดการโครงการบางประเภทเพื่อตัดสินใจว่าสิ่งใดที่มีความสำคัญสูงสุดในการทำงาน

a) คุณต้องมีรายการค้างเพื่อทำงาน คุณวางแผนที่จะปรับปรุงโค้ดใน Backlog

b) ข้อบกพร่องทั้งหมดไปที่ค้าง

c) งานในมือได้รับการจัดลำดับความสำคัญ

d) คุณทำตามลำดับความสำคัญทั้งหมด

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

มันง่ายที่สุดถ้าคุณเพียงทำการปรับปรุงการเพิ่มขึ้นทีละน้อยในขณะที่คุณผ่านส่วนที่มีปัญหา / ข้อบกพร่องเพื่อแก้ไข จากนั้นคุณสามารถบอกผู้บริหาร "ฉันต้องแก้ไข A แต่ B เสียพื้นฐานและฉันต้องแก้ปัญหา C เพื่อแก้ไขทั้งหมดเพื่อให้ D จะง่ายขึ้น / ถูกกว่าในอนาคต" โดยที่ A = ข้อผิดพลาด B = anti-pattern, C = Solution, D = กำไรในอนาคต

หากคุณไม่สามารถปรับงานให้คุ้มค่ากับการลงทุนได้นักธุรกิจจะไม่ยอมรับมัน

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

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

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