ฉันเป็นนักพัฒนาใหม่ที่ค่อนข้างใหม่จากวิทยาลัย ในขณะที่อยู่ในวิทยาลัยและในระหว่างการหางานฉันพบว่ามีวิธีการพัฒนาซอฟต์แวร์ที่ "ทันสมัย" จำนวนมากที่การศึกษาของฉันขาด: การทดสอบหน่วยการบันทึกการทำฐานข้อมูลให้เป็นมาตรฐานการพัฒนาแบบเปรียว (เทียบกับแนวคิดแบบเปรียวทั่วไป) คู่มือ, การเปลี่ยนโครงสร้าง, การตรวจสอบโค้ด, ไม่มีวิธีการเอกสารที่เป็นมาตรฐาน (หรือแม้กระทั่งข้อกำหนด), ฯลฯ

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

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

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

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

ฟังดูเหมือนว่าคุณกำลังเอาเกวียนมาก่อนม้า

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

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

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

Java? ทันสมัย?! คุณล้มเหลวในการกระโดดข้ามรั้วแรก หากคุณต้องการทันสมัยและหลีกเลี่ยง "การฆ่าตัวตายอย่างมืออาชีพ" คุณต้องเขียนรหัสสนิม แน่นอนว่าในสัปดาห์หน้าทุกอย่างจะเปลี่ยนแปลงและคุณจะต้องเรียนรู้สิ่งใหม่ ๆ เพื่อให้ทัน!

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

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

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

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

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

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

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

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

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

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

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

ตอนนี้สำหรับการนำเสนอ "แนวปฏิบัติที่ดีที่สุด" เหล่านั้นมีสองวิธีในการอธิบายให้ทีมของคุณ:

• เพราะฉันบอกว่าพวกเขาเป็นแนวปฏิบัติที่ดีที่สุดและนั่นก็เพียงพอแล้ว
• เพราะมันมีประโยชน์และช่วยแก้ปัญหา

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

สำหรับวิธีการที่สองในการทำงานจะต้องมีความตระหนักว่าปัญหาที่มีอยู่ ดังนั้น:

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

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

ยินดีต้อนรับสู่โลกขององค์กรไอทีเด็กชาย! :-P

¹ : โอเคบางทีฉันกำลังเร่งรีบนิดหน่อย แต่ก็ไม่มากเกินไป

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

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

การควบคุมแหล่งที่มา

คุณไม่ได้พูดถึงมันหวังว่าเพราะมันมีอยู่แล้ว แต่ในกรณีที่มันไม่ได้เริ่มต้นที่นั่น

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

และคุณสามารถเริ่มคนเดียวได้หากไม่มีใครซื้อในตอนแรก

คำตอบโดยตรง

คำตอบอื่น ๆ ให้ 'meta-points' ที่ดีเกี่ยวกับการใช้แนวทางปฏิบัติที่ดีขึ้น แต่เพื่อให้คำแนะนำที่เกี่ยวข้องโดยตรงกับคุณนี่เป็นคำสั่งที่ดีที่สุดเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุดที่ฉันแนะนำให้ทีมของคุณ (หรือทีมใด ๆ )

1. การควบคุมแหล่งที่มา
2. การติดตามปัญหา (การจัดการโครงการและงาน)
3. สร้างอัตโนมัติ¹
4. การปรับใช้อัตโนมัติ

^{1 _{วิธีปฏิบัติที่เกี่ยวข้องอย่างมากคือการสร้างเอกสารอัตโนมัติหรืออย่างน้อยที่สุดการตั้งค่าสภาพแวดล้อมการสร้างและการพัฒนาของแต่ละแอพหรือโครงการซอฟต์แวร์ที่คุณกำลังพัฒนาหรือบำรุงรักษาอยู่ มันมีประโยชน์น้อยกว่ามากเพราะคุณ (หวังว่า) จะทำสิ่งนี้ไม่บ่อยนักหรือไม่ค่อยได้}}

อย่างอื่น

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

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

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

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

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

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

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

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

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

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

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

ค้นหาข้อบกพร่อง แก้ไขข้อบกพร่อง แสดงการแก้ไข

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

มันเป็นเรื่องที่ดีที่คุณจะสามารถค้นหากรณีที่เกิดขึ้นจริงของข้อมูลที่ไม่สอดคล้องกัน ตอนนี้คุณพบสองสิ่ง:

1. ข้อบกพร่องในข้อมูลของคุณ

2. ข้อผิดพลาดในสกีมาฐานข้อมูลของคุณ

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

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

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

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

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

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

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

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

: มีกระบวนทัศน์หนึ่งที่ถูกนำมาคัลในปี 1960 คือ การเขียนโปรแกรมโครงสร้าง : เพียงใช้ "ระดับสูง" สร้างเช่นwhile, for, repeat, if/ then/ else, switch/ caseงบแทนการใช้มากgotoคำสั่งที่ได้รับการยอมรับโดยปริยาย ยังคงมีการถกเถียงกันว่าgotoมีการใช้ที่ถูกต้องหรือไม่

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

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

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

จากการเขียนโดย anti-goto ringleader Edsger Dijkstra:

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

—Dijkstra ใน: Dahl, Dijkstra & Hoare 1972, pg. 6. (ดูหน้า 6 ที่นี่ )