วิธีจัดการกับความคิดโฆษณาเฉพาะกิจ?

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

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

— Rotian
แหล่งที่มา

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

— Rig

ยินดีต้อนรับสู่การพัฒนาซอฟต์แวร์!

— yannis

@YannisRizos ไม่ไม่! ;)

— Rotian

@Rotian นี้เป็นสิ่งจำเป็นเกือบอ่าน: joelonsoftware.com/articles/fog0000000332.html ล้าสมัยไปหน่อย แต่ก็ยังเป็นแหล่งข้อมูลที่ดีและน่าจะคุ้มค่ากับคำตอบของตัวเอง

— K.Steff

ในวงกว้างฉันแนะนำ "Uncle Bob" / Clean Code / และ / Clean Coder / ฉันไม่เห็นด้วยกับทุกสิ่งที่เขาพูดในหนังสือเหล่านั้น แต่พวกเขาเป็นอาหารที่ดีมากสำหรับความคิด พวกเขาเปิดตาของฉันอย่างแน่นอน!

— Michael Scott Shappe

คำตอบ:

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

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

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

— Michael Scott Shappe
แหล่งที่มา

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

— Rotian

+1 เป็นความเปลี่ยนแปลงที่คุณต้องการเห็นในทีมของคุณ กำหนดมาตรฐาน

— Scott C Wilson

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

— Erik Dietrich

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

— Michael Scott Shappe

ไม่มีอะไร?

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

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

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

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

— Telastyn
แหล่งที่มา

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

— 9000

@ 9000: OP บอกว่ามันเป็นเรื่องของกำหนดการและการจัดการดังนั้นฉันคาดเดา (หวัง) ว่ามันกดดันเวลาเป็นส่วนใหญ่ การประเมินผลงานจริงที่เกี่ยวข้องกับการพัฒนาซอฟต์แวร์ต่ำเกินไปไม่ใช่เรื่องแปลก

— Telastyn

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

— Michael Scott Shappe

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

— Telastyn

@ 9000 และ Telastyn - ใช่ทั้งฉันคิดว่า - ความไม่รู้บางอย่างเกี่ยวกับความจริงที่ว่ามีหนี้ทางเทคนิครวมอยู่กับสภาพแวดล้อมที่ส่งเสริมการแก้ไขปัญหาด้วยเหตุผลที่แตกต่างหลากหลาย (ไม่ว่าจะเป็นเวลานิสัย ฯลฯ )

— Rotian