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

ฉันต้องการส่งคำถามนี้ออกไปเพื่อดูว่าสื่ออยู่ที่ไหนอย่างน่าสนใจ

ฉันจะยอมรับว่าในช่วง 12 เดือนที่ผ่านมาฉันเลือก TDD และค่า Agile จำนวนมากในการพัฒนาซอฟต์แวร์ ฉันรู้สึกสับสนมากกับการพัฒนาซอฟต์แวร์ที่ดีขึ้นเรื่อย ๆ จนฉันไม่เคยละทิ้งพวกเขาออกจากหลักการ จนกระทั่ง ... ฉันได้รับการเสนอบทบาทการทำสัญญาที่สองเท่าของฉันกลับบ้านจ่ายสำหรับปี

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

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

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

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

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

ปรับปรุง

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

นี่คือที่ฉันคิดว่านักพัฒนาทุกคนควรรู้จักการจัดการโครงการนิดหน่อย ทุกอย่างเป็นการแลกเปลี่ยนระหว่างเวลาเงินและทรัพยากร พิจารณาทรัพยากรด้วยตัวเอง

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

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

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

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

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

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

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

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

ฉันต้องการพูดถึงอดีตเพื่อนร่วมงานของฉัน เขากล่าวว่าเมื่อใดก็ตามที่เขากำลังมองหางานหรือโครงการพาร์ทไทม์มีสามเกณฑ์ที่โครงการต้องปฏิบัติตาม:

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

เมื่อฉันอ่านคำถามของคุณโครงการนี้เป็นไปตามเกณฑ์ล่าสุดเท่านั้น

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

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

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

ไม่เคย

ชีวิตนั้นสั้นเกินไป (โดยเฉพาะอย่างยิ่งเมื่อคุณแก่) ที่จะทำสิ่งที่คุณจะเกลียด

แน่นอนว่ามันทำให้การเปลี่ยนงานยากขึ้นและมีที่ทำงานน้อยลง

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

ในระยะสั้นวิธีการพัฒนาไม่ได้เป็นส่วนหนึ่งของคุณ มันไม่ได้เป็น relgion และไม่ใช่คุณ มันเป็นเครื่องมือ ทำในสิ่งที่คุณได้รับการบอกวิธีการบอกและทำเงินพิเศษ ระบบหลายพันระบบได้รับการพัฒนาและทำงานอยู่ทุกวันนี้หากปราศจาก TDD, Code Smell และอื่น ๆ ในอีกไม่กี่ปีที่ผ่านมาไม่มีใครรู้ว่าคำเหล่านี้มีความหมายอย่างไรเพราะวิธีการต่างๆ ทำงานอย่างหนักตามที่คุณบอกและรับเงินมันเป็นที่นิยมตลอดเวลาและตลอดเวลา :)

เพียงแค่ให้แน่ใจว่าการทำงานกับทีมใหม่เป็นการลงทุนที่คุ้มค่ากับเวลาของคุณ

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

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

ฉันจะไม่ทำงานที่ไหนสักแห่งที่ไม่อนุญาตให้ฉันทำงานตามที่ฉันต้องการ โดยที่ฉันหมายความว่าฉันไม่ต้องการที่จะ micromanaged

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

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

ถ้าฉันทำอย่างนั้นไม่ได้ฉันก็ไม่รู้ว่าจะไปทำงานที่นั่นหรือเปล่า

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