วิธีการเขียนโค้ดที่เร็วขึ้น (โดยไม่ต้องเสียสละคุณภาพ) [ปิด]

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

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

สิ่งที่ฉันทำอยู่แล้ว:

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

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

นอกจากนี้ฉันได้รับเงินคืนจากผู้จัดการของฉันอย่างสม่ำเสมอไม่ว่าจะเป็นการพัฒนา Flash ขนาดเล็กหรือการพัฒนา Java / C ++ ขององค์กร

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

ฉันทำงานในทีมขนาดเล็กและขนาดกลาง (5-50 คน) ใน บริษัท ต่าง ๆ ในโครงการต่าง ๆ และเทคโนโลยีต่าง ๆ (แฟลช, ASP.NET, Java, C ++) ข้อสังเกตของผู้จัดการของฉัน (ซึ่งพวกเขาบอกฉันโดยตรง) คือฉัน "ช้า"

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

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

ทำไม? ฉันพลาดอะไรไป ฉันจะทำให้ดีขึ้นได้อย่างไร

เป้าหมายสุดท้ายของฉันคือง่าย: ถ้าฉันสามารถสร้างผลิตภัณฑ์ X ใน 40 ชั่วโมงวันนี้และฉันสามารถปรับปรุงตัวเองอย่างใดเพื่อให้ฉันสามารถสร้างผลิตภัณฑ์เดียวกันที่ 20, 30 หรือ 38 ชั่วโมงในวันพรุ่งนี้นั่นคือสิ่งที่ฉันอยากรู้ - ฉันจะไปที่นั่นได้อย่างไร? ฉันสามารถใช้กระบวนการใดในการปรับปรุงอย่างต่อเนื่อง ฉันคิดว่ามันเกี่ยวกับการใช้รหัสซ้ำ แต่ดูเหมือนไม่เพียงพอ

ผมชอบวิธีการที่เจฟฟ์แอดนี้ซึ่งสามารถพบได้ที่นี่http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html

โดยทั่วไปในบทความที่เขาอ้างอิงทางจากหนังสือศิลปะ & ความกลัวโดย David Bayles และ Ted Orland ตอนที่ไป:

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

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

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

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

สิ่งที่คนส่วนใหญ่คิดว่าสำคัญไม่สำคัญ ความเร็วในการพิมพ์ไม่สำคัญ เครื่องจักรหรือเครื่องมือที่เร็วกว่านั้นไม่สำคัญ เราไม่ได้เป็นพนักงานพิมพ์ดีดหรือผู้ปฏิบัติงานเครื่อง พวกเราเป็นคนคิด เราเป็นผู้มีอำนาจตัดสินใจ

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

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

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

* http://codekata.pragprog.com/

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

ในสภาพแวดล้อมการพัฒนาบางอย่าง¹มันไม่คุ้มค่ากับเวลาพิเศษในการสร้างบางสิ่งที่สวยงามเมื่อ "เพียงแค่ดีพอ" จะทำ

^{1 - ฉันกำลังคิดถึง "เครื่องมือภายในด้วย" โดยเฉพาะ แต่อาจมีบางอย่าง}

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

ดังนั้นฉันมีคำแนะนำสำหรับคุณ:

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

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

3. ทำการเขียนโปรแกรมจับคู่กับนักพัฒนา "คุณภาพสูง" เพื่อดูว่าคุณสามารถเห็นความแตกต่างได้หรือไม่

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

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

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

สรุป:

• ประสบการณ์สร้างลักษณะที่เพิ่มความมั่นใจและซอฟต์แวร์ที่ดีขึ้น

PS: ประสบการณ์ยังมาจากการเรียนรู้จากผู้อื่น เช่นความช่วยเหลือจาก SO, การเขียนโปรแกรมจับคู่, รีวิวจากเพื่อน ฯลฯ คุณไม่สามารถมีประสบการณ์ได้หากคุณไม่สามารถมองย้อนกลับไปและเรียนรู้จากความผิดพลาด (หรือบางคนไม่เคยท้าทายความพยายามของคุณ)

คำถามคือถ้าคุณไม่แพงเมื่อดูต้นทุนรวมระยะยาว

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

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

ถ้าไม่เช่นนั้นคุณต้องพิจารณาอย่างรอบคอบว่าเหตุใดจึงเป็นเช่นนี้:

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

คิดทบทวนและแก้ไขคำถามของคุณด้วยสิ่งที่คุณค้นพบ

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

1) ไม่หยุดเรียนรู้: เรียนรู้ทุกสิ่งที่คุณสามารถเกี่ยวกับการเขียนโปรแกรมและการใช้คอมพิวเตอร์โดยทั่วไป ค้นหาพื้นที่ที่คุณอ่อนแอและเรียนรู้ แม้ว่ามันจะไม่เกี่ยวข้องกับงานของคุณและ C # อย่างสมบูรณ์ แต่ฉันรับประกันได้ว่าหากคุณกำลังมองหามันคุณมักจะพบวิธีที่จะนำไปใช้กับสิ่งที่คุณทำ การเรียนรู้เป็นเรื่องเกี่ยวกับประสบการณ์ด้วยดังนั้นอย่าเพิ่งอ่านเนื้อหา แต่ลองทำและขยายทักษะของคุณ หากคุณคุ้นเคยกับการใช้ Windows ให้ลองใช้ Unix หรือในทางกลับกัน หากปกติคุณต้องการใช้เครื่องมือบรรทัดคำสั่งลองของ IDE และตัวแก้ไขข้อความหรือในทางกลับกัน หากคุณได้ยินเกี่ยวกับเครื่องมือหรือเทคโนโลยีที่คุณไม่เคยได้ยินมาก่อนหรือไม่รู้จักมากนักอย่ายอมแพ้กับสิ่งล่อใจที่จะเดินหน้าต่อไป ค้นดูสิ! อย่ากลัวที่จะคิดนอกกรอบและเรียนรู้เทคโนโลยีใหม่ ๆ ที่คนอื่นพูดว่าไม่จริง

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

3) ใช้เทคนิค Pomodoro และปรับ / เปลี่ยนแปลงสิ่งที่ไม่เหมาะกับคุณ หากคุณรวมสิ่งนี้เข้ากับหมายเลข 2 ในรายการนี้คุณจะได้รับผลผลิตเพิ่มขึ้นอย่างมาก

4) เรียนรู้เป็นกลุ่ม แม้ว่าคุณจะใช้คำสั่งเหล่านี้ภายใน Visual Studio ผ่าน ViEmu หรือจากภายใน Eclipse ผ่านทางปลั๊กอินหรือจากภายใน Emacs คุณจะได้รับผลผลิตเพิ่มขึ้น วิธีที่ดีที่สุดในการเรียนรู้ Vim คือการเริ่มใช้มันและบังคับตัวเองให้อย่า (ปิดการใช้งาน / กลับไปที่เครื่องมือเก่าของคุณ) จนกว่าคุณจะเชี่ยวชาญ มันเป็นความเจ็บปวดในตอนแรก แต่คุณจะไม่ต้องการกลับมาและแม้กระทั่งเมื่อคุณต้องทำงานโดยปราศจากมัน บางคนบอกว่าสิ่งนี้จะไม่เพิ่มความเร็วของคุณมากนัก แต่เร็วขึ้นเร็วขึ้นโดยเฉพาะเมื่ออ่านและแก้ไขโค้ดคือสิ่งที่เราทำและฉันพบว่าตัวเองประหยัดเวลาได้มากในบางครั้ง

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

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

ใช้สมองของคุณมากขึ้นและทำการทดสอบน้อยลง ความซื่อสัตย์การทดสอบมีที่ของมัน แต่มีราคาแพง

นอกจากนี้อ่าน The Art of Unix Programming (ออนไลน์ฟรีจองคุ้มค่ากับราคา)

ในที่สุดคุณอาจไม่ถูกที่ ตรึงรอบในงานสแควร์ ฯลฯ

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

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

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

คุณอาจเคยได้ยินคำพูดเดิม - หากคุณพบข้อผิดพลาดในขณะที่คุณพิมพ์มันจะช่วยให้คุณประหยัดเวลาได้มากกว่า 10 เท่าถ้าคุณจับมันได้ที่ build time ซึ่งดีกว่าการจับมันในช่วง QA 10 เท่าซึ่งดีกว่า 10x มากกว่าการจับมันหลังจากปล่อย ..

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

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

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

การเข้ารหัสแบบป้องกัน (ตัวอย่างเช่นการตรวจสอบพารามิเตอร์) สามารถลดปัญหา ... ถ้าคุณมีนักวิเคราะห์ / สถาปนิกที่ดีมากในทีมของคุณคุณสามารถประหยัดเวลาด้วยการออกแบบเริ่มต้นที่ดี

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

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

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

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

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

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

หากไม่มีสิ่งใดที่จะช่วยให้คุณได้มาตรฐานคุณสามารถทำงานกับมันได้

จากรายการของคุณคุณทำได้ดี

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

อย่าเขียนโค้ดที่มี CRAP มากกว่าที่คุณต้องการ ;)

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

1. บริษัท ของคุณขายห้องสมุด
2. คุณมีรหัสซ้ำที่ refactored ลงในไลบรารี

คุณกำลังอ่านและทำอยู่และมันก็เยี่ยมมาก แต่คุณอาจกำลังคิดเกี่ยวกับ procuedural หรือรหัส OO คุณเคยสัมผัสกับการเขียนโปรแกรมฟังก์ชั่น (พูด Haskell?) และ Prolog หรือไม่?

เพื่อฝึกฝนเทคนิคการเขียนโปรแกรม OO ของคุณคุณเล่นกับ Smalltalk / Squeak หรือไม่?

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

ฉันจะพูดกับลุงบ๊อบ :

วิธีเดียวที่จะไปอย่างรวดเร็วคือไปได้ด้วยดี

ทุกครั้งที่คุณไปยังสิ่งล่อใจเพื่อแลกเปลี่ยนคุณภาพเพื่อความเร็วคุณจะชะลอตัวลง ทุกเวลา.

- "Vehement Mediocrity", Robert C. Martin

เท่าที่ฉันรู้:

1. ดี
2. รวดเร็ว
3. ถูก

ในฐานะผู้จัดการคุณสามารถเลือก 2

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

สิ่งสำคัญที่ฉันคิดได้มีดังนี้

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

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

คุณสามารถเรียนหลักสูตรการพิมพ์เร็วได้ ฉันไม่รู้ว่าการพิมพ์เร็วขึ้นเป็นปัญหา แต่ "การเข้ารหัสช้าเกินไป" อาจเกิดจากความเร็วในการพิมพ์ช้า

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

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

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

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

ฉันคัดค้านมุมมอง "คุณภาพที่เสียสละเพื่อความเร็ว" ของ OP

นักเขียนโค้ดมืออาชีพ (โปรแกรมเมอร์) ต้องการวัตถุ 3 ตัว:
1) รหัสควรทำงานตามที่ตั้งใจไว้
2) การส่งมอบควรตรงเวลา
3) มีคุณภาพเอกสารที่ดี ฯลฯ
4) อื่น ๆ เป็นต้น

ฉันคิดว่า OP ถูกตำหนิอย่างช้าๆอาจเป็นเพราะ OP ไม่ได้ทันเวลา

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

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

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

ประโยชน์ของ Squeak สำหรับการเข้ารหัสที่รวดเร็วนั้นยิ่งไปกว่า "การฝึกฝนทักษะ OOP" มีเหตุผลที่ GUIs ที่ทันสมัยรวมถึง IDEs ถูกประดิษฐ์ขึ้นบน Smalltalk ไม่ต้องพูดถึง JUNIT เป็นพอร์ตของ SUNIT ไปยัง Java คำว่า "OOP" ถูกคิดค้นเพื่ออธิบาย Smalltalk ฯลฯ เป็นต้น

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