วิศวกรรมซอฟต์แวร์

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

53 tdd 

เราทดสอบรหัสของเราเพื่อให้ถูกต้องมากขึ้น (จริง ๆ แล้วมีโอกาสน้อยที่จะไม่ถูกต้อง ) อย่างไรก็ตามการทดสอบนั้นก็เป็นรหัส - พวกเขายังสามารถมีข้อผิดพลาด และหากการทดสอบของคุณมีข้อบกพร่องพวกเขาแทบจะไม่ทำให้โค้ดของคุณดีขึ้น ฉันสามารถคิดถึงข้อผิดพลาดสามประเภทที่เป็นไปได้ในการทดสอบ: ข้อผิดพลาดเชิงตรรกะเมื่อโปรแกรมเมอร์เข้าใจผิดงานในมือและการทดสอบทำในสิ่งที่เขาคิดว่าพวกเขาควรทำซึ่งผิด ข้อผิดพลาดในกรอบการทดสอบพื้นฐาน (เช่น. การเยาะเย้ยสิ่งที่เป็นนามธรรม); ข้อบกพร่องในการทดสอบ: การทดสอบทำแตกต่างจากที่โปรแกรมเมอร์คิดไว้เล็กน้อย ข้อผิดพลาดประเภท (1) ดูเหมือนว่าเป็นไปไม่ได้ที่จะป้องกัน (เว้นแต่ว่าโปรแกรมเมอร์เพิ่ง ... ฉลาดขึ้น) อย่างไรก็ตาม (2) และ (3) อาจถูกเวไนยได้ คุณจัดการกับข้อผิดพลาดประเภทนี้อย่างไร คุณมีกลยุทธ์พิเศษเพื่อหลีกเลี่ยงพวกเขาหรือไม่? ตัวอย่างเช่นคุณเขียนการทดสอบแบบ "ว่างเปล่า" เป็นพิเศษหรือไม่ซึ่งเป็นการตรวจสอบเพียงข้อสันนิษฐานของผู้เขียนทดสอบเท่านั้น นอกจากนี้คุณจะแก้ไขข้อบกพร่องในกรณีทดสอบอย่างไร

53 unit-testing  tdd  debugging 

เมื่อเร็ว ๆ นี้เรามีปัญหาซึ่งคุณสมบัติสำหรับ webapp ของเรา (การลงทะเบียนอัตโนมัติ) ถูกเลื่อนออกไปโดยผู้บริหารเพราะพวกเขารู้สึกว่าการเริ่มต้นนั้น "หนาว" เกินไป แต่พวกเขาต้องการคุณสมบัติอื่น ๆ ทั้งหมดที่เรากำลังทำอยู่ ปัญหาคือฟังก์ชั่นนี้ได้รับการผสานเข้ากับการพัฒนาเมื่อเสร็จสิ้นพร้อมกับคุณสมบัติอื่น ๆ ทั้งหมดที่เราคาดว่าจะมีการถ่ายทอดสดในรุ่นถัดไปดังนั้นเราจึงไม่สามารถผสาน dev -> test -> master เหมือนที่เราทำ เราจะหลีกเลี่ยงปัญหานี้ได้อย่างไร?

53 project-management  git  gitflow 

มาจากพื้นหลังส่วนใหญ่ c # ฉันเคยใช้คำว่า "อินเตอร์เฟส" สำหรับการอธิบายวัตถุที่ไม่มีการใช้งานที่กำหนดพฤติกรรม ใน c # การประชุมคือการเพิ่มชื่อส่วนต่อประสานด้วย "I" เช่นในIEnumerableเป็นต้น แน่นอนว่าแนวคิดนี้มีชื่อแตกต่างกันในภาษาต่างๆ ใน Swift แนวคิดเดียวกันนี้เรียกว่า "โปรโตคอล" เมื่อฉันพัฒนาโปรโตคอลฉันมักจะมีชื่อคล้ายกันมากสำหรับโปรโตคอลและคลาสที่ใช้งานมัน จนถึงตอนนี้ฉันได้ต่อท้ายคำว่า "โปรโตคอล" กับวัตถุเหล่านี้ในลักษณะเดียวกับที่ฉันใช้ "I" ใน c #, ในEnumerableProtocol, ฯลฯ มีความคิดเห็นเกี่ยวกับการตั้งชื่อโปรโตคอลสำหรับโพรโทคอลอย่างรวดเร็วหรือไม่?

53 naming-standards  swift-language 

สมมติว่าฉันมีฟังก์ชั่นที่ทำงานกับไฟล์ข้อความตัวอย่างเช่นอ่านจากมันและลบคำว่า 'a' ฉันสามารถผ่านชื่อไฟล์และจัดการเปิด / ปิดในฟังก์ชั่นหรือฉันจะผ่านมันไฟล์ที่เปิดอยู่และคาดหวังว่าใครก็ตามที่เรียกมันจะจัดการกับการปิดมัน วิธีแรกดูเหมือนจะเป็นวิธีที่ดีกว่าในการรับประกันว่าไม่มีไฟล์ใดถูกเปิดทิ้งไว้ แต่ป้องกันไม่ให้ฉันใช้สิ่งต่าง ๆ เช่นวัตถุ StringIO วิธีที่สองอาจเป็นอันตรายเล็กน้อย - ไม่มีทางรู้ว่าไฟล์จะถูกปิดหรือไม่ แต่ฉันจะสามารถใช้วัตถุเหมือนไฟล์ def ver_1(filename): with open(filename, 'r') as f: return do_stuff(f) def ver_2(open_file): return do_stuff(open_file) print ver_1('my_file.txt') with open('my_file.txt', 'r') as f: print ver_2(f) เป็นที่ต้องการโดยทั่วไปหรือไม่ โดยทั่วไปแล้วคาดว่าฟังก์ชั่นจะทำงานในหนึ่งในสองวิธีนี้หรือไม่? หรือควรมีการบันทึกไว้อย่างดีเพื่อให้โปรแกรมเมอร์สามารถใช้ฟังก์ชั่นได้ตามความเหมาะสม?

53 python  file-handling 

ฉันเพิ่งเข้าใจแลมบ์ดานิพจน์ที่นำมาใช้ในจาวา 8 ฉันพบว่าเมื่อใดก็ตามที่ฉันใช้อินเตอร์เฟซที่ใช้งานได้ฉันมักจะใช้นิพจน์แลมบ์ดาแทนการสร้างคลาสที่ใช้อินเทอร์เฟซ นี่ถือว่าเป็นการปฏิบัติที่ดีหรือไม่? หรือสถานการณ์ของพวกเขาที่ใช้แลมบ์ดาสำหรับอินเทอร์เฟซการใช้งานไม่เหมาะสมหรือไม่

52 java  lambda 

Java / ทำไมต้องมีvoidวิธีการ? เอกสารอ้างอิง : วิธีการใด ๆ ที่ประกาศเป็นโมฆะจะไม่ส่งคืนค่า เท่าที่ผมสามารถคิดว่าการใช้งานของทุกคนจะได้รับการบริการที่ดีขึ้นโดยการกลับธงสถานะวัตถุที่ถูกเรียกหรือvoidnull สิ่งนี้จะทำให้การเรียกใช้คำสั่งที่กำหนดได้และจะช่วยให้รูปแบบการสร้างและวิธีการผูกมัด วิธีการที่ถูกเรียกใช้เฉพาะกับเอฟเฟกต์ของพวกเขามักจะส่งคืนบูลีนหรือSuccessประเภททั่วไปหรือส่งข้อยกเว้นเมื่อล้มเหลว

52 java  programming-languages  return-type 

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

52 history  unix  process  pipelining 

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

52 c++  c  garbage-collection 

ฉันสงสัยว่ามีข้อดีและข้อเสียต่อสไตล์นี้หรือไม่: private void LoadMaterial(string name) { if (_Materials.ContainsKey(name)) { throw new ArgumentException("The material named " + name + " has already been loaded."); } _Materials.Add( name, Resources.Load(string.Format("Materials/{0}", name)) as Material ); } วิธีการนั้นควรnameจะเรียกใช้เพียงครั้งเดียวเท่านั้น จะโยนยกเว้นถ้ามันจะถูกเรียกว่าหลายครั้งเหมือนกัน_Materials.Add() nameผลที่ตามมาคือการป้องกันซ้ำซ้อนอย่างสมบูรณ์หรือมีประโยชน์ที่เห็นได้ชัดน้อยลงหรือไม่? นั่นคือ C #, Unity หากใครสนใจ

52 exceptions 

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

52 refactoring  code-reviews  clean-code  code-smell 

ฉันมีโครงการแล้ว ในโครงการนี้ฉันต้องการ refactor เพื่อเพิ่มคุณสมบัติและฉัน refactored โครงการเพื่อเพิ่มคุณสมบัติ ปัญหาคือเมื่อฉันเสร็จแล้วมันกลับกลายเป็นว่าฉันต้องการที่จะทำการเปลี่ยนแปลงอินเตอร์เฟซเล็กน้อยเพื่อรองรับมัน ดังนั้นฉันจึงทำการเปลี่ยนแปลง จากนั้นคลาสการบริโภคไม่สามารถนำไปใช้กับอินเทอร์เฟซปัจจุบันในแง่ของอินเทอร์เฟซใหม่ดังนั้นมันจึงต้องการอินเทอร์เฟซใหม่เช่นกัน ตอนนี้สามเดือนต่อมาและฉันต้องแก้ไขปัญหาที่ไม่เกี่ยวข้องอย่างมากมายนับไม่ถ้วนและฉันกำลังมองหาการแก้ปัญหาที่ถูกทำแผนที่สำหรับหนึ่งปีต่อจากนี้ อีกครั้ง ฉันจะหลีกเลี่ยงการปรับลดประเภทของการเรียงซ้อนในอนาคตได้อย่างไร มันเป็นแค่อาการของชั้นเรียนก่อนหน้าของฉันซึ่งขึ้นอยู่กับแต่ละคนแน่นเกินไปหรือไม่? การแก้ไขสั้น ๆ : ในกรณีนี้ refactor เป็นคุณลักษณะเนื่องจาก refactor เพิ่มความสามารถในการขยายของโค้ดบางส่วนและลดการเชื่อมต่อบางส่วน นั่นหมายความว่าผู้พัฒนาภายนอกสามารถทำอะไรได้มากกว่าซึ่งเป็นคุณลักษณะที่ฉันต้องการนำเสนอ ดังนั้นตัวปรับเปลี่ยนดั้งเดิมเองไม่ควรเปลี่ยนฟังก์ชัน แก้ไขที่ใหญ่กว่าที่ฉันสัญญาห้าวันที่ผ่านมา: ก่อนที่ฉันจะเริ่ม refactor นี้ฉันมีระบบที่ฉันมีอินเทอร์เฟซ แต่ในการนำไปใช้นั้นฉันเพิ่งdynamic_castผ่านการใช้งานที่เป็นไปได้ทั้งหมดที่ฉันจัดส่ง เห็นได้ชัดว่านั่นหมายความว่าคุณไม่สามารถสืบทอดจากอินเทอร์เฟซสำหรับสิ่งใดสิ่งหนึ่งและอย่างที่สองว่ามันจะเป็นไปไม่ได้สำหรับทุกคนที่ไม่มีการเข้าถึงเพื่อใช้งานอินเทอร์เฟซนี้ ดังนั้นฉันตัดสินใจว่าฉันต้องการแก้ไขปัญหานี้และเปิดอินเทอร์เฟซสำหรับการบริโภคสาธารณะเพื่อให้ทุกคนสามารถใช้งานได้และการใช้อินเทอร์เฟซนั้นเป็นสัญญาทั้งหมดที่จำเป็นต้องมี - การปรับปรุงอย่างชัดเจน เมื่อฉันค้นหาและฆ่าด้วยไฟในทุกสถานที่ที่ฉันได้ทำสิ่งนี้ฉันพบที่เดียวที่พิสูจน์แล้วว่าเป็นปัญหาเฉพาะ มันขึ้นอยู่กับรายละเอียดการใช้งานของคลาสที่ได้รับมาทั้งหมดและฟังก์ชั่นการทำซ้ำที่มีการใช้งานแล้ว แต่ดีกว่าที่อื่น มันอาจถูกนำมาใช้ในแง่ของอินเทอร์เฟซสาธารณะแทนและนำมาใช้ใหม่การใช้งานที่มีอยู่ของฟังก์ชั่นนั้น ฉันค้นพบว่ามันจำเป็นต้องใช้บริบทบางอย่างในการทำงานอย่างถูกต้อง พูดโดยประมาณการเรียกใช้งานก่อนหน้านี้ดูเหมือนจะเป็นไปได้ for(auto&& a : as) { f(a); } อย่างไรก็ตามเพื่อให้ได้บริบทนี้ฉันต้องเปลี่ยนมันเป็นอะไรที่มากกว่า std::vector<Context> contexts; for(auto&& a …

52 design  programming-practices  refactoring  coupling 

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

52 c++  garbage-collection 

มีข้อโต้แย้งอย่างต่อเนื่องของการทดลองใช้ฟรีกับรุ่น freemium (นั่นคือเวอร์ชันฟรีสำหรับอายุการใช้งานของซอฟต์แวร์ที่มีข้อ จำกัด และ / หรือถอดคุณสมบัติ) สำหรับการอนุญาตให้ลูกค้าและผู้ใช้ทดสอบผลิตภัณฑ์ของตน จากการวิจัยของฉันฉันสามารถสรุปได้ว่าการทดลองใช้ฟรีเป็นวิธีที่จะดำเนินการทั้งสองเพื่อประโยชน์ของประสบการณ์การใช้งานของผู้ใช้แต่ละคนโดยใช้ซอฟต์แวร์และเพื่อประโยชน์ของผู้ขายทั้งในด้านการขายและการใช้งานสูงสุด มีหลายปัจจัยสำหรับซอฟต์แวร์ทดลองใช้ฟรีที่สามารถเพิ่มการใช้งานของผู้ใช้ได้อย่างมากเช่นระยะเวลาทดลองใช้ฟรี คำหลักหนึ่งที่เกี่ยวกับการวิจัยของฉันสำหรับ "freemium" คือ "น่าผิดหวัง" บุคคลหลายคนเลือกที่จะถอนการติดตั้งซอฟต์แวร์แทนที่จะต้องใช้ชิ้นส่วนของซอฟต์แวร์ที่คุณสมบัติบางอย่างไม่สามารถใช้งานได้ ในเวลาเดียวกันผู้ใช้เหล่านี้ไม่เคยมีโอกาสใช้คุณลักษณะ "ชำระแล้ว" ไม่รู้จักกับพวกเขาและซ่อนตัวโดยผู้จำหน่ายของตัวเองที่ขายซอฟต์แวร์พวกเขาไม่รู้และไม่สามารถรู้ได้ว่าคุณสมบัติของ Pro จะให้ประโยชน์อะไรบ้าง ผู้ใช้จะไม่ทราบว่าพวกเขามีความรู้สึกว่า "ต้องการ" อะไรบางอย่าง ซึ่งนำฉันไปสู่จุดต่อไปของรุ่นทดลองใช้ฟรี ความคิดเห็นบางส่วนของผู้ใช้ทดลองใช้ฟรีคือ "ฉันไม่สามารถจินตนาการถึงการใช้ซอฟต์แวร์นี้หากไม่มีคุณสมบัติ Pro" สิ่งนี้กลับไปที่จุด "ผู้ใช้ที่ไม่รู้ว่าต้องการบางสิ่งจนกว่าพวกเขาจะเข้าใจความรู้สึกเป็นครั้งแรก" ผู้ที่มีเวลา 14 วันในการใช้คุณสมบัติ "เต็มรูปแบบ" กล่าวว่าพวกเขาไม่สามารถจินตนาการได้ว่าไม่มีหรือใช้คุณสมบัติที่มีให้ ดังนั้นเมื่อเวลาผ่านไปสิบสี่วันพวกเขามีแนวโน้มที่จะลบล้างเงินได้มากกว่าคนที่ไม่เคยมีคุณสมบัติเต็มรูปแบบ ความยาวของการทดลองใช้ฟรีเป็นปัจจัยสำคัญที่ทำให้ผู้ใช้ประทับใจ ในการทดสอบที่ดำเนินการโดยเครื่องมือเพิ่มประสิทธิภาพเว็บไซต์ Visual พวกเขาสังเกตเห็นว่าการทดลองใช้ฟรี 14 วันเทียบกับการทดลองใช้ฟรี 30 วันในขณะที่จำนวนการสมัครใช้งานและการติดตั้งเท่ากันการใช้งานสำหรับการทดลองใช้ 14 วันเพิ่มขึ้น 102% อีกจุดสำคัญที่พูดถึงคือ "การนำเสนอผลิตภัณฑ์รุ่นฟรีที่มีประโยชน์และใช้งานได้อย่างสมบูรณ์" นั้นสำคัญมาก การทดลองใช้ฟรีที่ใช้งานได้อย่างสมบูรณ์มีประสิทธิภาพในการรับความคุ้มครองสื่อและการประชาสัมพันธ์สำหรับผู้จำหน่ายซอฟต์แวร์รายใหม่และ …

52 software  development 

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

52 skills  solo-development