จะทำอย่างไรเมื่อคุณหมดทุกเส้นทางเพื่อแก้ไขข้อบกพร่อง

ฉันเป็นโปรแกรมเมอร์รุ่นเยาว์ (ประสบการณ์การทำงาน 4 เดือนจนถึงปัจจุบัน) ทำงานกับ Cross Application Mobile Application (ทีม 1 คน - ดังนั้นเป็นเพียงตัวฉันเอง)

ฉันมีข้อบกพร่องในโปรแกรม / แอพนี้ซึ่งค่อนข้างใหญ่ (30 ไฟล์ส่วนหัวที่แตกต่างกันแต่ละไฟล์มี cpp ของตัวเองด้วย) ฉันพยายามติดตามสิ่งที่เกิดขึ้นกับข้อผิดพลาด & เพื่อแก้ไข (แม้พยายามใช้แฮ็กเพื่อให้ทำงานได้) แต่มีวิธีแก้ปัญหามากกว่าหนึ่งโหลหรือมากกว่า (ความคิดที่ฉันมีคือสาเหตุของปัญหา ) ฉันไม่มีสิ่งใดมากระตุ้นให้ฉันติดตามสิ่งที่เป็นข้อบกพร่องหรือแก้ไขข้อผิดพลาด

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

เพื่อให้บริบทเพิ่มเติมเล็กน้อยสำหรับข้อบกพร่องของฉัน มันเกี่ยวข้องกับข้ามแพลตฟอร์ม API Mosync เมื่อฉันดำเนินการตามลำดับที่เฉพาะเจาะจงของหน้าจอปัจจุบันไม่ได้วาดใหม่ (& ปรากฏขึ้น) ว่าหน้าจอที่แสดงก่อนหน้านี้ยังคงได้รับเหตุการณ์ตัวชี้ / การกดปุ่ม & ไม่ใช่หน้าจอปัจจุบัน

ลำดับที่เฉพาะเจาะจง:
- หน้าจอเมนูที่แสดง - คลิก "แสดงปุ่มคำสั่ง prev"
- หน้าจอคำสั่งซื้อที่แสดง - คลิก "โหลดไฟล์" จากนั้นคลิกปุ่มเมนูและเปิดหน้าจอการ
จัดส่ง - หน้าจอการจัดส่งแสดง - ปุ่มเมนูและเปิดหน้าจอ
ซื้อ - ข้อผิดพลาดที่นี่การป้อนข้อมูลไปที่หน้าจอนี้จะไม่แสดง / ตอบสนองต่อ ListViews อย่าเลื่อนปุ่มไม่ตอบสนองต่อการคลิกเซลล์ ListView ไม่ตอบสนองต่อการคลิก

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

... และไม่มีการออกจากการฝึกงานที่ได้รับค่าจ้างนี้ไม่ใช่ทางเลือกสัญญาบอกว่าถ้าฉันออกไปก่อน 6 เดือนจำนวน 12 เดือนสัญญาฉันอาจต้องจ่าย 30% ของเงินเดือนประจำปีของฉัน

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

แก้ไข:

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

การดีบักนั้นเกี่ยวกับการแยกและการทำความเข้าใจอย่างชัดเจนว่าปัญหาคืออะไร (เปรียบเทียบกับการใช้การแก้ไข)

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

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

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

1. ตระหนักดีว่ามันเป็นเพียงรหัสและบางแห่งในนั้นมีจุดบกพร่อง (ไม่ใช่แค่มนต์ดำ) ที่คุณสามารถแก้ไขได้
2. หยุดพัก.
3. ค่อยๆผ่านโค้ดอย่างช้าๆวิเคราะห์แต่ละขั้นตอนและตรวจสอบให้แน่ใจว่าคุณเข้าใจและทำอะไรอยู่
4. รับดวงตาคู่ที่สองเพื่อดูปัญหา
5. ไปนอนแล้วลืมมันไปจนพรุ่งนี้ (เคลียร์หัว) พร้อมมุมมองใหม่ ๆ
6. พิมพ์รหัสของคุณและวิเคราะห์แต่ละบรรทัดจดบันทึกที่ระยะขอบทำความเข้าใจทุกความหมายของทุกบรรทัด
7. หากไม่ใช่ข้อผิดพลาดร้ายแรง แต่เป็นสาเหตุของข้อผิดพลาดที่ผู้ใช้ไม่จำเป็นต้องทราบฉันมี (ละอายใจ แต่อย่างตรงไปตรงมา) ดักข้อผิดพลาดและกลืนมัน! ถ้ามันไม่อันตรายและคุณไม่สามารถหาสาเหตุได้บางครั้งคุณก็ดักจับมันและอย่าให้ผู้ใช้รู้ว่ามีอะไรเกิดขึ้น มันคือทั้งหมดที่เกี่ยวกับ ROI สำหรับลูกค้าและบางครั้งก็ไม่คุ้มค่า
8. แจ้งข้อผิดพลาดด้วยวาจาว่าคุณกำลังจะตามล่ามันและฆ่ามัน บางครั้งมันจะวิ่งหนี :-)

ฉันมักจะมีวิธีนี้เมื่อแก้ไขข้อบกพร่อง

1. สร้างทีละขั้นตอนเพื่อทำซ้ำบั๊ก
2. ลดความซับซ้อนของขั้นตอน
3. จุดบกพร่องในรหัสเกิดขึ้นที่ไหน ชอบฟังก์ชั่นอะไรบ้างที่เกี่ยวข้อง?
4. รหัสใดที่เส้นทางเลือกเมื่อเกิดข้อผิดพลาดคือ callchain
5. มุ่งเน้นไปที่สถานที่เมื่อมันโอเคเมื่อมันไม่ได้ จากนั้นทำซ้ำสิ่งนี้มากจนกระทั่งคุณพบจุดที่ข้อผิดพลาดเกิดขึ้น
6. ทำไมสิ่งนี้ถึงเกิดขึ้น

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

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

คำแนะนำก่อนหน้าทั้งหมดนั้นยอดเยี่ยมมากและส่วนใหญ่มีจุดประสงค์เพื่อตรวจสอบข้อสมมติฐานเกี่ยวกับข้อผิดพลาด / ข้อผิดพลาดจากนั้นทำตามกระบวนการตรวจแก้จุดบกพร่องเพื่อค้นหาข้อผิดพลาด (บางครั้งโดยการตรวจสอบสภาพแวดล้อมรอบข้อบกพร่องและบางครั้งโดยตรงในรหัส)

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

ดังที่คนอื่น ๆ กล่าวไว้ 1) สามารถทำซ้ำได้อย่างน่าเชื่อถือและ 2) ก้าวไปข้างหน้าในตัวดีบั๊กถึงจุดที่มันเกิดขึ้น

หากฉันไม่สามารถทำได้ด้วยเหตุผลใดก็ตามฉันมีวิธีอื่นสองวิธีที่ทั้งสองต้องมีรหัสรุ่นอื่นที่ไม่มีข้อผิดพลาด

1. เรียกใช้โค้ดทั้งสองรุ่นเคียงข้างกันภายใต้โปรแกรมดีบั๊ก ก้าวไปตามพวกเขาจนคนเลวทำสิ่งที่แตกต่างจากคนดี

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

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

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

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

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

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

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

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

อย่าถือว่าห้องสมุดของคุณถูกต้องยืนยันว่าเป็น

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

คำตอบที่ดีมากมายที่นี่ เคล็ดลับอื่น ๆ :

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

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

ในขณะที่คุณกำลังอ่านโค้ด - ซึ่งคุณควรใช้เวลาในการทำมากทำให้เกิดปัญหาในบั๊ก - ระวังการปฏิบัติที่ไม่ดีบางอย่างที่อาจปิดบังบั๊กของคุณ คุณเห็นสิ่งนี้หรือไม่?

try {
    SaveTheWorld();
} catch (std::exception& ex) { /* oh it didn't work, let's just ignore it */ }

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

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

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

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

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

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

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

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

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