จะเป็นผู้เล่นที่ดีได้อย่างไร? [ปิด]

ฉันได้รับการเขียนโปรแกรม (อย่างย่ำแย่) ตั้งแต่ฉันอายุ 12 ปีฉันมีความรู้พอสมควรในภาษาต่าง ๆ ตั้งแต่การประกอบการจนถึง C ++ จาวาสคริปต์จนถึง Haskell Lisp และ Qi แต่ทุกโครงการของฉันเป็นของตัวเอง

ฉันสำเร็จการศึกษาด้านวิศวกรรมเคมีไม่ใช่ CS หรือวิศวกรรมคอมพิวเตอร์ แต่เป็นครั้งแรกที่ฤดูใบไม้ร่วงนี้ฉันจะทำงานในโครงการเขียนโปรแกรมขนาดใหญ่กับคนอื่น ๆ และฉันก็ไม่รู้วิธีเตรียม ฉันใช้ Windows มาตลอดชีวิต แต่โครงการนี้จะเป็นยูนิกซ์มากฉันจึงซื้อ Mac เมื่อไม่นานมานี้โดยหวังว่าจะได้ทำความคุ้นเคยกับสภาพแวดล้อม

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

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

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

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

คำถาม:ขั้นตอนใดบ้างที่ฉันสามารถทำเพื่อเริ่มต้น "รวม" กับคนอื่น ๆ ?

ขอบคุณ!

ฉันคิดว่าคุณมีความกังวลและตื่นเต้นที่ได้ทำงานเป็นกลุ่ม

พวกเราไม่มีใครเรียนรู้การทำงานในกลุ่มหรือทีมจากหนังสือหรือได้รับขั้นตอนทารกหรือ "คู่มือ Dummies เพื่อการทำงานในทีม"

เราเพิ่งเรียนรู้การทำงานกับกลุ่มโดยทำงานในกลุ่ม

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

สำหรับฉันบรรทัดล่างคือ

เป็นส่วนหนึ่งของทีม

ฉันจะเลือกประโยคของคุณและทำประเด็นทั่วไปสองสามข้อ:

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

...

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

...

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

ฉันคิดว่าสิ่งเดียวที่ยิ่งใหญ่ที่สุดที่คุณจะต้องเรียนรู้คือ:

สำหรับมาตรฐานที่กำหนดของความสามารถในการพัฒนาทีมงานของnนักพัฒนาไม่น้อยกว่าnครั้งการทำงานที่หนึ่งในนักพัฒนาสามารถทำคนเดียว - แต่พวกเขาจะยังคงทำมากกว่าคนใดคนหนึ่งจะทำได้

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

สิ่งสำคัญอื่น ๆ คือ:

เพื่อนร่วมงานของคุณบางคนจะมีความสามารถน้อยกว่าคุณอย่างแน่นอนในทักษะบางอย่าง บางคนอาจมีความสามารถน้อยกว่าคุณในทุกทักษะ

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

จริง ๆ ฉันคิดว่าวิธีเดียวที่จะเรียนรู้วิธีการทำงานในทีมคือการทำสิ่งนั้นจริง ๆ แต่หวังว่าข้างต้นจะช่วยให้คุณเตรียมใจ โชคดี!

วิธีที่มีประสิทธิภาพที่สุดคือการเป็นส่วนหนึ่งของทีม

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

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

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

ปลั๊กไร้ยางอาย: คุณยินดีอย่างมากที่นี่ !

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

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

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

ทีมมีต้นกำเนิดมาจากการมีปฏิสัมพันธ์ของบุคคลที่รู้จักกันและกันและพยายามทำความเข้าใจวิธีการทำงานร่วมกันจนกว่าพวกเขาจะพบวิธีการทั่วไป (ดูเช่นขั้นตอนการพัฒนากลุ่มของ Tuckman )

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

ฉันเห็นด้วยกับ ElYusubov ว่าคุณต้องการความอดทนมากมายและให้ตัวเองและเพื่อนร่วมงานใหม่เพื่อเรียนรู้ที่จะทำงานร่วมกันจนกว่าคุณจะเป็นทีม หากคุณฝึกกีฬาเป็นทีมคุณควรมีประสบการณ์นี้มาแล้ว

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

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

การเป็นสมาชิกในทีมที่ดีหมายถึงการสื่อสารอย่างไม่เกรงกลัวไว้วางใจวิทยาลัยของคุณและเอาชนะอุปสรรคในโครงการในฐานะทีมและdeliver project as a team.

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

มันจะเป็นประโยชน์ในการเน้นตัวละครของสมาชิกในทีมที่ดีบางอย่าง

a) สมาชิกในทีมที่ดีคือบุคคลที่มุ่งสู่เป้าหมายแทนที่จะมุ่งเน้นตนเอง

b) คุณสมบัติ:คิดถึงภาพรวมมากกว่าความพึงพอใจในตนเอง นี่คือจุดสำคัญ คุณสมบัติอื่น ๆ ทั้งหมด (เช่นความน่าเชื่อถือการสื่อสารที่สร้างสรรค์) สืบทอดมาจากคุณสมบัตินี้

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

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

คุณเสียเปรียบในเรื่องที่คุณไม่มีการศึกษาด้านการสร้างซอฟต์แวร์ ในการศึกษานั้นมีหลายสิ่งที่สอน (ไม่ใช่แค่วิธีการเขียนโปรแกรม) ซึ่งสำหรับ CS grads และผู้พัฒนาซอฟต์แวร์ที่มีประสบการณ์จะเป็นสิ่งที่สอง ไม่ว่ามันจะเกิดขึ้นบ่อยครั้งในที่ทำงาน (แม้ว่ามันจะทำให้ฉันครั้งเดียว) แต่ NP-hard เป็นตัวอย่างของคำที่พวกเขาอาจเข้าใจและคุณอาจไม่ คุณอาจขาดพื้นฐานในทฤษฎีทางการที่อยู่เบื้องหลังการคำนวณ แต่ก็ไม่เป็นไรตราบใดที่คุณยินดีที่จะเรียนรู้ อาจเป็นปริญญาโทใน CS ในอนาคตของคุณ? ดูเหมือนว่าบางรหัสของคุณอาจเป็นสำนวนในแง่ที่ว่าคุณมีรูปแบบการเขียนโปรแกรมที่ดูเหมือนชัดเจนสำหรับคุณ แต่ไม่ใช่กับคนอื่น ๆ ให้ความสนใจในการตรวจสอบโค้ดและยินดีที่จะยอมรับคำวิจารณ์และเรียนรู้ สิ่งนี้กำลังจะเกิดขึ้นและคุณอาจจะผิดหวัง

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