คุณควรเขียนเอกสารที่ดีและรหัสสะอาดเพื่อเพิ่ม "Bus Factor" หรือไม่?

หนึ่งในเป้าหมายหลักของ บริษัท พัฒนาซอฟแวร์คือการเพิ่มของพวกเขาปัจจัย Busนี้จะยังสนับสนุนในการพูดคุยที่ถูกจัดขึ้นโดย Google

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

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

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

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

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

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

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

ป.ล. ทั้งนายกรีนและมาเซียเวลลีไม่ได้ทำอะไรนอกจากการเขียนหนังสือที่พยายามจะประจบสอพลอได้ ใช้คำแนะนำของพวกเขาด้วยเม็ดเกลือ

หากคุณไม่สามารถถูกแทนที่ได้คุณจะไม่สามารถเลื่อนขั้น

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

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

สุสานเต็มไปด้วยมนุษย์ที่ขาดไม่ได้
- Gaulle, Charles De

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

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

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

  int sendData (int targetModule, เป็นโมฆะ * ข้อมูล, size_t byteCount);
  int recvData (int sourceModule, เป็นโมฆะ * ข้อมูล, size_t maxBytes);

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

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

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

การทำซ้ำได้นั้นไม่ได้ขัดกับความสนใจของนักพัฒนาหรือไม่?

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

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

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

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

การทำซ้ำได้นั้นไม่ได้ขัดกับความสนใจของนักพัฒนาหรือไม่?

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

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

ดูวิธีอื่น: นักพัฒนากี่คนตกงานโดยเป็นคนที่เขียนโค้ดที่ทุกคนสามารถอ่านได้

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

ฉันไม่รู้ว่าคุณเป็นคนแบบไหน แต่นั่นก็เป็นสิ่งที่ฉันสนใจมากกว่า

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

การทำซ้ำได้นั้นไม่ได้ขัดกับความสนใจของนักพัฒนาหรือไม่?

คุณพูดถูก แต่ฉันคิดว่าคุณเข้าใจความหมายของการถอดเปลี่ยนได้ ฉันสามารถหานักพัฒนา 1,000 คนที่เขียนโค้ดที่น่าตื่นเต้นซึ่งไม่มีเอกสารที่สามารถเปลี่ยนเป็นความยุ่งเหยิงอย่างรวดเร็ว

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

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

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

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

คุณต้องการเส้นทางไหน

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

ในทางกลับกันการเปลี่ยนได้จะให้ประโยชน์ที่ประเมินค่าไม่ได้หลายประการแก่คุณ:

• ความสามารถในการพักร้อน
• ไม่ได้อยู่ในสาย
• อิสระในการออกและทำงานในโครงการใหม่และที่มีอยู่

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

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

ในที่สุดเอกสารที่ยอดเยี่ยมจะล้าสมัยด้วยการเปลี่ยนโครงสร้าง / การวิวัฒนาการและการทำให้เป็นปัจจุบันนั้นใช้เวลานานจริงๆ

ทำความสะอาดรหัส + หน่วยทดสอบ> เอกสารที่ยอดเยี่ยม

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

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

หนึ่งในเป้าหมายหลักของ บริษัท พัฒนาซอฟต์แวร์คือการเพิ่มปัจจัย Bus

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

กฎข้อที่ 11เรียนรู้ที่จะทำให้คนพึ่งพาคุณ

สิ่งนี้มีความหมายต่อคุณอย่างไร?

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

มันคือสายของคุณ

(สมมติว่ามีรหัสการผลิต)

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

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

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

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

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

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

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

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

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

ดูเหมือนว่าหากพนักงานที่คาดหวังเห็นว่ากฎหมายแห่งอำนาจทั้ง48 ฉบับนั้นเป็นที่ยอมรับทางจริยธรรมหรือทางศีลธรรมคุณก็จะดีขึ้นหากไม่มีพวกเขา

หากคุณต้องการที่จะถูกแทนที่ไม่ได้จริงๆ (ซึ่งคุณอาจต้องการพิจารณาใหม่หลังจากอ่านคำตอบทั้งหมด ... ) - ทำไมหยุดด้วยการไม่บันทึกรหัส?

มีแนวทางที่ยอดเยี่ยมอย่างแท้จริงเกี่ยวกับวิธีการเขียนโค้ดที่ไม่สามารถทำลายได้ที่คุณควรอ่านอย่างแน่นอน: http://thc.org/root/phun/unmaintain.html

สนุก! (แน่นอนที่สุดฉันทำ ... )