See the original English version of this article here
บทความนี้เป็นการแชร์มุมมองส่วนตัวของคุณ Doug Foo ซึ่งเมื่อ 20 ปีที่แล้ว เขาเป็นผู้เชี่ยวชาญด้าน Technology จากนั้นเขาก็ได้ทำงานบริหารประมาณ 10 ปี จนล่าสุดได้มีโอกาสกลับทำหน้าที่ Consultant อีกครั้ง ซึ่งการเปลี่ยนแปลงนี้ทำให้ทั้งตัวเขาและคนรอบข้างรู้สึกประหลาดใจ และนี่คือ สิ่งที่ได้เรียนรู้ จากการกลับมา Coding หลังจากผ่านมา 10 ปี
1. Unix กลับมามีบทบาทกับ Developer มากขึ้น
ในช่วงยุค 80 และต้นยุค 90 มี Software จำนวนมากที่ได้รับการพัฒนาบน Unix Workstations ที่มีราคาสูง อย่าง Sun Sparc หรือ NeXT Station จากนั้นในยุค 90 WinTel ก็ได้เข้ามาแทนที่และทุกคนก็เขียน Code บน Windows ด้วย Tools อย่าง MS Visual Studio ในขณะที่ Linux ยังคงถูกใช้งานบน Desktop อยู่บ้าง
คุณ Doug เริ่มต้นทำงานในปี 2001 และเป็น Developer เพียงคนเดียวในที่ทำงานที่ใช้ Linux และต้องดิ้นรนอย่างมากเนื่องจากไม่สามารถเข้าถึง Source Code Management (SCM) Tools และ Outlook Email ได้ เขาจำได้ว่าเวลาจะให้ดู Code กันก็ต้องส่งผ่าน Email แถมในตอนนั้นคุณ Doug ก็ใช้ XEmacs ด้วยซึ่งถือว่ามันอะไรที่ Classic มาก
จนถึงตอนนี้ Unix ได้กลายเป็น Dev Platform ได้รับความนิยมมากขึ้นโดยเฉพาะบน Mac และ Linux บน Windows ก็ยังคงมีอยู่เช่นกัน (WSL) นี่คงเป็นส่วนที่ง่ายสำหรับเขาที่จะกลับมา Coding อีกครั้ง มันมีเรื่องน่าตลกที่เพื่อนรุ่นน้องบางคนของเขา แทบจะไม่รู้วิธีใช้ Windows แต่กลับใช้งาน Linux / Unix ได้เป็นอย่างดี
2. ไม่จำเป็นต้องมี Release Managers อีกแล้ว
ย้อนกลับไปในยุคก่อนหน้านี้ Branching, Merging และการแก้ปัญหา Conflicts ดูจะเป็นงานที่น่ากลัว ซึ่งบางกรณีก็ต้องอาศัยความเชี่ยวชาญของ Release Manager ด้วย ย้อนกลับไปช่วงที่ SCM ClearCase เป็นที่นิยม มันต้องใช้ทีมงานจำนวนมากในการ Maintain และจัดการเรื่อง Branching, Merging และ Releases (อย่างน้อยก็จากประสบการณ์ที่ทำงานที่ HP ในปี 2002)
แนวคิดของ Self-Managed Pull Request (PR) นั้นค่อนข้างใหม่และเห็นได้ชัดว่ามาจาก Linux dev และคลื่นลูกใหม่ของ Distributed SCMs อย่าง BitKeeper และ Git ความสามารถในการสร้าง Request เพื่อ Merge ใน Workflow ถือเป็นสิ่งที่ไม่มีอยู่ใน System รุ่นเก่าอย่าง ClearCase, CVS, SVN และ PerForce คุณมี Repo Owner หรือ Release Manager ที่สามารถทำสิ่งนี้ได้ หรือไม่ Developer แต่ละคนก็ทำได้ด้วยตัวเอง สิ่งนี้ช่วยให้ Users สามารถทำงานร่วมกันได้อย่างคล่องตัวและมีประสิทธิภาพมากขึ้น
3. ทีม QA อยู่ที่ไหน? (Unit Testing/CI)
คุณ Doug ได้เรียนรู้เกี่ยวกับ Unit Testing และ Continuous Integration (CI) ครั้งแรกผ่านทาง Kent Beck ซึ่งเป็นหนึ่งในผู้ก่อตั้ง Agile Manifesto และผู้สร้าง Extreme Programming มันเป็นการเปลี่ยนแปลงครั้งสำคัญเมื่อ 20 ปีที่แล้ว และต้องใช้เวลาพอสมควรเพื่อให้บรรลุมาตรฐาน Dev Workflow ในปัจจุบัน ซึ่งเขาพบว่าโชคไม่ดีนักที่ CI ไม่ได้ถูกให้ความสำคัญใน Agile และ Scrum มากนัก แต่ CI ก็ได้รับการยอมรับเป็นอย่างดีในตอนนี้
คุณ Doug จำได้ว่า เขาเคยเข้าร่วมใน Software Development Conference และได้เห็น Josh Bloch (ซึ่งเป็นผู้สร้าง Java Collections) บนเวที โดย Josh ได้กล่าวว่า “ต้องขอบคุณ (Agile หรือ JUnit) ที่ทำให้การ Testing น่าสนใจมากขึ้น”
มันเป็นเรื่องจริงที่ในสมัยก่อน การเขียน Tests เป็นเรื่องที่น่าเบื่อและไม่เป็นที่นิยม ดังนั้น บริษัทจึงจ้าง QA Engineers เข้ามาเพื่อค้นหาข้อผิดพลาดทั้งหมดให้กับคุณ
Unit Testing และ CI แทบจะขจัดความจำเป็นในการมี QA Testers เนื่องจาก Developer ก็สามารถเขียน Tests ได้และ CI Infrastructure ก็สามารถ Run และรายงานผลการ Tests ได้ มันทำให้ Software มีความน่าเชื่อถือมากขึ้นและ Dev Cycle ก็เร็วขึ้น นอกจากนี้ยังทำให้ Programmer สามารถคิดแบบองค์รวมได้มากขึ้นและเขียน Code ในรูปแบบที่เป็นมิตรต่อการ Test ได้ดีขึ้น
4. Dev->Test->Prod Issues No More? (Docker)
Containers หรือที่ถูกเรียกว่า Docker มีการ Packaging ที่คล่องตัวและมีประสิทธิภาพ รวมทั้งช่วยลดปัญหาเกี่ยวกับ Environment ในขณะที่คุณย้าย Code ผ่าน QA ไปสู่ Production (แต่อาจต้องแลกกับการมี DevOps Engineer ที่มาช่วย Set up Docker Ecosystem)
ในสมัยก่อน คุณอาจจะต้อง Develop ใน System ที่แตกต่างจาก System ที่มันถูก Deploy (เช่น Code บน Windows แต่ไป Deploy ที่ Unix) ซึ่งสิ่งนี้อาจทำให้เกิด Bugs และอาจต้องทำงานมากขึ้นในการ Test และ Release Cycle
ก่อนหน้านี้ Release, QA หรือ DevOps Engineer จะเป็นคนนำ Code จาก SCM tag แล้วหาวิธี Compile, Test, และ Migrate ซึ่งมักจะพบว่า ไม่ครอบคลุม Hardcoded Paths และ Variables ทั้งหมด หรือมีบาง Libraries และ Files ที่ขาดหายตกหล่นไป ทำให้ต้องมีการทำซ้ำใหม่หรือตัดบางส่วนออกไปเพื่อให้สามารถใช้งานได้
Docker เองได้มีการปรับปรุง Process ให้มีประสิทธิภาพมากขึ้นและอนุญาตให้ใช้ทั้ง CI และ Continuous Deployment (CD) ได้ด้วยการเพิ่มขีดความสามารถให้ Programmer ในการ Build และ Test ด้วยตัวพวกเขาเอง
5. มีตัวเลือกมากเกินไปสำหรับ Open Source Software (OSS) หรือไม่?
ทุกวันนี้ เราจะพบว่ามีตัวเลือกมากมายในโลกของ OSS ก่อนหน้านี้คุณ Doug เคย Set up Jenkins และต้องการ Integrate กับ BitBucket และเมื่อค้นหา “bitbucket” คุณจะได้พบกับตัวเลือกมากกว่า 400 ตัวเลือก (นั่นหมายถึงมี Open Source อยู่เป็นจำนวนมาก)
Source: Atlassian Search Ref
สิ่งนี้ได้สร้างปัญหา 2 เรื่องคือ:
มีตัวเลือกในปริมาณที่มากเกินไป
ด้วยตัวเลือกมากมายขนาดนี้ อาจทำให้บาง Open Source ไม่ได้ไปต่อ และไม่ได้รับการ Support
แต่ส่วนที่ดีคือคุณแทบจะไม่จำเป็นต้องสร้าง Infrastructure และ Tools ขั้นพื้นฐาน – คุณแค่ต้องหาสิ่งที่เหมาะสมเพื่อนำมา Reuse
เมื่อ 20 ปีที่แล้ว การสร้าง Libraries และ Data Structures ดูเหมือนจะเป็นเรื่อง “น่าสนุก” แต่ปัจจุบันมี Frameworks และ Libraries ในแทบจะทุกภาษา ซึ่ง 99% ของ Developer ไม่ต้องเขียน b-tree, hashmap หรือแม้แต่ OAUTH Connector
6. Agile และ Scrum เข้ามามีบทบาทอย่างมาก
ในขณะที่ Agile เกิดขึ้นมาเมื่อ 20 ปีที่แล้ว มันได้รับการยอมรับอย่างกว้างขวางในปัจจุบัน มันกลายเป็นสิ่งที่ได้รับความสำคัญสำหรับองค์กรไปแล้ว (“Business ของคุณต้องใช้ Agile เพื่อความอยู่รอด”)
คุณ Doug จำได้ว่าเคยมี Release Cycles ที่ค่อนข้างยาวนาน (นานถึง 3 เดือนตั้งแต่เริ่มต้น) หลังจากเข้าร่วม Meetings เพื่อทำความเข้าใจ Requirements อย่างละเอียด จากนั้น Developer สามารถไปที่โต๊ะทำงานและเล่นเกมได้ 2-3 สัปดาห์โดยไม่ต้องกังวลกับปัญหาต่าง ๆ ในช่วงนั้นเลย แต่เทียบกับปัจจุบัน คุณมีประชุมแทบจะทุกวันและ Sprint ทุก 2 สัปดาห์ ดังนั้น คุณจึงไม่สามารถย่อหย่อนในการทำงานได้อีกต่อไป
บทบาทของ BA ก็ลดน้อยลงเพราะ Agile เนื่องจากตอนนี้ Developer ต้องเจอต้องพูดคุยกับ Users หรือ Product Managers โดยตรงมากขึ้น คุณไม่สามารถหลบซ่อนสิ่งเหล่านี้ได้ ดังนั้น ทักษะการสื่อสารจึงมีความสำคัญมากกว่าในอดีตมาก
Quote from the Tom, the BA/Manager—Source: Office Space
Agile ทำให้การ Develop รวดเร็วขึ้นมาก มันไม่ใช่แค่ Scrum เป็นกิจวัตรและการประชุมกันทุกวันเท่านั้น Tools ก็มีประสิทธิภาพมากขึ้นทั้ง JIRA Boards, Pull Requests และ CI/CD ซึ่งทั้งหมดนี้ช่วยให้คุณทำงานได้เร็วขึ้นทั้งสิ้น แม้ว่าคุณจะกำลังยุ่งอยู่กับงานประจำวัน แต่ก็เป็นเรื่องน่ายินดีที่จะได้สร้างสิ่งต่าง ๆ ได้เร็วขึ้นและมีความสมบูรณ์มากขึ้น
สรุป
ประเด็นหนึ่งที่คุณอาจรู้สึกได้ในบทความนี้ก็คือ Developer ในปัจจุบันมีงานที่ต้องทำมากกว่าสมัยก่อน พวกเขาทั้งเขียน Code, จัดการ SCM, พูดคุยกับ User, Test Code, Build และ Deploy Containers เป็นต้น มันอาจเป็นเรื่องที่ยากจะทำความเข้าใจ แต่ Developer ก็ต้องมีการปรับตัวไปตามยุคสมัย
ISM Technology Recruitment Ltd. (#1 Tech Recruiter in Thailand) เราเชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ เปิดทำการมา 30 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย
หากคุณเป็นคน IT ที่อยากทำงานท้าทายและร่วมงานกับองค์กรชั้นนำ สามารถฝากประวัติการทำงาน (Resume) ของคุณไว้กับ ISM ได้ที่ https://www.ismtech.net/submit-your-resume แล้วคุณจะพบว่าอนาคตและโอกาสก้าวหน้ากำลังรอคุณอยู่
Source: https://betterprogramming.pub/