การล่อลวงที่เป็นอันตรายในการเขียนโปรแกรม


97

แค่อยากรู้อยากเห็นสิ่งล่อใจในการเขียนโปรแกรมประเภทใดบ้างที่เป็นอันตรายในโครงการของคุณ?

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

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

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

ปีศาจการเขียนโปรแกรมของคุณคืออะไรและคุณจะหลีกเลี่ยงได้อย่างไร


19
ฉันพบว่ามันน่าขบขันที่ไม่มีใครสามารถตอบคำถามตอนที่สองของคุณ - "[และ] คุณจะหลีกเลี่ยงได้อย่างไร"
Craige

3
มีใครสังเกตเห็นว่านี่เป็นคำถามยอดนิยมใน SE ตลอดทั้งวัน
msarchet

+1 สำหรับ "... ใช้เวลาหลายชั่วโมงในการเปลี่ยนเลย์เอาต์ UI ... " ฉันตกหลุมพรางนั้นบ่อยเกินไป
7wp

คำตอบ:


67

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

ปรับปรุง:

ดู " บาป # 1 -หลักเกณฑ์ทั่วไปก่อนกำหนด " สำหรับคำอธิบายเชิงลึก


6
ฉันเกลียดเมื่อนักบินอวกาศสถาปัตยกรรมทำเช่นนั้น!
ozz

13
โอ้ความสุขของ metafactoryfactories :(

+1 "การศึกษาของนักออกแบบที่ยอดเยี่ยมพบว่าพวกเขาทุกคนเก่งในการคาดการณ์การเปลี่ยนแปลง" (Code Complete 2) เป็นการดีที่จะสามารถบอกได้ว่าการเปลี่ยนแปลงประเภทใดมีแนวโน้ม จากนั้นคุณสามารถตัดสินใจได้ว่าจะมีสิ่งใดที่จะได้รับจากการแก้ไขกรณีทั่วไปที่มากขึ้นในช่วงต้น - ไม่ว่าจะประหยัดเวลาในภายหลัง บางครั้งมันไม่คุ้มค่ามันจะง่ายในการปรับเปลี่ยนรหัสในภายหลัง
MarkJ

1
คุณเคยได้ยินเกี่ยวกับYAGNI (คุณไม่ต้องการมัน)หลักการ?
Oscar Mederos

1
นี้. ฉันใส่ความผิดเกี่ยวกับความจริงที่ว่าการสร้างโค้ดที่สวยทั่วไปและใช้งานซ้ำได้นั้นเป็นที่น่าพอใจอย่างมากโดยเฉพาะอย่างยิ่งหากปัญหาของตัวเองไม่ได้ท้าทายมากและ / หรือเป็นเพียงการทำซ้ำสิ่งที่คุณเคยทำ ในกรณีที่จุดการดำเนินงานฐานข้อมูล CRUD ทั่วไป (UI ตอบสนองต่อการกระทำของผู้ใช้ทำอะไรกับ DB, thar)
คธูลู

197

"เราจะกลับมาที่นี่และแก้ไขมันทีหลังเราแค่ต้องการมันตอนนี้!"


16
นี่คือมารที่แน่นอน
alesplin

6
ฉันจะให้ +100 สำหรับสิ่งนี้ถ้าทำได้ "ภายหลัง" ไม่เคยเกิดขึ้น ทำสิ่งที่ถูกต้องในครั้งแรกหรือไม่เลย
quick_now

12
นี่ไม่ใช่ส่วนเสริมของการใช้เวลาหลายชั่วโมงในการสร้างรหัสที่ไม่ดีใหม่ เราสามารถแบ่งโลกในการเขียนโปรแกรมที่ "จะแก้ไขได้ในภายหลัง" แต่ไม่และโปรแกรมเมอร์ที่พยายามทำให้ถูกต้องในครั้งแรกแล้วใช้เวลาหลายชั่วโมง "refactoring bad code"

6
วลีนี้อีกครั้งเป็น "เราจะกลับมาและแก้ไขการทำซ้ำครั้งต่อไปนี้" และฟังดูมีโครงสร้างมากขึ้น
Chris S

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

105

กำหนดเส้นตายอยู่ไกลมากฉันมีเวลามากพอที่จะทำมันทำไมไม่ลองใช้เวลาสักครู่ในการท่องเว็บ?


72
แทนที่ "เว็บ" ด้วย "programmers.stackexchange.com" :)
davidhaskins

1
มีสิ่งใดในเว็บที่ควรค่าแก่การอ่านอีกหรือไม่ ฉันลืมไปแล้วว่ามีสิ่งอื่นอีก!
James McLeod

3
อาคา 'Damn you, Minecraft'
johnc

1
@ David นั่นเป็นเพียงจุดเริ่มต้นบนเว็บ - คำถามคือไกลแค่ไหนที่คุณได้รับ ...

Id 'บอกว่านี่ไม่ถูกต้องอีกต่อไปแล้วเนื่องจาก Agile
vartec

103

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


13
สิ่งนี้เรียกว่าการพัฒนาแอปพลิเคชันอย่างรวดเร็ว และมันไม่เคยทำงานในสภาพแวดล้อมทางธุรกิจ :)
John Kraft

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

6
ฉันทำงานด้านการเงินและ RAD ยังคงแข็งแกร่งโดยเฉพาะอย่างยิ่ง VBA / Excel มีความสามารถพิเศษคือแม้ว่า RAD ไม่จำเป็นต้องหมายถึงเลอะเทอะ
เอียน

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

12
นี้. ฉัน: "นี่เป็นเพียงหลักฐานพิสูจน์ของฉันถ้าคุณชอบเราจะเขียนเวอร์ชันการผลิต" Manager: "เวอร์ชั่นของคุณใช้งานได้แล้วมาจัดส่ง!" ฉัน: "มันไม่ครอบคลุมการใช้งานทั้งหมด ca ... คุณส่งไปแล้วใช่ไหม?"

74
  1. การปรับโครงสร้างส่วนของโค้ดอีกสองสามวันก่อนการวางจำหน่าย
  2. อินเทอร์เน็ต:สิ่งที่ทำให้ไขว้เขวมากที่สุด
  3. เทคโนโลยีใหม่ : ไม่สามารถละทิ้งเทคโนโลยีใหม่
  4. Optimize: Optimize, Optimize .. และเพิ่มประสิทธิภาพมากขึ้น
  5. ความสมบูรณ์แบบ : ไม่เคยพอใจกับรหัส
  6. สิ่งที่ต้องทำ:การไม่มีเวลา to-do to-do ที่ไม่สามารถทำได้
  7. การประมาณเวลา: PMs ส่วนใหญ่ไม่ได้ใช้สิ่งนี้ว่า "ประมาณ" พวกเขาใช้ความจริง
  8. สัญญา:การให้สัญญามากเกินไป

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

2
เกี่ยวกับการประมาณเวลา ... ผู้จัดการจำนวนมากมองว่าเป็นจุดเริ่มต้นในการเจรจาต่อรอง (เช่นการต่อรองราคา) คนที่เข้าใจผิด แต่จริง ๆ แล้วสูงกว่าค่าเฉลี่ย ...
dbkk

@quickly_now การตัดเน็ตอาจใช้กับงานทางโลกเช่นการป้อนข้อมูลหรือการแก้ไขตามปกติซึ่งคุณไม่จำเป็นต้องค้นหาอะไรเลย สำหรับสิ่งที่ไม่ธรรมดา (เช่นการค้นหาเอกสาร API / โค้ดตัวอย่าง) Google เป็นเพื่อนของคุณ - ใช้เวลาในการคิดออกเอง 5 เท่า นอกจากนี้หากผู้คนไม่ได้รับแรงจูงใจและต้องการที่จะหันเหความสนใจพวกเขาจะหาวิธี
dbkk

@dbkk - ใช่จนถึงจุดหนึ่ง มันคือทั้งหมดใน Ada ไม่มี API ที่จะค้นหามันเป็นฮาร์ดแวร์พิเศษและจำแนก securoty ระดับชาติ การวางเครื่องเชื่อมต่ออินเทอร์เน็ตที่ไม่ได้จัดประเภทเข้ากับสภาพแวดล้อมนั้นเป็นฝันร้ายด้านความปลอดภัยเช่นกัน
quick_now

55

ตกเป็นเหยื่อของการพยายามสร้างทุกสิ่งภายใน บริษัท เมื่อมีกรอบและไลบรารีที่มีอยู่


6
บางครั้งเฟรมเวิร์กและไลบรารีที่มีอยู่จะถูกทำเครื่องหมาย Verboten ด้วยตัวอักษรสีแดงขนาดใหญ่ตามกฎหมายไอที
Christopher Mahan

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

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

2
@Christopher: ถ้าอย่างนั้นก็เป็นเหตุผลที่ดีที่จะนำไปใช้ใหม่ (หรือค้นหาไลบรารี่อื่นที่มีไลเซนส์ที่ยอมรับได้) แต่บ่อยครั้งที่เหตุผลในการปรับใช้งานใหม่เป็นเพียง NIH …
Donal Fellows

@Carson: +1 :-)
Macke

48

ปีศาจกำเริบของฉัน: การเพิ่มประสิทธิภาพก่อนกำหนดและการเอาชนะ

และฉันยังคงหลีกเลี่ยงไม่ได้ 100% ...


10
+1 สำหรับ overengineering ผมเคยเขียนทั้งกรอบ "การตั้งค่า" กับ "อะแดปเตอร์พารามิเตอร์การตั้งค่า" สำหรับไฟล์ ini ของไฟล์ XML, ตารางฐานข้อมูลและซ็อกเก็ตเครือข่าย (เพราะทุกคนต้องการที่จะเป็นเจ้าภาพการกำหนดค่าบริการเว็บใช่มั้ย?)
TMN

8
วิศวกรรมก่อนวัย?
Christopher Mahan

@Chris "overengineering ก่อนวัยอันควร" ใช้ได้เช่นกัน มันถูกกล่าวถึงในคำตอบอื่น ๆด้วย ฉันรู้ว่ามันเป็นหนึ่งในความหายนะของฉัน
Matthew Scharley

วิธีการเกี่ยวกับการคลอดก่อนกำหนดมากกว่าการเพิ่มประสิทธิภาพล้านวิศวกรรม ...
Newtopian

4
นี่เป็นของฉัน. ฉันวางความผิดในการจัดการให้ฉันเป็นอิสระ / กำหนดเส้นตายอนาคตไกลและไม่ให้ตัวเองกำหนดเวลาสำหรับองค์ประกอบเฉพาะ
คธูลู

46

ประมาณการในแง่ดีเกินไป

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

ท้ายที่สุดแล้วลำไส้ของคุณอาจต่ำเกินไป!


13
เมื่อพวกเขาถามคุณว่าจะใช้เวลานานขนาดนั้นจริงหรือเปล่าเพียงแค่พูดว่าใช่แล้วนั่งเงียบ ๆ จนกว่าพวกเขาจะรู้สึกอึดอัดใจ ...
PeterAllenWebb

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

2
อีกทางเลือกหนึ่งให้ลองใช้วิธีการ SMBC
Detly

4
หนึ่งในเจ้านายเก่าของฉันมีการประเมินผู้พัฒนาเพิ่มขึ้นสามเท่าจากนั้นจึงเจรจากับลูกค้าเป็นสองเท่า ลูกค้าคิดว่าพวกเขาได้รับข้อตกลงนักพัฒนามีเวลาที่พวกเขาต้องการแม้ว่าพวกเขาจะไม่รู้ win-win!
DaveE

2
การจัดตารางเวลาตามหลักฐานอาจช่วยแก้ไขปัญหานี้ได้: joelonsoftware.com/items/2007/10/26.html
Rei Miyasaka

33

เพื่อใช้เทคโนโลยี / เครื่องมือ / ภาษาในโครงการของคุณอย่างหมดจดเพราะคุณเพิ่งเรียนรู้มัน

เพื่อพยายามพิสูจน์ว่าคุณเป็นนักพัฒนาที่ดีเพียงใด

ในการพิจารณาโค้ดที่คุณเขียนให้เป็นของคุณ


ถ้าฉันทำได้เพียงโหวตขึ้นทุกครั้งที่ฉันทำ โชคดีที่ครึ่งหนึ่งของการแก้ปัญหากลับกลายเป็นว่าค่อนข้างดี ครึ่งหนึ่งไม่ได้
ด่าน

หรือที่คุณยังไม่ได้เรียนเลย อย่าลืมรัดสายเดือยของคุณเพราะมันจะเป็นการเดินทางที่ยาวนาน
Evan Plaice


31

สิ่งล่อใจที่เลวร้ายที่สุด:

โอ้ .. ฉันเดาว่าหนึ่งเล่ห์เหลี่ยม / แฮ็ก / แก้ไขสกปรกจะไม่เจ็บ

คาดเดาสิ่งที่มันจะเจ็บ :)

ไปที่


11
"การแก้ไขเกตเวย์"
ทำเครื่องหมาย C

4
การใช้gotoคำสั่งจะส่งผลให้การโจมตีของแร็พเตอร์
Maxpm

1
@ Maxm: ความคิดที่ดี! ที่รวมอยู่
Goran Jovic

1
@ Mark C, เกตเวย์แก้ไขคืออะไร? gøøgle-fu ของฉันไม่ดีพอ

1
@ Thorbjørn Ravn Andersen: en.wikipedia.org/wiki/Gateway_drug_theory
Jimmy

25

ลืมไปว่าการเขียนโค้ดเป็นรีสอร์ทที่ผ่านมาสำหรับการแก้ปัญหา


+1 ฉันคิดว่าคุณกำลังโน้มตัวไปในทิศทางที่จะท่องสถาปัตยกรรมวงโคจรจนกว่าฉันจะอ่านบทความ สิ่งที่ดี ...
Evan Plaice

23

คุณสมบัติคืบ

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

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


ปล่อยสเป็คที่ยังไม่ได้เปิดเผยและเปิดเป็นสัมปทานเพราะ PM คนแรก (ผู้ถูกไล่ออกในขณะนี้) ไม่รู้อะไรเลยเกี่ยวกับการพัฒนาซอฟต์แวร์และออกแบบกำหนดการวางจำหน่ายที่ไม่สมจริงอย่างสมบูรณ์ ความคิดที่เลวร้ายที่สุดที่เคย
Evan Plaice

20
  1. เพิ่มคุณสมบัติเพิ่มเติม

  2. การแข่งขันมีคุณสมบัตินี้ ดังนั้นนี่คือคุณสมบัติที่ต้องมีดังนั้นการเขียนโปรแกรมมากกว่าวิเคราะห์กลยุทธ์การวางตำแหน่ง ฯลฯ

  3. การแข่งขันไม่มีคุณสมบัตินี้ ดังนั้นนี่คือคุณสมบัติที่แตกต่างดังนั้นการเขียนโปรแกรมมากกว่าการวิเคราะห์กลยุทธ์การวางตำแหน่ง ฯลฯ

  4. การแก้ปัญหาทางธุรกิจด้วยการเขียนโปรแกรมเพิ่มเติม เช่นความเชี่ยวชาญที่ดีขึ้นในการจัดการเซิร์ฟเวอร์ linux ที่เว็บไซต์ของคุณโฮสต์อยู่นั้นไม่สามารถรับได้จากการเขียนโปรแกรมคุณสมบัติเพิ่มเติม บางครั้งคุณเพียงแค่ต้องเรียนรู้วิธีแก้ไขปัญหาแทนที่จะเขียนโค้ดใหม่ทั้งหมดลงใน C # .Net

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

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

  7. วางแผนรหัส แต่ยังไม่ได้เข้ารหัสเพราะคุณต้องการ "ทำให้ถูกต้อง"

  8. การเข้ารหัสรุ่นที่สกปรกและสัญญาว่าคุณจะ "ทำให้ดีขึ้นในภายหลัง" แต่อย่ากลับไปที่ "ทำให้ดีขึ้น"

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

คำสารภาพ: ฉันทำผิดพลาดเป็นการส่วนตัว 1, 3, 7, 8 ฉันทำผิด 2, 4, 5, 6 แต่มักจะพูดถึงตัวเองว่าฉันไม่ได้ทำ

ขณะนี้ฉันกำลังแก้ไข 9

แก้ไข ไม่ได้ตระหนักถึงคำถามที่เราต้องใส่ในการแก้ปัญหา

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

ไปอ่านเกี่ยวกับตัวสั่นด้วยความรู้สึกGrouponฯลฯ เกี่ยวกับวิธีที่พวกเขาเพียงแค่ตัดสิ่งต่าง ๆ ลงไปเพียง 1 สิ่งที่นำไปสู่ความสำเร็จของพวกเขา

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

2) การแข่งขันมีคุณสมบัตินี้ ดังนั้นนี่คือต้องมีคุณสมบัติ

ดูโซลูชัน 1

3) การแข่งขันไม่มีคุณสมบัตินี้ ดังนั้นนี่คือคุณสมบัติที่แตกต่าง

ดูโซลูชัน 1

4) การแก้ปัญหาทางธุรกิจด้วยการเขียนโปรแกรมเพิ่มเติม

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

5) การแก้ปัญหาการตลาดด้วยการเขียนโปรแกรมเพิ่มเติม

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

6) การแก้ปัญหาผลผลิตด้วยการเขียนโปรแกรมเพิ่มเติม

รอ.

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

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

ทวีคูณการประมาณของคุณด้วยอัตรารายชั่วโมง

ตอนนี้ตรวจสอบการแก้ปัญหาทางเลือก: outsource, ซื้อโซลูชันนอกชั้นวาง, ไม่ต้องทำอะไรเกี่ยวกับมัน, ฯลฯ

เลือกโซลูชันที่คุ้มค่าที่สุด

ติดมัน

7) วางแผนที่จะเขียนโค้ด แต่ยังไม่ได้เข้ารหัสเพราะคุณต้องการ "ทำให้ถูกต้อง"

ไปออกกำลังกาย คุณจะรู้สึกถึง endorphins ที่จะกระตุ้นให้ตูดของคุณและทำให้คุณวางแผนที่จะดำเนินการ ฉันรู้สิ่งนี้เพราะฉันเพิ่งจะทำการกดขนาด 5x5 และตัวที่ 5x5

8) การเข้ารหัสรุ่นที่สกปรกและสัญญาว่าคุณจะ "ทำให้ดีขึ้นในภายหลัง" แต่ไม่เคยกลับไปที่ "ทำให้ดีขึ้น"

ตั้งค่าระบบไฟล์ตัวเลือกใน GTD และติดตามอย่างจริงจัง ติดตามสัญญาทั้งหมดเพื่อตัวคุณเองและผู้อื่น

9) ไม่ทำการจำลองหรือแผนผังเว็บไซต์เพราะเป็น "ลำบากมาก"

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

สิ้นสุดการแก้ไข


+1 คำตอบนี้ แต่ฉันพบว่าอ่านยาก ฉันไม่เข้าใจบริบทของ 9 คะแนนแรก คุณจะช่วยชี้แจงไหม ยังคงเป็นงานที่ดี

@MattFenwick สวัสดีขอบคุณสำหรับ +1 ของคุณ โดยปกติแล้วคะแนน 1-5 จะนำไปใช้ในสถานการณ์การสร้างผลิตภัณฑ์เพื่อขาย แต่คุณสามารถนำไปใช้กับสถานการณ์ที่แนวโน้มการหาคำตอบที่ดีที่สุดนำคุณไปสู่การค้นคว้าอย่างกว้างขวางเกี่ยวกับงานศิลปะก่อนหน้า เช่นในการวิจัย
Kim Stacks

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

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

17

เบียร์สองขวดจะช่วยให้ฉันทำงานได้ดีขึ้นเรื่อย ๆ


11
เดี๋ยวก่อนคุณหมายความว่ายังไงเหรอ? ( xkcd.com/323 )
Craige

4
@Craige: หลังจาก 21 ปีมีประสบการณ์กับการดื่มและประสบการณ์ 20 ปีในฐานะวิศวกรซอฟต์แวร์มืออาชีพฉันยังคงทำงานในส่วนการสอบเทียบ
Adam Crossland

4
@adam คุณใช้เวลาหนึ่งปีในการดื่มเพื่อเป็นวิศวกรหรือไม่?

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

1
@Kitsched: ใช่! โดยเฉพาะอย่างยิ่งถ้าคุณมีการออกแบบที่มีอยู่แล้วของคนอื่นเพื่อฉ้อฉล
Mason Wheeler

16

"ใช่ฉันสามารถสร้างความยุ่งเหยิงขนาดมหึมาของปาเก็ตตี้ 2,000 บรรทัดในหนึ่งวัน ... "


13
อีกทางเลือกหนึ่ง: "คนใหม่ [ที่ไม่รู้อะไรเลยเกี่ยวกับซอฟต์แวร์หรือโครงสร้างของรหัส] ไม่ได้ทำอะไรเลยเขาสามารถแก้ไขได้" คะแนนโบนัสเมื่อผู้ชายไม่เคยใช้ภาษาที่เขียนรหัส
wildpeaks

16

“ ฉันสามารถผ่านได้โดยไม่ต้องทำการทดสอบมันยากเกินไปที่จะทดสอบ”

และมันก็เป็นพี่ชายที่ชั่วร้าย

"ฉันต้องมีการทดสอบสำหรับสิ่งนั้นไม่ว่าการทดสอบจะยากหรือยากแค่ไหน"


2
หากการทดสอบเป็นเรื่องยากที่จะเขียนคุณอาจไม่ได้รับการเขียนโปรแกรมมันขวา :)
เมอร์ลิน Morgan-เกรแฮม

2
@Merylyn Morgan-Graham ค่อนข้างจริง แต่มีบางพื้นที่เช่นการเกิดพร้อมกันที่ยากต่อการทดสอบ
Wayne Conrad

1
@Merlyn: หากคุณพบว่าคุณกำลังเขียนโปรแกรมจำลองการสอนเพื่อที่คุณจะได้บังคับให้สลับบริบทในสถานที่ที่เหมาะสมคุณก็อาจจะไปไกลเกินไปในการทดสอบภาวะพร้อมกัน :)
ซานคม

1
@ แซน: ฉันเห็นด้วย - ณ จุดที่ต้องการฉันจะผลักดัน devs และพยายามที่จะให้พวกเขาสร้างรหัสของพวกเขาใหม่และให้ฉันใส่ mocks ฉันทำงานกับ langauges ระดับสูงที่เราดู Big-O เพิ่มประสิทธิภาพคอขวดต้องคิดเกี่ยวกับการทำงานพร้อมกันส่วนใหญ่สำหรับความสมบูรณ์ของข้อมูลมากกว่าความเร็วดิบและจัดส่ง (และบ่อยครั้งที่ไม่มีใครเพราะมันเร็วธรรมดาพอ กล่อง).
Merlyn Morgan-Graham

15

การผัดวันประกันพรุ่งและการประเมินงานในแง่ดีเป็นบาปที่ใหญ่ที่สุดของฉัน

การยืดกล้ามเนื้อ, push-ups หรือ pull-ups (หรือการออกกำลังกายอื่น ๆ ) สำหรับคนแรกและอารมณ์ในแง่ร้ายก่อนที่จะให้การประเมินเป็นครั้งที่สอง


ชี้แจง ... โดย "การประเมินงานในแง่ดี" คุณหมายถึง 'โรคง่ายของอึ' ใช่ไหม? :)
Evan Plaice

@Evan Plaice - อย่างแน่นอน เช่น "โอ้มันช่างน่ารำคาญเหลือเกิน" จากนั้นจึง googling ตัวอักษรทุกตัวของรหัสของคุณหลังจากที่คุณเริ่มเขียนโค้ดจริง
Nikita Barsukov

13

" ง่ายกว่ามากที่จะปรับใช้การทำงานใหม่ตั้งแต่เริ่มต้นแทนที่จะเข้าใจโค้ดที่มีอยู่"


2
ใช่c2.com/cgi/wiki?RewriteCodeFromScratchอ้างว่านี่เป็นหนึ่งใน "สิ่งที่คุณไม่ควรทำ"
เดวิดแครี

การทำงานกับโอเพ่นซอร์สช่วยให้แนวโน้มนี้ ฉันเคยจ้องที่แพตช์ก่อนที่จะมองข้ามจากนั้นไปข้างหน้าและเขียนการใช้งานของฉันเองเท่านั้นที่จะตระหนักว่ามันใกล้เคียงกับแพทช์ มันตลกดีที่มันทำงานได้
Evan Plaice

10

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


10

NIH - ไม่ได้คิดค้นที่นี่

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

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


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

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

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

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

9

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

ฉันจะไม่เริ่มโครงการอีกครั้งจนกว่าจะมีสำเนาของข้อมูลจริง


หากยังไม่มีผลิตภัณฑ์จะมีการคัดลอกข้อมูลหรือไม่?
Svish

หากไม่มีข้อมูลแสดงว่ามีกระดาษอยู่เสมอ บันทึก บริษัท จะช่วยที่นี่เช่นกัน
burnt_hand

9

นอกจากนี้ต้องเป็นห้องสมุดที่ไม่อยู่ที่ไหนสักแห่งที่ซินโดรม

เกี่ยวข้องอย่างใกล้ชิดกับ

ปลั๊กอินเครื่องราง


2
ฉันมักจะพบห้องสมุดที่ "ไม่" ปัญหาของฉันมักทำให้พวกเขาทำงานตามที่โฆษณาไว้ :(
เบ็น L

หาง่ายห้องสมุด - ยากที่จะหาห้องสมุดที่มีการทดสอบหน่วยที่ดีในตัว
burnt_hand

8

ลัทธิพอใจ แต่สิ่งดีเลิศฆ่า อาจเป็นเหตุผลที่ดีที่สุดที่โครงการไม่ประสบความสำเร็จ


ฉันเดาว่าเป็นไปได้ว่านี่เป็นเรื่องจริง แต่ฉันไม่เคยทำโครงการที่ล้มเหลวหรือช้าไปด้วยเหตุนี้
PeterAllenWebb

ขึ้นอยู่กับวิธีที่คุณกำหนดความสมบูรณ์แบบและระดับของความมุ่งมั่นของคุณ
Svish


7

เขียนใหม่แทนการปรับโครงสร้างใหม่


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

1
ในฐานะที่เป็นข้อพิสูจน์ .... เขียนอีกครั้งที่อื่นแทนการแฟอีกครั้ง ฐานรหัสของเรามีการใช้งานที่แตกต่างกันมากมายในสิ่งเดียวกันเป็นไปไม่ได้ที่จะได้รับความสอดคล้องใด ๆ
Newtopian

6

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


5

การทำให้ทุกอย่างเป็นอัตโนมัติเป็นจุดยิ่งใช้เวลากับการดูแลรักษาเครื่องมือมากกว่างานจริง

การแก้ไข: เช่นเดียวกับการเพิ่มประสิทธิภาพรหัสแรกพบคอขวดการผลิตและเฉพาะหลังจากที่พวกเขาจะค้นพบรักษาพวกเขากับบางอัตโนมัติที่ดี


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

4

ปีศาจการเขียนโปรแกรมของคุณคืออะไร?

นอกเหนือจากที่คนอื่นพูดถึง

การจัดลำดับความสำคัญ : ไม่สนใจงานที่มีลำดับความสำคัญสูงเมื่อเทียบกับโครงการและทำงานกับสิ่งอื่น ๆ ในโครงการก่อนเพราะพวกเขาน่าสนใจกว่า!

คุณจะหลีกเลี่ยงพวกเขาได้อย่างไร

ด้วยวินัยในตนเองที่มากขึ้นอีกเล็กน้อย การมีวินัยในตนเองอย่างจริงจังและแรงจูงใจในการทำสิ่งที่ถูกต้องจะช่วยหลีกเลี่ยง "ปีศาจ" เหล่านี้ส่วนใหญ่


3

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

ต่อมาหลังจากที่คุณสร้างโครงการให้ตรงกับ comps ...

โอ้นี่คือการแก้ไขของลูกค้าพวกเขาต้องการเปลี่ยนสิ่งเล็กน้อย *

(* ฟังก์ชั่นหลักแตกต่างอย่างสิ้นเชิง)

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

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


2
ทำตามนโยบายที่คุณไม่ได้เริ่มพัฒนาจนกว่าคุณจะมีลายเซ็นของลูกค้า
เบ็น L

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