วิธีการพัฒนาที่ดีที่สุดสำหรับหนึ่งคน?


77

ฉันใช้เวลาทำงานโครงการต่าง ๆ ซึ่งฉันเป็นผู้พัฒนาผู้จัดการโครงการผู้ออกแบบคน QT (ใช่ฉันรู้ ... แย่!) และบางครั้งฉันก็เป็นลูกค้า

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

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


ทดสอบก่อนและคล่องตัวหรือแบบลีนและสำหรับทีมเล็ก XP
ctrl-alt-delor

14
สิ่งหนึ่งที่เราทำคือค้นหา มีคำถามมากมายในหัวข้อนี้ programmers.stackexchange.com/questions/50658/…เป็นต้น ทั้งหมดนี้ programmers.stackexchange.com/search?q=solo+programmer
S.Lott

3
ฉันมักจะพัฒนาความประสงค์ที่ฉันมีนักพัฒนาที่มีความสามารถอื่นอย่างน้อยหนึ่งคนทำงาน
ChaosPandion

ซ้ำเป็นไปได้ของการออกแบบและพัฒนาระเบียบวิธีสำหรับนักพัฒนาเดียว
ริ้น

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

คำตอบ:


28

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

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


2
วิธีการของ TDD ไม่ใช่ "มันเสร็จสิ้นเมื่อใช้งานได้" วิธี TDD คือ "มันทำเมื่อมันทำงานและรหัสที่สะอาด "
เบนจามินฮอดจ์สัน

วิธี TDD คือ "มันทำเมื่อมันทำงานและได้รับการปล่อยตัวออกมา ."
Mike Chamberlain

6
มันเป็นซอฟต์แวร์ มันไม่เคยทำ เมื่อถึงจุดหนึ่งคุณก็หยุดทำงาน แม้ว่าคุณอาจเริ่มต้นใหม่อีกครั้ง
candied_orange

23

ที่นี่คุณไป ... http://xp.c2.com/ExtremeProgrammingForOne.html

XP ลดขนาดลงอย่างเห็นได้ชัดเนื่องจากมันเหมาะสำหรับทีมขนาดเล็กที่มุ่งเน้น ..

  • คุณสามารถสร้างสเปรดชีตของคำขอคุณสมบัติจัดลำดับความสำคัญและเลือกสิ่งที่ดีที่สุดได้
  • กำหนดเกณฑ์การยอมรับ (สิ่งที่ทำไปแล้วดูเหมือน) และรหัสขึ้นสู่การทดสอบที่ปฏิบัติการได้
  • ถัดไปกำหนดงานวิศวกรรมที่จะทำ
  • เขียนการทดสอบหน่วยทำสิ่งที่ง่ายที่สุด (YAGNI) และ refactor ตลอดเวลา เป้าหมายคือการทำแบบทดสอบการยอมรับภายนอก
  • กล่องเวลาแต่ละเซสชัน สำหรับการที่มีประสิทธิภาพในการจัดการเวลาคุณยังสามารถดูเทคนิค Pomodoro
  • ใช้การควบคุมเวอร์ชันและตั้งค่าเซิร์ฟเวอร์ CI / ไฟล์แบตช์เพื่อสร้างการติดตั้งหรือ zip ของซอฟต์แวร์ของคุณ
  • สาธิตบ่อยๆ กำหนดเส้นทางความคิดเห็นลงในสเปรดชีตดั้งเดิมและจัดลำดับความสำคัญใหม่

สิ่งเดียวที่คุณไม่สามารถทำได้ในทีมหนึ่งคือ PairProgramming


16

หากคุณกำลังทำงานเดี่ยว นี่คือคำแนะนำ:

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

13

บทวิจารณ์โค้ด

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

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


7

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


7

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

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


4

ฉันขอแนะนำคุณดังต่อไปนี้:

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

1
คุณจะอธิบายส่วนที่ "เติมรหัสการยืนยันของคุณ" ได้ไหม?
EKanadily

3

ฉันหวังว่าฉันจะบอกว่าฉันสามารถฝึกฝนสิ่งที่ฉันสั่งสอน 100% ของเวลา แต่ BDD ดูเหมือนจะเป็นวิธีที่ดีในสถานการณ์ของคุณ:

นี่คือลิงค์ที่มีข้อมูลเพิ่มเติม: http://en.wikipedia.org/wiki/Behavior_driven_development


2

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


2

ฉันพบว่าการใช้เครื่องมือการจัดรูปแบบโค้ดเช่น ReSharper ช่วยให้มั่นใจได้ว่าอย่างน้อยที่สุดโค้ดนั้นง่ายต่อการรับสำหรับนักพัฒนาซอฟต์แวร์รายอื่น

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


2

ปรัชญา: XP / TDD + GTD

ร่างทั่วไป:

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

ฉันเห็นด้วยกับสิ่งเหล่านี้และฉันดีใจมากที่เห็นว่าเป็นคำตอบแรก แต่ด้วยทีมงาน 1 คนฉันคิดว่าการจัดตารางเวลาแบบ Kanban นั้นดีกว่า (และง่ายยิ่งขึ้น) กว่าการทำซ้ำ
William Pietri

@ William ถ้าลูกค้าเข้าใจ kanban หรือไม่มีลูกค้าไปเลย
Steven A. Lowe

1

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

บางทีอาจจะน่าสนใจกว่าคือถามว่าวิธีการใดที่จะไม่ทิ้งเพราะมีเพียง 1 คนที่ทำงานในโครงการ

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

อย่างแดกดันฉันพบว่าโซลูชันการควบคุมเวอร์ชันแจกจ่ายเช่น GIT นั้นดีกว่าสำหรับบุคคลที่มีบางอย่างเช่น SVN


0

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

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


0

เปรียว

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

นอกจากนี้ยังง่ายต่อการส่งงานระหว่างการทำซ้ำ


0

ในฐานะที่ปรึกษาของฉันฉันขอแนะนำให้คุณหาวิธีที่จะมีนักพัฒนาอย่างน้อยสองคนในการมอบหมายใด ๆ

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


0

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

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