ตรงไปตรงมาคุณชอบรหัสคาวบอยหรือไม่ [ปิด]

โปรแกรมเมอร์ส่วนใหญ่ปกป้องวิธีการทางการเมืองที่ถูกต้องเช่น Agile, Waterfall, RUP และอื่น ๆ บางคนทำตามวิธีการ แต่ไม่ทั้งหมด ตรงไปตรงมาถ้าคุณสามารถเลือกวิธีการที่แน่นอนคุณจะไปที่วิธีการ "ถูกต้อง" ที่สำคัญหรือคุณต้องการวิธีการ "ง่ายขึ้น" เช่นการเขียนโปรแกรมคาวบอย? ทำไม?

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

ดูเกี่ยวกับการเข้ารหัสคาวบอยใน Wikipedia

ฉันคิดว่าโปรแกรมเมอร์ที่มีประสบการณ์เกือบทุกคนผ่านสามขั้นตอนและบางรายการผ่านสี่ขั้นตอน:

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

2. สถาปัตยกรรมนักบินอวกาศได้เห็นความล้มเหลวของโครงการ ball-of-yarn ครั้งแรกเพื่อปรับตัวให้เข้ากับสถานการณ์ที่เปลี่ยนแปลง ทุกอย่างต้องถูกเขียนใหม่และเพื่อป้องกันไม่ให้มีการเขียนซ้ำอีกครั้งในอนาคตพวกเขาสร้างแพลตฟอร์มภายในและจบลงด้วยการสนับสนุน 4 ชั่วโมงต่อวันเพราะไม่มีใครเข้าใจวิธีการใช้งานอย่างถูกต้อง

3. วิศวกรเสมือนมักจะเข้าใจผิดว่าเป็นวิศวกรที่ผ่านการฝึกอบรมจริงเพราะพวกเขามีความสามารถอย่างแท้จริงและเข้าใจหลักการทางวิศวกรรมบางอย่าง พวกเขาตระหนักถึงแนวคิดพื้นฐานทางวิศวกรรมและธุรกิจ: ความเสี่ยง, ROI, UX, ประสิทธิภาพ, การบำรุงรักษาและอื่น ๆ คนเหล่านี้เห็นว่าการออกแบบและเอกสารเป็นสิ่งที่ต่อเนื่องและมักจะสามารถปรับระดับของสถาปัตยกรรม / การออกแบบให้เข้ากับความต้องการของโครงการ

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

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

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

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

หากคุณเป็นคนทำคาวบอยคุณก็ไม่รู้วิธีอื่น

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

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

และถ้าคุณเป็นโปรแกรมเมอร์เทปพันท่อก็ไม่มีเหตุผลอะไรที่จะ "โคบาลรหัส" เพราะคุณสามารถสร้างผลิตภัณฑ์ที่มีคุณภาพได้อย่างรวดเร็ว

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

ใช่.

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

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

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

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

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

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

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

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

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

ฉันจะโยนบางสิ่งบางอย่างออกจากที่นี่ในนี้ที่อาจจะไม่เป็นที่นิยมจริงๆ: ลูกค้าทั่วไปต้องการสิ่งที่จัดการในแฟชั่นคาวบอย

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

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

"คาวบอย" ที่ประสบความสำเร็จที่ฉันได้ทำงานด้วยสามารถ:

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

คนแบบนี้ให้ผลลัพธ์ที่ยอดเยี่ยมอย่างแท้จริงด้วยการจัดการและโครงสร้างค่าใช้จ่ายเพียงเล็กน้อย แต่ก็หายาก

แก้ไข: สำหรับการอ้างอิงในอนาคตคำตอบของฉันสำหรับคำถามอื่นซึ่งได้รับการรวมเข้ากับคำถามนี้ มันค่อนข้างนอกที่นี่ แต่นั่นไม่ใช่การโทรของฉัน

เธอเป็นคนขี้เกียจหยิ่งเขลาและเห็นแก่ตัวมาก พฤติกรรมนี้ประมาท

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

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

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

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

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

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

• กลศาสตร์คลาสสิก? คาวบอยไอแซกนิวตันเพิ่มเติมจาก Leibniz, Lagrange, Hamilton
• เครื่องบิน? Cowboys Wright
• ทฤษฎีสัมพัทธภาพ? คาวบอยอัลเบิร์ตไอน์สไตน์
• วิทยาศาสตร์พื้นฐานของคอมพิวเตอร์? ทัลันทัวริง
• ทรานซิสเตอร์? Cowboys Walter Brattain และ John Bardeen

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

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

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

นอกจากนี้ฉันคิดว่าส่วนใหญ่ของการออกแบบได้รับการประมวลผลแล้วในเธรดพื้นหลังที่ไหนสักแห่งในหัวหน้านักพัฒนาอาวุโส

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

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

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

ฉันคิดว่าผู้แสดงความเห็นคนหนึ่งพูดถูก - ทั้งหมดเกี่ยวกับผลลัพธ์

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

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

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

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

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

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

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

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

ข้อเท็จจริงที่สำคัญเพียงอย่างเดียวคือผลลัพธ์ของผลิตภัณฑ์ในระยะยาวของทีม

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

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

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

ตัดสินใจเลือกและเพิ่มประสิทธิภาพบัญชีรายชื่อของทีม

ไม่ใช่โปรแกรมเมอร์ทุกคนที่ทำงาน (หรือควรทำงาน) ด้วยวิธีเดียวกันตราบใดที่ผลลัพธ์สุดท้ายดี

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

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

หรืออาจเป็นสัญญาณของมือสมัครเล่นอันดับ

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

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

ไม่มีข้อแก้ตัว - ใช้เวลา 10 นาทีในการตั้งค่าพื้นที่เก็บข้อมูลและ 10 วินาทีในการกระทำ คิดเป็น 1% ของเวลาการพัฒนาทั้งหมดของคุณ การทดสอบหากคุณกำลังรีบสามารถ whittled ลงได้อย่างง่ายดายถึง 20-30 นาทีต่อวันและยังคงมีประโยชน์พอสมควร

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

ใช่ แต่คุณต้องรับรู้เมื่อไม่ต้องทำ

ในทุกสิ่งเล็ก ๆ คุณอาจจะสบายดี แต่ถ้าคุณมีบางอย่างที่ซับซ้อนอันตราย จำกัด ฯลฯ คุณต้องจำได้เมื่อการออกแบบที่เหมาะสมคุ้มค่ากับเวลาพิเศษ

ฉันคิดว่าคุณควรคิดด้วยคำตอบของ Aaronaught คาวบอยหมายถึงสิ่งต่าง ๆ สำหรับคนต่าง ๆ

เมื่อฉันคิดว่าวิธีการแบบ "ดั้งเดิม" ฉันคิดว่า "การจัดการไม่ทราบวิธีที่จะเข้าใจนักพัฒนาดังนั้นแทนที่จะเข้าสู่โลกของนักพัฒนาและเข้าใจพอที่จะรู้ว่าเกิดอะไรขึ้นพวกเขาทำให้นักพัฒนาเข้ามาในโลกของพวกเขา"

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

กล่าวอีกอย่างคือมีสิ่งที่คุณต้องทำในโครงการขนาดใหญ่มากและมีหลายสิ่งที่คุณต้องทำในโครงการขนาดเล็กและมีสิ่งที่คุณต้องทำทั้งสองอย่าง

ตัวอย่างเช่นฉันจะไม่มี backlogs ที่ง่ายที่สุดสำหรับโครงการที่ฉันทำงานด้วยตัวเอง ... มันเป็นเพียงรายการที่ต้องทำ หากมีเราสองคนฉันอาจจะแบ่งปันรายการนั้น แต่ในรูปแบบที่ง่ายมาก (อาจเป็นเพียงบันทึกย่อที่เก็บไว้ในที่เก็บรหัสของเรา) เมื่อฉันมี 3 หรือ 4 ฉันกำลังมองหาระบบรายการงานบางอย่าง

เมื่อสร้างต้นแบบของคุณสมบัติที่ง่ายมาก

จากนั้นเมื่อทำเสร็จและพิจารณาวิธีการที่ถูกต้องแล้วฉันจะวางโค้ดและจริงจัง

ฉันเคยทำมันในโครงการจริง (ในเวลาที่เราเรียกมันว่า Samurai Programming หลังจาก Samurai Tailor ซีรีย์สเก็ตช์ของ Saturday Night Live) และทำให้ฉันประหลาดใจมากมันทำงานได้ดี แน่นอนว่าสิ่งที่ฉันเริ่มต้นคือขยะดังนั้นมีความเสี่ยงเพียงเล็กน้อยที่ทำให้แย่ลง

อย่างไรก็ตามฉันเป็นคนที่ "เรียบร้อย" ในใจและไม่ชอบรูปแบบการพัฒนาจากสะโพก

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

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

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

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

ในกรณีเช่นนี้สิ่งที่มักจะคุ้มค่าคือการสร้างห้องสมุดเพื่อให้งานง่าย ๆ เช่นนี้ เมื่อใช้โค้ด front-end บ่อยครั้งที่การเขียน (หรือแก้ไข) เพื่อทำสิ่งที่คุณต้องการกลายเป็นเรื่องง่ายกว่าการจัดเรียงโปรแกรมที่สมบูรณ์เพื่อทำสิ่งที่คุณต้องการ พิจารณาสำหรับ exmaple, gnu เยื้องกับธงที่แตกต่างกัน 50+ ซึ่งหลายคนมีปฏิสัมพันธ์ในรูปแบบที่หลากหลายดังนั้นเกี่ยวกับตัวเลือกที่สมเหตุสมผลเท่านั้นคือ 1) อย่าใช้เลยหรือ 2) ตัดสินใจว่าจะให้อะไรกับคุณ แทนที่จะพยายามหาสิ่งที่คุณต้องการในตอนแรก

ดูเหมือนจะมีสองค่าย - ผู้ที่ชื่นชอบผลลัพธ์และผู้ที่ชื่นชอบหลักการ ฉันตกหลุมหลัง

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

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

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

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

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

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

ไม่ไม่เคย.

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

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

ฉันไม่คิดว่าการเข้ารหัสคาวบอยเป็นวิธีการอาวุโส

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

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

การเขียนโปรแกรมคาวบอยเป็นวิธีที่ค่อนข้างแน่ใจว่าในการสร้างลูกใหญ่ของโคลน ซึ่งฟังดูไม่น่าพอใจเท่าที่ควร ...

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

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

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

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

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

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