อารมณ์ที่แนบมากับรหัส [ปิด]


26

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

แก้ไข: ฉันไม่ได้พูดเกี่ยวกับการเขียนรหัสที่ไม่ดีและจากนั้นทำงาน ...


ขอขึ้นอยู่กับวัฒนธรรมการทำงาน

คำตอบ:


33

หลังจาก 30 ปีในฐานะผู้รับเหมา

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

  2. มันชัดเจนมาก มันแพงกว่ารหัสในบ้านดังนั้นมันจึงได้รับการตรวจสอบอย่างมาก เนื่องจากฉันจะไม่อยู่รอบ ๆ เพื่อรักษามันจะได้รับการตรวจสอบอย่างมาก คำแนะนำและการส่งมอบรหัสเป็นสิ่งสำคัญมาก มีความภาคภูมิใจในฝีมือบางอย่าง แต่ไม่มีความรู้สึกเป็นเจ้าของ

บันทึกของฉันคือ 17 ปีของการผลิต 12 ปีนั้นโดยไม่มีค่าบำรุงรักษาใด ๆ

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

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

อีกครั้งฉันรู้ว่ามันไม่มีที่ติเพราะไฟล์ที่ไม่ได้สัมผัสตั้งแต่รุ่นล่าสุดที่ฉันได้ทำ

ดังนั้นใช่มีความภาคภูมิใจอย่างมากในงานฝีมือ

แต่ไม่มี "ความเป็นเจ้าของ" มันเป็นรหัสของพวกเขาไม่ใช่ของฉัน ฉันสร้างมันขึ้นมาเท่านั้น


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

10

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


9

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

คำว่า "เหมือง" มีความหลากหลายมากมายตามความหมายของมัน "ภรรยาของฉัน" และ "แปรงสีฟันของฉัน" ไม่ขนานกันอย่างเคร่งครัด


4

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

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

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


3

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


0

ใช่และไม่.

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

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


0

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


0

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

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


0

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

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

ในทางกลับกัน (ตระหนักดีว่าฉันอาจจะย้ำสิ่งที่ @ S.Lott กล่าว) หากรหัสกำลังจะลงเอยเป็นทรัพย์สินของลูกค้าแล้วไม่มีความหมายในการรับซาบซึ้งมากกว่านั้น มันเหมือน ... การดูแลลูกสุนัขของเพื่อนคุณเมื่อเขาไปเที่ยวพักผ่อน : - /


0

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

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

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

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


0

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

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

ในทางกลับกัน: มีหลายสิ่งที่ฉันชอบมากกว่าที่จะทิ้งส่วนที่ล้าสมัยของ codebase ไม่ว่างานเขียนนั้นจะยากแค่ไหน การเดินทางมีความสำคัญมากกว่าผลิตภัณฑ์ (อย่างน้อยสำหรับอัตตาแน่นอนว่าผลิตภัณฑ์นั้นต้องทำงานด้วยเช่นกัน)

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

ดังนั้นในทั้งหมดที่ฉันพยายามที่จะใช้ "ความสัมพันธ์" ในทางปฏิบัติกับรหัสที่ฉันเขียน


0

นรกใช่ฉันเคยเอาชนะเพื่อนร่วมงานคนหนึ่งเพราะเขาหยิ่งพอที่จะเปลี่ยนชื่อตัวแปรสองสามอย่าง

ไม่ไม่ได้จริงๆ ฉันได้รับเงินสำหรับการพัฒนาซอฟต์แวร์ แม้ว่าฉันจะยอมรับการเห็นการแก้ไขข้อบกพร่องที่ทำกับรหัสของฉันโดย devs อื่น ๆ มีผลกระทบต่อ - อัตตา -

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.