นักพัฒนาซอฟต์แวร์ที่เพิกเฉยต่อคุณภาพ / มาตรฐานที่ดีกว่าสำหรับ บริษัท หรือไม่ [ปิด]

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

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

สไตล์เหล่านี้เปรียบเทียบในการแสดงความคิดเห็นกับเพื่อนอย่างไร

อะไรคือวิธีที่ดีที่สุดในการโน้มน้าวให้ทีมของคุณใช้แนวปฏิบัติที่ดีที่สุดระหว่าง SDLC

ไม่พวกเขาจะได้รับความเคารพจากเจ้าของโครงการในขณะนั้น

พวกเขาจะถูกทิ้งในถังขยะเป็นเวลาหลายปีโดย:

• ผู้ดูแลในอนาคต
• ผู้ทดสอบในอนาคต
• เจ้าของโครงการในอนาคต
• ผู้จัดการในอนาคต
• และใครก็ตามที่เกี่ยวข้องกับ codebase ในอนาคต

พวกเขาอาจได้รับการรักษาแบบเดียวกันจาก:

• ผู้ทดสอบปัจจุบัน
• นักเขียนเอกสารทางเทคนิคในปัจจุบัน

ขั้วต่อเท็จ: คุณสมบัติเป็นมุมฉาก

                คุณภาพสูงคุณภาพต่ำ

Sketchy ยอดเยี่ยมที่ทำกำไรได้

ไม่ทำกำไร Iffy FIRE FIRST

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

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

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

ฉันเห็นด้วยกับนักพัฒนาที่ไม่สนใจการเพิ่มประสิทธิภาพรหัสและแนวทางปฏิบัติหรือไม่ เลขที่

พวกเขาทำงานที่พวกเขาต้องทำหรือไม่? ใช่.

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

แม้ว่าฉันจะไม่เห็นด้วยกับการพัฒนารูปแบบนี้ แต่ก็อาจถูกมองว่าเป็นที่น่านับถือโดย บริษัท ถ้ามีการวางจำหน่ายผลิตภัณฑ์

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

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

คุณจะถูกเกลียดชังโดยผู้ดูแล แต่รักเจ้านายของคุณ

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

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

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

ทุกอย่างอื่นในระหว่าง: ต่อรองได้โดยเฉพาะอย่างยิ่งตราบใดที่ dev อยู่ในเบ็ดสำหรับการสนับสนุนเริ่มต้น

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

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

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

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

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

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

ทุกอย่างขึ้นอยู่กับลูกค้า

ลูกค้าที่ชอบรวดเร็วและสกปรก (และมักจะถูกกว่า) ไม่สนใจว่าจะนำเสนอปัญหาในอนาคต

คิดว่าการก่อสร้างตู้

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

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

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

เวลาเท่านั้นที่จะบอก. ทำสิ่งที่ผู้จัดการต้องการหรือหางานอื่น

ไม่ไม่เคย. การเพิ่มประสิทธิภาพรหัส IMO, แนวทางปฏิบัติที่ดีที่สุด, งานฝีมือที่เกิดขึ้นจริงเป็นสิ่งสำคัญที่สุดที่จะมีใน codebase; ไม่ว่ามันจะกลายเป็นกากตะกอนและถูกยึดด้วยเทปพันท่อ มันเป็นการออกแบบที่ไม่ยั่งยืน มันก็เหมือนกับการไม่สนใจเนื้องอกเพราะมันเล็กและตอนนี้คุณแข็งแรงแล้ว แน่ใจว่าคุณมีสุขภาพดีในขณะนี้ แต่ไม่กี่ปีตามถนนมันกลายเป็นสถานีเพราะคุณไม่สนใจมันมานาน

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

อ่านดี: http://www.joelonsoftware.com/items/2009/09/23.html

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

ไม่ว่าคุณจะคิดอะไรอย่ากระตุกเรื่องนี้

แก้ไข: ฉันไม่ได้ปกป้องตำแหน่งใด ๆ ขึ้นอยู่กับงานที่ฉันอาจเอนไปข้างใดข้างหนึ่ง

ดีกว่าสำหรับ บริษัท มันขึ้นอยู่กับ.

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

สำหรับผลิตภัณฑ์ที่พัฒนาแล้วที่มีผู้ใช้จำนวนมากที่ต้องพึ่งพาคุณภาพของซอฟต์แวร์ทุกอย่างควรทำอย่างถูกต้อง

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

ขึ้นอยู่กับนักพัฒนาและโครงการ / สถานการณ์

เวลาพิเศษต้องใช้มาตรการพิเศษ

ดังนั้นหากฉันต้องการสิ่งที่ส่งมอบตอนนี้และมีใครบางคนที่เป็นแอปพลิเคชันระดับองค์กร Java ที่ใช้งานวิศวกรรมเกินกว่า 14 เฟรมเวิร์ก buzzword ล่าสุดในขณะที่สคริปต์ python แบบธรรมดาจะทำงานได้แย่กว่าที่นักพัฒนาที่ตัดมุมและคิด รหัสรถจะทำในเวลาปกติ

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

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

เป็นกรณี ๆ ไป ยกเว้นรูปแบบการเข้ารหัส - ไม่มีข้อแก้ตัว

ฉันขอโทษ แต่ฉันจะต้องไม่เห็นด้วยกับคำตอบส่วนใหญ่ของคำถามนี้ยกเว้นคำถามแรก

คุณค่าหลักของซอฟต์แวร์คือมีความยืดหยุ่น

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

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

ข้อสันนิษฐานที่แย่ที่สุดที่ฉันเห็นในคำตอบบางข้อคือรหัสสะอาดบางอันลดความเร็วของการพัฒนา สำหรับโครงการใด ๆ ของสารใด ๆ (มากกว่า 6 ชั่วโมงการทำงาน) การพัฒนาความเร็วรหัสสะอาดในระยะยาว (อะไรมากกว่าสัปดาห์) ฉันได้เห็นมันครั้งแล้วครั้งเล่า

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

ดังนั้นไม่ถึงคุณภาพต่ำในแง่ของความยืดหยุ่นเคย!