ความขัดแย้งกับโครงการนำมาตรฐานการเข้ารหัส [ปิด]

ดังนั้นฉันจึงกำลังทำงานในโครงการใหม่พร้อมกับหัวหน้าโครงการของฉันในช่วง 1 ปีที่ผ่านมา

ตอนแรกเรามีโปรเจคย่อยของเราที่อาศัยอยู่ใน repos git แยกกันฉันมีปฏิสัมพันธ์กับโค้ดของเขาน้อยดังนั้นกลิ่นโค้ดไม่ได้รบกวนฉัน ประมาณ 6 เดือนต่อมาฉันเริ่มรักษาและเพิ่มฟีเจอร์ในโค้ดของเขาเนื่องจากฉันมีบทบาทมากขึ้นในโครงการ

ตอนนี้ฉันเป็นผู้พัฒนานำสำหรับทั้งโครงการย่อย (ทีมกำลังจะเติบโต; เขายังอยู่เหนือฉัน) สิ่งเหล่านี้รบกวนฉันและฉันต้องการดูแลพวกเขา แต่ถูกปฏิเสธ:

1. ไม่มีเครื่องหมายปีกกา, ฟังก์ชันตัวพิมพ์ใหญ่, การใช้คำพูดแบบผสม (ตรรกะดับเบิลและเดี่ยวที่มีลอจิกซ่อน), ไม่ใช้ ===, คลาสเรียนขนาดใหญ่พร้อมฟังก์ชั่นมากมาย บรรทัดล่างอาจจะดีกว่า
2. พึ่งพาตัวเลือกของ PHP เพื่อปิดการแจ้งเตือน / คำเตือน รหัสเต็มไปด้วยการใช้ตัวแปรและคีย์อาร์เรย์ ตัวแปรถูกนิยามไว้ภายใน ifs

ข้อโต้แย้งเกี่ยวกับปัญหา 2 ข้อข้างต้น:

1. ไม่ต้องการบังคับใช้รูปแบบการเข้ารหัสกับผู้คน
2. ถือได้ว่าเป็นคุณสมบัติภาษาซึ่งยืมตัวเองเพื่อรหัสสั้น / มีประสิทธิภาพมากขึ้น

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

ฉันต้องการจัดแนวทั้งสองโครงการให้ใช้แนวทางเดียวกันเนื่องจากแยกกันไม่ออก

ฉันผิดหรือเปล่า? ฉันกำหนดความต้องการส่วนตัวของฉันหรือไม่?

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

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

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

ตามความคิดเห็นของฉันด้านบน:

หากเขาเป็นผู้นำโครงการดูเหมือนจะบอกเป็นนัยว่ามันเป็นสายของเขา

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

การได้อยู่เหนือเขาเป็นไปได้ก็ต่อเมื่อคุณสร้างกรณีที่มีเหตุผลว่าทำไมควรมีมาตรฐานที่ดีกว่า

โดยทั่วไป:

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

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

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

มันก็มักจะขึ้นอยู่กับว่าคุณถาม ตัวอย่าง:

คุณต้องการอะไร:

ทำให้รหัสสวยขึ้น

สิ่งที่ไม่ควรพูด:

รหัสของคุณเป็นไปอย่างที่เป็นอยู่

สิ่งที่จะพูด:

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

คุณต้องการอะไร:

ไม่มีคำเตือนที่ไม่ถูกตรวจสอบเพิ่มเติม

สิ่งที่ไม่ควรพูด:

รหัสของคุณเป็นไปอย่างที่เป็นอยู่

สิ่งที่จะพูด:

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

และสุดท้าย:

ฉันรู้ว่ามันไม่สำคัญ ดังนั้นฉันยินดีที่จะทำเมื่อสิ่งที่มีลำดับความสำคัญสูงอยู่นอกโต๊ะก่อน

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

ข้อความด้านข้าง

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

นี่อาจจะเป็นข้อโต้แย้ง แต่ ...

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

ไม่เคย เคย ทำ. นี้. EVER ทุกครั้งที่คุณทำเช่นนี้มันทำให้เราทุกคนย้อนกลับไปหนึ่งทศวรรษ นี่คือวิธีที่จะเล่น:

• ผู้จัดการอาวุโส 1: "เราถูกขอให้จัดการกับปัญหานี้ blah, blah, blah, บางอย่างเกี่ยวกับมาตรฐานการเข้ารหัสและการเสียเวลา"

• ผู้จัดการอาวุโส 2: "แล้วพวกเขาก็ขอให้เราแก้ไขสงครามสนามหญ้าเน่าเพราะ?"

• ผู้จัดการอาวุโส 3: "เพราะพวกเขาเป็นเด็กขี้เกียจที่ไม่สามารถสื่อสารและไม่สนใจ / เข้าใจคุณค่าทางธุรกิจคืออะไร *"

• ผู้จัดการอาวุโส 2: "ต้องเป็นอย่างนั้นใครจะเล่นกอล์ฟ?"

จากนั้นคุณและหัวหน้าของคุณจะมาทบทวนเวลา:

"[ผู้จัดการอาวุโสของเจ้านาย]: ฉันขอโทษ แต่มีข้อกังวลบางอย่างที่คุณไม่สามารถจัดการรายงานโดยตรงของคุณและคุณอาจไม่ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุด (แม้ว่าฉันจะไม่รู้ว่าคุณทำอะไรยกเว้นพิมพ์จัมโบ้ mumbo บางส่วน ทำให้ซอฟต์แวร์ใช้งานได้) "

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

และนี่คือเหตุผลที่เราจ่ายเงินส่วนใหญ่น้อยกว่าค่าที่เราสร้าง **

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

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

** สำหรับคนที่คิดว่าภาพลักษณ์ของผู้บริหารระดับสูงว่าเป็น clueless a-hole นั้นไม่สมจริงโปรดเข้าใจว่าผู้จัดการให้ความสำคัญกับการจัดการคนในแบบที่เราใส่ใจเกี่ยวกับการจัดการรหัส พวกเขาอาจไม่รู้เรื่องทางเทคนิค แต่พวกเขารู้จักผู้คนและนั่นคือเหตุผลเพิ่มเติมที่ทำให้พวกเขามีข้อโต้แย้งว่า A) พวกเขาอาจไม่มีคุณสมบัติที่จะแก้ไขและ B) คุณสองคนนั้นควรจะแก้ไขได้โดยไม่ต้องได้รับความช่วยเหลือ ทำให้คุณดูไม่ดี

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

IMHO คุณกำลังเผชิญกับนักพัฒนา 'ที่ใช้งานได้' ไม่ใช่นักพัฒนาที่จะดูแลพวกเขาต่อไป ข้อโต้แย้งของเขาไร้ค่า

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

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

แต่ฉันอาจจะตอบคุณบางอย่างเป็นน้ำเสียง:

มันใช้งานได้ไม่มีประโยชน์ที่จะเปลี่ยนแปลง

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

เมื่อคุณทำงานในโครงการคุณจะต้องกำหนดลำดับความสำคัญ

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

และการเปลี่ยนรหัสที่มีอยู่เพื่อให้สอดคล้องกับมาตรฐานการเข้ารหัสใหม่นั้นต่ำมากในรายการลำดับความสำคัญ

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

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

PHP ไม่ใช่กลุ่มที่ยอดเยี่ยมที่สุดในอาชีพของเรา อันที่จริงคุณกำลังวิจารณ์ระบบซอฟต์แวร์ของเขาที่อาจชนะได้ยาก มาตรฐานวิชาชีพของคุณนั้นสูงกว่าของเขา

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

ฉันไม่รู้เกี่ยวกับตลาด PHP ในปัจจุบันของคุณ แต่คุณอาจจะเปลี่ยนไปบ้าง เรียนรู้ภาษา hype ด้วยหรือโพรงเช่น C #

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

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

การกำหนดรูปแบบของฐานรหัสเป็นการใช้เวลาของคุณอย่างคุ้มค่าที่สุดหรือไม่?

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

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

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

ด้วยวิธีนี้การเปลี่ยนแปลงแต่ละอย่าง:

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

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

ถามคำถามเกี่ยวกับโอกาสในการขายของคุณ

• พวกเขาเคยทำงานคนเดียวหรือกับทีมงานเล็ก ๆ หรือไม่?
• พวกเขาส่วนใหญ่เขียนที่ร้านนี้หรือไม่?
• พวกเขาเคยตัดสินใจหรือไม่?
• พวกเขาเคย "ทำเสร็จ" หรือไม่?
• พวกเขาเขียนโค้ดส่วนใหญ่หรือไม่?

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

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

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

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

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

นี่คือคนที่ไม่เคยเรียนรู้วิศวกรรมซอฟต์แวร์และสถาปัตยกรรมซอฟต์แวร์อย่างถูกต้อง พวกเขาเพียงแค่เรียงลำดับบางสิ่งเข้าด้วยกัน

คุณมีปัญหาคนไม่ใช่ปัญหาด้านเทคโนโลยี

คุณจะต้องฝึกซ้อมนำของคุณหรือคุณจะต้องออกจาก

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

หากต้องการฝึกฝนใหม่คุณจะต้อง ...

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

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

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

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

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

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

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

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

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

ฉันผิดหรือเปล่า?

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

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

บรรทัดล่างไม่ใช่รหัสที่ฉันต้องการใช้งาน

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

ฉันกำหนดความต้องการส่วนตัวของฉันหรือไม่?

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

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

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

นอกจากนี้คุณยังสามารถ (ฉันคิดว่า) ถามคนที่แก้ไขไฟล์อย่างมีเหตุผลในสไตล์ที่เขียนไฟล์ไว้แล้ว ที่ช่วยให้คุณรักษามาตรฐานในไฟล์ที่คุณเขียน น่าเสียดายที่การพลิกกลับของเรื่องนี้คือคุณต้องแก้ไขไฟล์ที่เขาเขียนในบางสิ่งที่คล้ายกับสไตล์ของเขา

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

[ผู้จัดการของฉันบอกว่าเขาไม่ได้] ต้องการบังคับใช้รูปแบบการเข้ารหัสกับคน [เพราะ] เราไม่ใช่หุ่นยนต์

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

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

แม้แต่สไตล์ที่ไม่ดีก็ยังดีกว่าไม่มีสไตล์เลย