ก้าวสู่วงการ!!

Jan 04 2023

สวัสดีทุกคน ในขณะที่ฉันกำลังเริ่มต้นอาชีพของฉันในฐานะนักพัฒนาซอฟต์แวร์ใน fintech มีการรับรู้บางอย่างว่าการเขียนโค้ดที่นี่แตกต่างจากโครงการวิทยาลัย/แฮ็กกาธอนของฉันอย่างไร โดยปกติแล้ว เมื่อเราทำงานในโครงการส่วนบุคคล พวกเขาจะเป็นต้นแบบเล็กๆ ของความคิดของเรา

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

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

การพัฒนาการทดสอบขับเคลื่อน

วิธีนี้สามารถช่วยให้คุณเขียนโค้ดสะอาดซึ่งเป็นอุตสาหกรรมที่จำเป็นในปัจจุบัน ในสถานการณ์ที่มีการประนีประนอมระหว่าง O(N) + clean code v/s O(logN) โค้ดอัลกอริทึม โดยทั่วไป ผู้คนมักจะยอมรับโค้ดที่สะอาดและอ่านง่ายกว่า

ในฐานะที่เป็นน้องใหม่ เรามักจะปรับโครงสร้างโค้ดของเราใหม่หลังจากที่เราเห็นกรณีทดสอบที่ล้มเหลวบน Leetcode/CodeChef/IB หรือแพลตฟอร์มการเขียนโค้ดอื่นๆ เป็นต้น แต่ในขณะที่ทำงานในโปรเจกต์การเปลี่ยนโค้ดในขณะที่พบข้อบกพร่องระหว่าง QA อาจทำให้โค้ดยุ่งเหยิงและอ่านไม่ได้ การสนทนากับผู้จัดการโครงการตั้งแต่ต้นจนจบก่อนกำหนดขอบ/กรณีทดสอบทั้งหมดสำหรับคุณลักษณะและการกำหนดอินพุต/เอาต์พุตต่างๆ ของฟังก์ชันที่คุณจะเขียนสามารถช่วยในการสร้างความเข้าใจที่ดีขึ้นและทักษะการทำงานร่วมกันข้ามทีม ลดจุดบกพร่องและ ปรับปรุงเวลาในการจัดส่งของคุณ
แน่นอนว่าเราไม่ได้เขียน UT ในทุกที่ในอุตสาหกรรมเนื่องจากความซับซ้อนที่เพิ่มขึ้นและกำหนดเวลาที่เข้มงวด แต่ถึงแม้มีพิมพ์เขียวคร่าวๆ บนกระดาษก่อนที่จะเริ่มเขียนโค้ด ในที่สุดก็ยังนำไปสู่โค้ดที่สะอาดขึ้นและมีข้อบกพร่องเล็กน้อย
นอกจากนี้ การเขียน UT จะช่วยป้องกันคุณลักษณะของคุณไม่ให้เสียหายเนื่องจากการพัฒนาที่จะเกิดขึ้น

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

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

ตัวอย่างเช่น ใน Nest.js เป็นแนวปฏิบัติที่ดีที่จะนำเข้าโมดูลแทนบริการ เนื่องจากคุณจะเพิ่มโอกาสที่จะพบข้อผิดพลาด

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

ป.ล. — ฉันทำพลาดครั้งใหญ่ขณะเขียน AWS Lambda ครั้งหนึ่ง การฉีดที่ไม่ต้องการอาจทำให้เวลาในการเริ่มต้นสูง ซึ่งส่งผลให้ต้นทุนและขนาดเซิร์ฟเวอร์เพิ่มขึ้น บทความ นี้โดย amazon AWS สำหรับ lambdas เป็นบทความที่ดีมากในการอ่านเพื่อทราบวิธีหลีกเลี่ยงอุบัติเหตุจากการฉีดพึ่งพา ซึ่งนำไปสู่การเพิ่มประสิทธิภาพที่ดีขึ้น แม้ว่าจะเป็นเรื่องเฉพาะสำหรับแลมบ์ดา แต่คุณก็สามารถอ้างถึงสิ่งนี้เพื่อให้มีภาพรวมเพื่อทำความเข้าใจถึงความสำคัญ

การจัดการข้อผิดพลาด

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

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

ใน JavaScript เรามีคลาส Error ในตัว

Error {
  constructor(message) {
    this.message = message;
    this.name = "Error"; // (different names for different built-in error classes)
    this.stack = <call stack>; // non-standard, but most environments support it
  }
}

export class ServerError extends Error {
    serverMessage: ServerMessages;
    statusCode: number;
    context: Record<string, string>;

    constructor(
        errorCode: ServerMessages,
        message: string,
        statusCode = 500,
        context: Record<string, string> = {},
    ) {
        super(message);
        this.name = ServerError.name;
        this.serverMessage = errorCode;
        this.statusCode = statusCode;
        this.context = context;
    }
}

จับข้อผิดพลาดของคุณเสมอ
หลีกเลี่ยงการโยนข้อผิดพลาดจากส่วนของโค้ดที่ทำงานแบบอะซิงโครนัสหลังจากคำขอเสร็จสมบูรณ์

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

ป.ล. ขอไม่ลงรายละเอียดที่นี่ เนื่องจากมีบทความที่น่าสนใจเกี่ยวกับการเดินทางของฉันในโดเมนนี้ โปรดติดตาม!!

ฐานข้อมูล

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

ปฏิบัติตามแนวทางปฏิบัติด้านความปลอดภัย — หากคุณมีข้อมูล PII ที่มีการเข้ารหัสชั้นแอปพลิเคชันอยู่รอบ ๆ ก็เป็นความคิดที่ดี หากไม่ลองหลีกเลี่ยงการเปิดเผยข้อมูลที่ละเอียดอ่อนไปยังปลายทางแบบเปิด การติดตามสถาปัตยกรรม 3 เลเยอร์และการนำเลเยอร์ DAO/ฐานข้อมูล ไปใช้เสมอ จะช่วยให้เกิดความยืดหยุ่นสำหรับกรณีที่คุณต้องการสลับหรือใช้ฐานข้อมูลหลายรายการ
การตรวจสอบประสิทธิภาพของแบบสอบถาม — เขียนแบบสอบถามที่มีการทำดัชนีเสมอ การเขียนแบบสอบถามในฟิลด์ที่ไม่ได้จัดทำดัชนีนั้นไม่ใช่เรื่องใหญ่เมื่อพูดถึงการวิเคราะห์และการตรวจสอบประสิทธิภาพ
มีข้อมูลเชิงลึกพื้นฐานเกี่ยวกับข้อกำหนดชั้นบนสุดที่เป็นไปได้ เช่นฐานข้อมูลในหน่วยความจำ เช่น- Redis

คำถามที่ถามนักพัฒนาอาวุโสของคุณ —

เราให้บริการแก่ลูกค้าอย่างไร

ไปป์ไลน์โค้ดทั้งหมดที่คุณมีคืออะไร และเราใช้แนวทางปฏิบัติใดในการปรับใช้

ทำไมเราถึงใช้สิ่งเหล่านี้?

ทางเลือกอื่นที่มีอยู่มีอะไรบ้าง?

การเขียนรหัสทั่วไป

พยายามเขียนโค้ดของคุณให้กว้างที่สุด ยกตัวอย่างง่ายๆ คุณต้องการเขียนโค้ดเพื่อหาระยะแฮมมิ่งระหว่างสองสตริง

export function hammingDistanceBetweenTwoStrings(
    str1: string,
    str2: string,
    comparator: (arg0: string, arg1: string) => boolean,
): number {
    const minLengthAmongTwo =
        str1.length < str2.length ? str1.length : str2.length;

    let diffCharacters = 0;
    for (let i = 0; i < minLengthAmongTwo; i++) {
        const isDifferent = str1.charAt(i).localeCompare(str2.charAt(i)) !== 0;
        if (isDifferent) diffCharacters++;
    }

    return (
        diffCharacters +
        (str1.length - minLengthAmongTwo) +
        (str2.length - minLengthAmongTwo)
    );
}

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

export function hammingDistanceBetweenTwoStrings(
    str1: string,
    str2: string,
    comparator: (arg0: string, arg1: string) => boolean,
): number {
    const minLengthAmongTwo =
        str1.length < str2.length ? str1.length: str2.length;

    let diffCharacters = 0;
    for (let i = 0; i < minLengthAmongTwo; i++) {
        const isDifferent = comparator(str1.charAt(i), str2.charAt(i));
        if (isDifferent) diffCharacters++;
    }

    return (
        diffCharacters +
        (str1.length - minLengthAmongTwo) +
        (str2.length - minLengthAmongTwo)
    );
}

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

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