การนัดหมายที่ 9: ทำไมเราจึงทิ้งรหัสที่ใช้เวลาสร้างถึง 9 ปี
เผยแพร่แล้ว: 2017-02-17บล็อกนี้เกี่ยวกับสาเหตุและวิธีที่เราสามารถลบโค้ดอายุ 9 ปีของเราทิ้ง และเริ่มคิดใหม่
บทที่หนึ่ง: การนัดหมายในการสร้าง
ระหว่างปี 2547 ถึง 2549 เราเคยพัฒนาเว็บไซต์บน WordPress สำหรับอุตสาหกรรมด้านสุขภาพและความเป็นอยู่ที่ดี มีปลั๊กอิน WordPress สำหรับทุกความต้องการ – ยกเว้นปลั๊กอินการตั้งเวลา เราได้รับคำขอมากมายสำหรับปลั๊กอินการตั้งเวลาซึ่งเราไม่สามารถติดตามได้!
ดังนั้นเราจึงเขียนสคริปต์ของเราเอง สคริปต์ที่จะช่วยให้เราประหยัดเวลาโดยไม่ต้องสร้างโค้ดเดิมซ้ำแล้วซ้ำอีก หนึ่งในความท้าทายแรกที่เราเผชิญคือธุรกิจทุกประเภทมีข้อกำหนดเฉพาะ ดังนั้นเราจึงสร้างกฎการตั้งเวลาเพื่อสรุปสคริปต์ของเราสำหรับประเภทธุรกิจต่างๆ
ในไม่ช้าความต้องการในการจัดตารางเวลาก็เพิ่มขึ้น และ Appointy ก็ เปิดตัวครั้งแรก ในเดือนมกราคม 2008 ด้วยแนวคิด "Do it Yourself"
น่าเสียดายที่ความกระตือรือร้นของเราที่จะเอาใจลูกค้าทุกคน เราได้เพิ่มคุณสมบัติอย่างต่อเนื่องและการนัดหมายก็ล้นหลาม แล้วลูกค้ากลุ่มเดียวกันก็เริ่มบ่น เราตระหนักว่าเรากำลังก้าวออกจากแนวคิด Do-it-Yourself ดังนั้นเราจึงกลับไปที่กระดานวาดภาพด้วยแนวคิดที่จะทำให้มันง่ายขึ้นอีกครั้งโดยที่ยังคงฟังก์ชั่นการใช้งานไว้
เราเสียค่าใช้จ่ายหนึ่งปีเต็ม แต่เราได้เรียนรู้บทเรียนสำคัญ
Appointy เป็นบริษัทที่มีการบูทสแตรป (ไม่เคยระดมทุนจากภายนอกเลย) และต้องสร้างรายได้จากลูกค้าเพื่อให้อยู่รอด เราเชื่อว่าวิธีที่ดีที่สุดในการทำเงินคือการแก้ปัญหาของใครบางคนก่อนแล้วจึงขอราคาที่ยุติธรรม ยิ่งเราช่วยเหลือลูกค้าได้มากเท่าไหร่ เราจะยิ่งเติบโตมากขึ้นเท่านั้น
เราเริ่มปรับปรุงกระบวนการปฐมนิเทศและการสนับสนุนของเรา แต่ในไม่ช้า เราก็ตระหนักว่าทุกธุรกิจมีลักษณะเฉพาะตัวและต้องการสิ่งที่แตกต่างออกไป หมายความว่าเราไม่เพียงแต่ต้องเพิ่มในทีมสนับสนุนเท่านั้น แต่ยังต้องเพิ่มโปรแกรมเมอร์อีกด้วย เราต้องการวิธีการปรับขนาดในแนวตั้งในทุกแผนก
เราเริ่มจ้างโปรแกรมเมอร์เพิ่มขึ้น ไม่กี่เดือนต่อมา ระหว่างการประชุม scrum สมาชิกในทีมใหม่แบ่งปันว่าเขามีความสุขที่บางสิ่งที่เขาเขียนได้เผยแพร่บนไซต์การผลิตของเรา สำหรับเขา มันเป็นความสำเร็จอย่างแน่นอน อย่างไรก็ตาม ฉันไม่มีความสุข ฉันตระหนักว่ามีบางอย่างผิดปกติในการตั้งค่าของเรา หากต้องใช้เวลาหลายเดือนกว่าที่โปรแกรมเมอร์ใหม่จะทำงานได้อย่างมีประสิทธิภาพ
ถึงเวลาแล้วที่จะต้องออกจากความสบายใจและตัดสินใจอย่างกล้าหาญ เราไม่สามารถปรับขนาดได้เร็วเท่าที่เราต้องการในอัตรานี้!
บทที่ 2: การตัดสินใจที่ยากแต่ยิ่งใหญ่
วันรุ่งขึ้น ฉันคุยกับรุ่นพี่สองสามคนและพยายามเข้าใจปัญหา ปัญหาเกิดขึ้นที่สถาปัตยกรรมที่เราสร้างขึ้นเมื่อ 9 ปีที่แล้ว เทคโนโลยีมีการเปลี่ยนแปลงทุกปี และในทางเทคนิคแล้ว เราตามหลังมาเกือบ 9 ปี
แนะนำสำหรับคุณ:
Metaverse จะพลิกโฉมอุตสาหกรรมยานยนต์อินเดียได้อย่างไร
บทบัญญัติต่อต้านการแสวงหากำไรสำหรับสตาร์ทอัพในอินเดียมีความหมายอย่างไร?
Edtech Startups ช่วยให้แรงงานอินเดียเพิ่มพูนทักษะและเตรียมพร้อมสู่อนาคตได้อย่างไร...
หุ้นเทคโนโลยียุคใหม่ในสัปดาห์นี้: ปัญหาของ Zomato ยังคงดำเนินต่อไป, EaseMyTrip Posts Stro...
สตาร์ทอัพอินเดียใช้ทางลัดในการไล่ล่าหาทุน
แพลตฟอร์มการตลาดดิจิทัล Logicserve ระดมทุน INR 80 Cr รีแบรนด์เป็น LS Dig...
ฉันไม่รู้จะบอกทีมของฉันอย่างไรให้เปลี่ยนรหัสทั้งหมดที่พวกเขาเขียนมาเป็นเวลา 9 ปี ฉันไม่ต้องการที่จะดูบ้าและตัดสินใจที่จะกระโดดด้วยตัวเองก่อน ท้ายที่สุด ฉันเองก็เคยเป็นโปรแกรมเมอร์มาก่อน (และก็เก่งในเรื่องนั้นด้วย!
ฉันจดวัตถุประสงค์ไว้เสมอก่อนที่จะเริ่มงานใหม่ นี่คือเป้าหมายของฉัน – สร้างสถาปัตยกรรมแบบโมดูลาร์ที่มีช่วงการเรียนรู้น้อยกว่าหนึ่งสัปดาห์ และพัฒนาแอปที่รวดเร็วอย่างเห็นได้ชัด หาก Google สามารถดึงผลลัพธ์ที่ถูกต้องจากแถวหลายล้านล้านแถวในเวลาน้อยกว่าหนึ่งวินาที เหตุใดจึงไม่สามารถนัดหมายได้
ฉันเจอคำศัพท์ RxJS บน Angular.io ติดตามหัวข้อนี้สองสามชั่วโมงและชอบแนวคิดในการสตรีมข้อมูลมาก แนวคิดนั้นเรียบง่าย – คุณจะดูวิดีโอบน Youtube หรือไม่ ถ้าคุณต้องรอ 5 นาทีทุกครั้งที่ต้องการดู
ฉันตัดสินใจที่จะลองดู แต่ความจริงก็คือฉันไม่สามารถทำเองได้ ฉันต้องการความช่วยเหลือจากพวกรุ่นพี่
วันถัดไป ฉันเพิ่งอธิบายแนวคิดการสตรีมให้ทีมฟังและพยายามสร้างความสนใจ ในอีกไม่กี่วันข้างหน้า ฉันยังคงดำเนินการต่อไปจนกว่าดาราดังของเรา (ซึ่งเป็นโปรแกรมเมอร์ที่ดีกว่าฉันในตอนนี้) จะจับจังหวะได้ หว่านเมล็ดพันธุ์แห่งการเปลี่ยนแปลงครั้งแรก
ในเวลาไม่กี่วัน เราก็สามารถนำแนวคิดการสตรีมทั้งหมดไปใช้ในโค้ดที่มีอยู่ของ Appointy อย่างที่คาดไว้ มันใช้งานได้ดี แต่ก็ไม่ได้ยอดเยี่ยม เราจำเป็นต้องทำมากขึ้น
บทที่ 3: ความใจจดใจจ่อคลี่คลาย
ยังมีอีกสองประเด็นที่ต้องแก้ไข
- ส่วนต่อประสานผู้ใช้และประสบการณ์ผู้ใช้ (UX/UI)
- ความเร็วในการโหลด
1.5 เดือนผ่านไป และเราเพิ่งได้รับความรู้ ยังไม่มีการดำเนินการ ฉันไม่สามารถขอให้รุ่นพี่ทำงานบน UX/UI ได้ และพวกเขาจะรู้ว่าเรากำลังพยายามลบโค้ดเก่า และฉันไม่รู้ว่าจะเกิดอะไรขึ้นในตอนนั้น
ดังนั้นฉันจึงตัดสินใจทำงานกับเด็กฝึกงานคนหนึ่งที่เราจ้างมา เด็กฝึกงานใหม่นี้มีแนวทางในการเขียนโค้ดที่ต่างไป จากเดิม เขาต้องการที่จะรวดเร็วเร็วกว่าใคร เขาช่วยฉันใช้เครื่องมือต่างๆ เพื่อให้ฉันตรวจสอบการเปลี่ยนแปลงได้แบบเรียลไทม์และให้คำติชมแก่เขาทันที เราทั้งคู่เริ่มมาแต่เช้าตอน 6 โมงเช้า และเมื่อถึงเวลาที่สำนักงานของเราจะเริ่มทำงาน เราก็จะได้งานอีกสองสามชั่วโมงแล้ว ผลิตภัณฑ์ใหม่เริ่มเป็นรูปเป็นร่าง
ไม่กี่วันต่อมา ฉันก็รู้ว่าทุกอย่างทำงานได้ดี เราอยู่ในเส้นทางและถึงเวลาที่จะพูดคุยกับทั้งทีม ตอนนี้ฉันมีหลักฐานของแนวคิดที่จะพิสูจน์ว่าโค้ด 9 ปีสามารถถูกทิ้งได้ แต่ไม่มีทีมร็อคสตาร์ของเรา
วันนั้นมาถึง เราแสดง UI ใหม่และอธิบายขั้นตอนถัดไปในการถ่ายทอดสด ทีมร็อคสตาร์ของเราเริ่มเชื่อว่าสามารถทำได้ นั่นเป็นเพียงสิ่งที่จำเป็น
ตอนนี้หลังจากผ่านไป 4 เดือน เวอร์ชันแรกของเราอยู่ในขั้นตอนการทดสอบ
ผลลัพธ์
- เราสามารถลดเวลาในการโหลด "Admin Area" จาก 10 วินาทีเป็น 2 วินาที (ใช่ เร็วกว่า 5 เท่า!!)
- เราสามารถลดโหลดบนเซิร์ฟเวอร์ของเราได้ 50%
- เราสามารถให้โปรแกรมเมอร์ใหม่มีประสิทธิผลภายในหนึ่งสัปดาห์
- ในที่สุดฉันก็มีเวลาเขียนบล็อก!
อะไรต่อไป?
- ขั้นตอนแรกคือการพอร์ตซอฟต์แวร์ที่มีอยู่ ขั้นตอนต่อไปคือการสร้างคุณสมบัติที่ไม่ต้องการ (เราได้รวบรวมคำขอคุณสมบัติจากลูกค้าของเราและรายการลำดับความสำคัญของเราพร้อมแล้ว)
- API ของเราพร้อมแล้วซึ่งทีมของเราหรือทีมภายนอกสามารถใช้เพื่อรวมแอปต่างๆ ได้ ตัวอย่างเช่น เราไม่ต้องใช้เวลามากกว่าหนึ่งสัปดาห์ในการเพิ่มช่องทางการชำระเงินใหม่อีกต่อไป
- เราจะมีแบนด์วิดธ์มากขึ้นเพื่อเชื่อมโยงกับบริษัทอื่นๆ ที่สามารถเพิ่มมูลค่าให้กับธุรกิจของคุณได้มากขึ้น เราได้เชื่อมโยงกับ "จองกับ Google" เพื่อช่วยให้คุณได้ลูกค้าใหม่แล้ว
PS: ในช่วง 4 เดือนนี้ เราไม่เพียงแต่สร้าง Appointy ตั้งแต่เริ่มต้น แต่ยังประสบความสำเร็จในการสร้างผลิตภัณฑ์การจัดตารางเวลาห้องประชุมอีกรายการตั้งแต่เริ่มต้น เรา ขายมันในราคา $130,000 โดยไม่ได้พบปะกับลูกค้าด้วยตนเอง
[โพสต์นี้โดย Nemesh Singh ปรากฏตัวครั้งแรกในบล็อกอย่างเป็นทางการและทำซ้ำโดยได้รับอนุญาต]