ถ้า coder ที่คล่องแคล่วไม่สนใจแนวปฏิบัติที่ดีความคล่องแคล่วของเขาจะไม่ทำงานกับเขาใช่ไหม [ปิด]


16

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

ส่วนสำคัญของแอพนี้เขียนขึ้นโดยนักศึกษาฝึกงาน, n00bs เป็นต้น แต่ก็มีโปรแกรมเมอร์ในตำแหน่งของ Master Developer และด้วยความนอบน้อมทั้งหมดรหัสที่เขาทิ้งไว้ข้างหลังนั้นก็เป็นที่น่าสงสัยเช่นกันในทางที่ต่างออกไป

ได้รับรหัสของเขามีแนวโน้มที่จะได้งานทำ - ส่วนใหญ่ - แต่โดยทั่วไปแล้วจะเป็นความลับ, ปรับเปลี่ยนวงล้อ (เช่นวิธีการที่กำหนดเองขนาดใหญ่ที่ประสบความสำเร็จในการสำรองข้อมูล SQL db ธรรมดา) เป็นต้นโดยทั่วไปแล้ว

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

สมมติว่าเป็นเรื่องจริงบางเหตุผลที่ฉันคิดได้คือ:

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

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

คุณคิดอย่างไรกับเรื่องนี้? มันเป็นความจริงหรือเปล่าถ้าเป็นเช่นนั้น?


24
"ให้เวลาฉันหกชั่วโมงเพื่อตัดต้นไม้ฉันจะใช้ขวานสี่คมแรก" --Abraham Lincoln "ลับขวานของคุณในเวลาของคุณเอง" - บอสใหญ่
JeffO

15
ความสับสนบางอย่างที่นี่สำหรับฉันเกิดจากชื่อเช่นเมื่อฉันอ่าน 'คล่องแคล่ว'I.ThinkOf(this).KindOfThing()
Benjol

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

@Ramhound - ไม่เพราะเขาออกจาก บริษัท ก่อนที่ฉันจะเข้าร่วม เขาเป็นคนสุดท้ายที่จะทำงานกับมันก่อนที่ฉันจะหยิบมันขึ้นมา ฉันรู้จากเพื่อนร่วมงานว่าเขาเคยเป็นคนรีบเร่งเนื่องจากการแก้ไขแอพมีความสำคัญเนื่องจากลูกค้าร้องเรียนจำนวนมาก แต่เขาไม่ได้ทำงานที่ดีมากในแง่ของการจัดการเวลาเพราะเขาเห็นได้ชัดว่ากระแทกผ่านประตูที่เปิดอยู่ทุกขณะแล้ว BTW เขาสร้างไลบรารี่ของตัวเองเพื่อแปลแอพพลิเคชั่น WPF และ Winforms
Konrad Morawski

1
ที่เกี่ยวข้องอย่างมากกับ เรื่องนี้และนี้ บางคน(มาก)ติดอยู่ในขั้นตอนนี้ ...
BlueRaja - Danny Pflughoeft

คำตอบ:


22

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

ใช่. ฉันเป็นผู้ชายคนนั้น และฉันได้เรียนรู้ว่ามันเป็นสิ่งที่แย่มาก

ทุกอย่างดีมากสำหรับคุณคุณไม่ต้องเรียนรู้อะไรใหม่

แต่แล้วทีมอื่นของคุณล่ะ? พวกเขาพึ่งพาคุณมาก พวกเขาไม่สามารถ google สำหรับ "Quicky ORM ของ Clive" เพื่อรับความช่วยเหลือเกี่ยวกับผู้ทำแผนที่เชิงวัตถุที่คุณเขียน

แล้วถึงวันที่พวกเขาต้องการจ้างคนใหม่และพวกเขาไม่สามารถหาคนที่มีประสบการณ์ใน Quicky ORM ของ Clive ได้

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

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


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

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

2
@Toby: จุดยุติธรรม แต่โดยทั่วไปแล้ว บริษัท เหล่านั้นมักจะอยู่นอกเหนือการออม
pdr

ไม่พูดถึงกองทัพอากาศสหรัฐเหมือนกับ บริษัท ที่ @Toby พูดถึง เราพยายามผลัก Ruby on Rails ให้ผ่าน แต่พวกเขาไม่ชอบ
Travis Pessetto

@Toby มีบางกรณีที่การปรับแต่งล้อเป็นสิ่งที่ถูกต้องที่ต้องทำกุญแจสำคัญคือการทำให้แน่ใจว่าคุณเข้าใจว่าทำไมคุณถึงเป็น
jk

14

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

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

•หากมีประสบการณ์เพียงพอที่จะรักษาภาพลักษณ์ของโปรแกรมที่ซับซ้อนได้ง่ายคน ๆ นั้นมีแนวโน้มน้อยที่จะแยกออกเป็นโมดูลเลเยอร์ ฯลฯ

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


1
ใช่แน่นอน. และฉันคิดว่าฉันจะถูกต่อต้านมากกว่าชาวบ้านแบบนี้ถ้าฉันไม่ได้มีชีวิตที่ดีในช่วงหลายปีที่ผ่านมาเพื่อทำความสะอาดหลังจากพวกเขา ... ;-)
Mike Woodhouse

4

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

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

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


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

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

3

100%

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

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

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


1

ปัญหาที่คุณอธิบายเป็นพื้น NIH ("ไม่ได้คิดค้นที่นี่") - มีอาการอื่น ๆ ?

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


1

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

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


0

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

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

โดยทั่วไปคุณต้องป้องกันตัวเองจากการแฮ็กใด ๆที่อาจกลายเป็น "วิธีแก้ปัญหาที่ใช้การได้" พร้อมที่จะขายโดยพนักงานขายที่กระตือรือร้น มันเก่า "มันยังไม่พร้อม! - แต่มันใช้ได้ใช่มั้ย" ปริศนา.


คำถามนี้ถามคำถามนี้อย่างไร
ริ้น

@gnat คำถามที่ว่า "คุณคิดอย่างไรกับสิ่งนั้น" คำตอบของฉันคือสิ่งที่ฉันคิด ฉันยังคงมีความคิดเห็นแบบเดียวกัน: ความคล่องแคล่ว (ดังนั้นความสามารถในการแก้ปัญหาอย่างรวดเร็วแฮ็ก ฯลฯ ) สามารถนำไปสู่รหัสที่เป็นอันตรายในระยะยาว คุณไม่สามารถพูดภาษาได้อย่างคล่องแคล่วคุณต้องรู้วิธีจัดระเบียบโค้ด
MPelletier
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.