จะเป็นโปรแกรมเมอร์ที่“ เร็วขึ้น” ได้อย่างไร?

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

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

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

ข้อเสนอแนะใด ๆ ที่ชื่นชมอย่างมากขอบคุณ

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

แนวคิดบางอย่าง ...

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

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

คุณ (และทีมของคุณ) กำลังทำข้อผิดพลาดอย่างใดอย่างหนึ่งต่อไปนี้ (หรือทั้งหมด):

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

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

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

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

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

หลายคนหลายคนมุ่งมั่นเพื่อคุณภาพ "สุดยอด" โดยเสียค่าใช้จ่ายของบางสิ่งที่ (a) ง่าย, (b) เชื่อถือได้และ (c) ถูกต้อง

วิธีที่สำคัญที่สุดในการเร่งการพัฒนาของคุณคือการทำให้สิ่งที่คุณทำนั้นง่ายขึ้นเพื่อให้ง่ายที่สุดเท่าที่จะทำได้

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

ฉันได้ยินผู้คนมากมายบอกฉันว่าลูกค้าคาดหวังอะไร นี่เป็นนโยบายที่ไม่ดี

สร้างสิ่งที่ง่ายที่สุด หากลูกค้าต้องการมากขึ้นสร้างมากขึ้น แต่สร้างสิ่งที่ง่ายที่สุดก่อน

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

แต่บ่อยครั้งที่การเพิ่มความเร็วหมายถึงการเสียสละคุณภาพ

การนำกลับมาใช้ใหม่ - ฉันพยายามแยกส่วนที่ฉลาดออกจากโครงการก่อนหน้านี้ดังนั้นฉันจึงสามารถใช้อีกครั้งในการลงทุนในอนาคต ควรถามตัวเองเสมอว่า "ฉันจะใช้อีกสักวันหนึ่งได้ไหม?"

ง่าย ๆ เข้าไว้.

หากคุณใช้ TDD คุณควรทำตาม " สีแดงสีเขียวตัวทำซ้ำ ":

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

คุณดาวน์โหลดเอกสารทุกภาษา / ห้องสมุดในประเทศไปยังเครื่องคอมพิวเตอร์ของคุณแล้วถอดสายเคเบิลเครือข่ายของคุณ / ปิดWi-Fi

ไม่พยายามที่จะตลกที่นี่ มันช่วยฉันได้จริงๆ!

โปรดสังเกตว่าเมื่อคุณอ่าน Stack Overflow มานานเกินไป ข้ออ้าง "รวบรวม" ใช้งานได้นาน :)

หลีกเลี่ยงการสลับงานบ่อยเกินไป การรบกวนและการสลับงานสามารถฆ่าวันแม้ว่าคุณจะใช้เครื่องมือเช่นMylynเพื่อจัดการงานของคุณ

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

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

ทำถูกวิธีที่ดีที่สุดเป็นครั้งแรก ถ้านั่นหมายความว่าคุณต้องหยุดและคิดสักครู่ก่อนที่จะเริ่มทำ ทำงาน 90% ของเวลา

เรียนรู้ที่จะสัมผัสพิมพ์เร็วที่สุดเท่าที่เป็นไปได้

ฉันทำมันในวันพรุ่งนี้

การทำสิ่งต่าง ๆ ให้สำเร็จนั้นมีประโยชน์อย่างมากเช่นกัน

ฉันมีความสนใจสั้น ๆ อยู่แล้วดังนั้นหนังสือเหล่านี้ช่วยฉันรักษาตำแหน่งของฉัน ... ฉันกำลังทำอะไรอยู่อีก?

ฝึกฝนและทำงานหนัก

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

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

เรียนรู้เกี่ยวกับ The Zone เรียนรู้วิธีการเข้าร่วมและเรียนรู้วิธีการจดจำเมื่อคุณไม่ได้อยู่ในโซน

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

อ้างจากwhat-tricks-do-you-use-to-get-yourself-in-the-the-zone

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

Emacs

ก่อนที่คุณจะเริ่มพัฒนา:

• ออกจากระบบกล่องจดหมายของคุณ
• ปิดการใด ๆIMลูกค้า
• ขอให้เพื่อนร่วมงานอย่างสุภาพเพื่อให้คุณมีสมาธิ
• แน่นอนหยุดการท่องอินเทอร์เน็ต

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

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

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

คุณช้ากว่าเพื่อนร่วมงานหรือประมาณการของคุณมากเกินไปหรือไม่

เพื่อผลิตซอฟต์แวร์ได้เร็วขึ้นฉันได้พบสิ่งที่ดีที่สุดที่ต้องทำคือเรียนรู้ runtime API ของคุณให้ดีที่สุด อย่าพิมพ์ตรรกะรายการเมื่อส่วนขยาย LINQ จะทำ; อย่าสร้างกลุ่มผู้ฟังเหตุการณ์เมื่อการรวมจะทำงาน ฯลฯ

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

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

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

สองสิ่งที่อาจบอกเป็นนัย แต่ฉันไม่เห็นคำตอบที่นี่ที่เพิ่มประสิทธิภาพการผลิตคือ:

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

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

ความคิดสองประการอยู่ในใจ:

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

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

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

1. รู้ว่าเทคโนโลยีทั้งภายในและภายนอก
2. หยุด! คิด! ไป!
3. สถาปนิกสำหรับสิ่งที่อาจเกิดขึ้น แต่ใช้เฉพาะสิ่งที่ขอจริงๆ
4. KISS - ทำให้มันงี่เง่า
5. ถ้ามันซับซ้อนเกินไปอาจเป็นไปไม่ได้ที่จะคิด (กลับไปที่ 2 และ 4)
6. อย่าติดอยู่ใน 5 มักจ่ายให้เริ่มต้นจากศูนย์ (กลับไปที่ 2 และ 4)
7. กลับไปที่ 1

ฉันคิดว่าพวกเขาคำสำคัญที่นี่คือ "ทันเวลา" พวกเขาไม่ได้บอกว่าคุณช้าเกินไป แต่ไม่ใช่ว่าคุณจะทันเวลา

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

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

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

รับที่มั่นคงอยู่ที่มั่นคง

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

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

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

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

หากคุณมี 10,000 บรรทัดของรหัสที่ไม่เคยทำงานและคุณต้องค้นหาตัวแบ่งคุณมีจำนวนของรหัสเพื่อค้นหา

การเปลี่ยนแปลงเล็ก ๆ น้อย ๆ ที่เพิ่มขึ้นในระบบที่มีเสถียรภาพ FTW อย่างสม่ำเสมอ ไปช้าเพื่อไปอย่างรวดเร็ว

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

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

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

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

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

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

ในที่สุดฉันคิดว่าการประเมินประสิทธิภาพส่วนใหญ่ (ถ้าไม่ทั้งหมด) นั้นบิดเบี้ยวและบิดเบือนอย่างผิดปกติ คุณไม่สามารถควบคุมความเร็วและความเร็วได้ถึง 100% หัวหน้าของคุณควรจะให้คะแนนคุณกับมาตรฐานที่กำหนดโดยองค์กร มาตรฐานขององค์กรในการแลกเปลี่ยนระหว่างคุณภาพและความเร็ว ให้จินตนาการว่า OrangeSoft Inc. คาดหวังคุณภาพ 33% และความเร็ว 66% ดังนั้นหากคุณกำลังเขียนโค้ดที่อาจมีหนึ่งในสามของการทดสอบหน่วย แต่ควรทำด้วยความเร็วและลดเวลาการส่งมอบคุณควรได้คะแนนใกล้ 100% จากการรีวิวของคุณ! (สิ่งเหล่านี้เป็นคำเปรียบเทียบที่ค่อนข้างหยาบ แต่คุณเข้าใจถูก) แต่สิ่งที่เกิดขึ้นก็คือบ๊อบเขียนโค้ดเร็วมาก แต่ก็เป็นรถที่มีชื่อเสียง ดังนั้นในการตรวจสอบประสิทธิภาพของเขาเขาจะได้คะแนน 3/5 สำหรับคุณภาพและ 5/5 สำหรับความเร็ว ในทางตรงกันข้ามแครอลเขียนโค้ดช้ากว่ามาก แต่ก็สร้างบั๊กได้น้อยกว่ามาก เธอทำคะแนนได้ 5/5 สำหรับคุณภาพ แต่ 3/5 สำหรับความเร็ว ไม่ว่าจะด้วยวิธีใดบ๊อบกับแครอลก็ขึ้นแท่น เป็นไปได้หรือไม่ที่พนักงานคนใดจะได้คะแนนเต็ม? ยุติธรรมหรือไม่

เทคนิคที่ฉันใช้คือการสร้างต้นแบบเชิงวิวัฒนาการ

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