คำถามติดแท็ก technical-debt

ฉันเขียนโปรแกรมมาสองสามปีและคุ้นเคยกับ C # และ JavaScript เมื่อเวลาผ่านไป ฉันมีโครงการ C # และ JavaScript ที่ใหญ่กว่าซึ่งฉันไม่มีปัญหาในการนำทาง ฉันเพิ่งเริ่มต้นโครงการ PHP & AngularJS สำหรับการทำงานที่ไม่มีประสบการณ์มาก่อนด้วย PHP กระแสของสิ่งต่าง ๆ ใน PHP กลายเป็นเรื่องยากที่จะติดตาม (ด้าน JavaScript มีขนาดใหญ่ขึ้น แต่ง่ายต่อการทำงาน) เมื่อฉันลองและคิดในเรื่องนั้นฉันคิดว่าลูกบอลที่พันกันยุ่งเหยิง ข้อผิดพลาดในการออกแบบที่สำคัญที่ฉันทำเมื่อฉันเริ่มจะเริ่มกองพะเนินเทินทึกและมีผลต่อการออกแบบของฉันไปข้างหน้า ใช้เวลานานขึ้นและนานขึ้นในการใช้งานสิ่งใหม่ ฉันอยู่ในกำหนดเส้นตายและพบว่ามันยากและยากที่จะเขียนดี DRY ของแข็งรหัส มันยิ่งดึงดูดให้คัดลอก / วางชิ้นส่วนของรหัสเพื่อสร้างพฤติกรรมที่เปลี่ยนแปลงเล็กน้อยเมื่อเวลาในการออกแบบเพิ่มขึ้น นอกจากนี้ยังใช้เวลานานในการกลับไปที่ฐานรหัสเมื่อใดก็ตามที่ฉันต้องทำการสลับบริบท (จากโครงการหนึ่งจากนั้นกลับสู่โครงการนี้) ฉันมีความรู้สึกกลัวเมื่อใดก็ตามที่ฉันกลับไปทำงานในโครงการนี้ ขั้นตอนใดที่ฉันสามารถแก้ไขได้ เวลาเพิ่มเติมอาจต้องมีความสมเหตุสมผลเช่นกันเจ้านายของฉันไม่ใช่นักพัฒนาและไม่คุ้นเคยกับการพัฒนาหรือวงจรชีวิตของซอฟต์แวร์ดังนั้นการอธิบายอาจยากกว่าปกติ

14 php  javascript  web-applications  code-smell  technical-debt 

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

13 architecture  coding-style  management  technical-debt 

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

13 users  technical-debt  product-management 

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

12 management  communication  technical-debt 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ดูดน้อยทุกปี -Jeff Atwood ฉันเจอบทความที่ลึกซึ้งแล้วการอ้างอิงโดยตรงจากโพสต์ ฉันมักจะคิดว่าการดูดน้อยลงทุก ๆ ปีเป็นสิ่งที่โปรแกรมเมอร์ผู้ถ่อมตนพัฒนาขึ้น คุณควรไม่พอใจกับรหัสที่คุณเขียนเมื่อปีที่แล้ว หากไม่เป็นเช่นนั้นหมายความว่า A) คุณไม่ได้เรียนรู้อะไรเลยในหนึ่งปี B) รหัสของคุณไม่สามารถปรับปรุงได้หรือ C) คุณไม่เคยทบทวนรหัสเดิมอีกเลย ทั้งหมดนี้คือความตายของนักพัฒนาซอฟต์แวร์ สิ่งนี้เกิดขึ้นบ่อยแค่ไหนหรือไม่เกิดขึ้นกับคุณ? นานแค่ไหนก่อนที่คุณจะเห็นการปรับปรุงที่แท้จริงในการเข้ารหัสของคุณ เดือนปี? คุณเคยทบทวนรหัสเดิมของคุณอีกครั้งหรือไม่? รหัสเก่าของคุณทำให้เกิดภัยพิบัติบ่อยแค่ไหน หรือคุณต้องจัดการกับหนี้ทางเทคนิคของคุณบ่อยเพียงใด แน่นอนว่ามันเป็นเรื่องที่เจ็บปวดอย่างมากที่จะแก้ไขข้อบกพร่องเก่า ๆ และรหัสสกปรกที่เราอาจทำเพื่อให้ตรงตามกำหนดเวลาและการแก้ไขอย่างรวดเร็วเหล่านั้นในบางกรณีเราอาจต้องเขียนแอปพลิเคชั่น / รหัสใหม่เกือบทั้งหมด ไม่มีข้อโต้แย้งเกี่ยวกับเรื่องนี้ นักพัฒนาบางคนที่ฉันเจอเจอแย้งว่าพวกเขาอยู่ในช่วงวิวัฒนาการซึ่งการเข้ารหัสของพวกเขาไม่ต้องการการปรับปรุงหรือไม่สามารถพัฒนาได้อีกต่อไป สิ่งนี้เกิดขึ้นหรือไม่ ถ้าเป็นเช่นนั้นกี่ปีในการเขียนโค้ดกับภาษาใดภาษาหนึ่งคาดว่าสิ่งนี้จะเกิดขึ้น? ที่เกี่ยวข้อง: เคยมองย้อนกลับไปที่บางส่วนของรหัสเก่าของคุณและแสยะด้วยความเจ็บปวด? Star Wars Moment in Code "ลุค! ฉันเป็นรหัสของคุณ!" "ไม่! เป็นไปไม่ได้! มันเป็นไปไม่ได้!"

10 self-improvement  technical-debt