Trang chủ

Khám phá những dòng code của lập trình viên kinh nghiệm 3 năm

Kinh nghiệm lập trình là một cụm từ được mỗi người định nghĩa khác nhau. Nhưng với mình thì kinh nghiệm lập trình có nhiều yếu tố hình thành nên. Và hầu hết mọi người đều chỉ ra kinh nghiêm lập trình qua thời gian, chưa đủ, ở bài viết này mình sẽ nói lên quan điểm của mình về vấn đề này. Khi bạn bắt đầu bước chân vào thế giới lập trình, thì bài viết này sẽ định hướng cho bạn biết con đường tích lũy kinh nghiệm lập trình nhiều chông gai nhưng cũng rất thú vị phía trước.

Kinh nghiệm lập trình là gì?

Ở đây mình nói một chút về cụm tự kinh nghiệm trước khi mình vô tình bắt gặp khoảnh khắc thú vị của bạn có kinh nghiệm 3 năm trong một dự án mình tham gia cùng. Câu hỏi thú vị của bạn dev có kinh nghiệm trong lập trình đấy là về kinh nghiệm và kinh nghiệm trong lập trình bao gồm yếu tố là:

Thời gian làm việc bao lâu?
Bạn đã tham gia bao nhiêu dự án?
Chức năng bạn làm trong dự án đó là gì?
Lương của bạn hiện tại được bao nhiêu?

Bạn đã từng gặp những câu hỏi này qua các cuộc phỏng vấn chưa? Nếu bạn đã từng gặp thì chúc mừng bạn đã tìm được một công ty chất lượng, nếu chưa thì có thể bạn chưa gặp một người phỏng vấn có tâm huyết :D Nếu có thời gian mình sẽ giải thích cho bạn vì sao người tuyển dụng lại hỏi như thế? Nhưng quan trọng vẫn là câu hỏi "Lương của bạn hiện tại được bao nhiêu?".

Nhiều bạn hiểu rằng nhà tuyển dụng chắc hỏi mức lương công ty cũ để đánh giá kinh nghiệm của mình để ra mức lương đây mà, cho nên cứ deal thêm chứ lo sợ gì chứ! Đấy là câu chuyện bạn đang nghĩ, về cơ bản bạn nghĩ cũng đúng thôi, bạn chưa từng gặp những người từng trải nên không ai có thể phân tích cho bạn về bản chất của nó.

Bạn có biết vì sao họ lại lập ra những chức danh như Senior, Juinor, Fresher, PM, Leader... Ngoài chức danh để phân cấp thì nó còn có một khía cạnh mang tính bóc lột, sở dĩ họ quy định mỗi vị trí như vậy chỉ là để quyết định tương ứng một mức lương mà thôi và cho dù bạn có giỏi như thế nào thì anh cũng đang là ở vị trí đó nên không thể deal lương cho bạn.

Việc bạn kê khai lương của bạn tại công ty cũ thì cũng là lúc bạn tự đánh giá kinh nhiệm của bạn đấy. Họ sẽ nhìn mức lương của bạn để đánh giá kinh nghiệm của bạn, cho nên hãy can đảm để đón nhận mức lương xứng đáng với năng lực của bạn, không nên gò bó vào một vị trí như Senior mà nhận mức lương không tương xứng. Và bây giờ, mình sẽ nói về một hoàn cảnh thực tế một chút.

Gần đây, mình đã tham chung trong một dự án của một nhóm khác trong công ty. Một lần trong lần họp của nhóm họ luôn để xảy ra lỗi và khi fix lỗi này thì lại xảy ra một lỗi khác, nghĩa là họ đã không kiểm soát lỗi trong dự án của mình. Theo như mình suy đoán thì họ đã fix thủ công theo yêu cầu thêm tính năng của khách hàng, và đúng như vậy!

2. Cách viết code

Khi mình xem qua về chức năng phần quyền của nhóm, mình đã phát hiện ra một chức năng mà mình cho rằng công ty đã trả lương cho bạn dev ấy không xứng đáng. Ở đây mình đưa ra đoạn code tương tự trong dự án 😘


function checkAuth(data) {
  if (data.role !== 'admin') {
    console.log('Đây không phải Admin!');
    return false;
  }
  if (data.grade < 1) {
    console.log('Chưa đủ Level để làm việc!');
    return false;
  }
  if (data.job !== 'FE') {
    console.log('Không phải góc làm việc của bạn!');
    return false;
  }
  if (data.type !== 'eat dog') {
    console.log('Ở đây chúng tôi không ăn thịt chó!');
    return false;
  }
}

Ở đây, chắc hẳn các bạn đã hiểu cách hoạt động và có thể viết đoạn mã này, nhưng hy vọng là chỉ dành cho những bạn Fresher mà thôi! Vấn đề ở đây là gì?

Nếu thêm nhiều quyền nữa thì sao, chắc là if...else tới sáng luôn quá.
Không thể sử dụng lại cho dự án khác có chức năng tương tự như vậy?
Vi phạm nguyên tắc đóng mở trong code lập trình

Sau khi đọc xong đoạn code, mình đã xác định các chiến lược cụ thể, đóng gói từng sự kiện một và làm cho chúng có thể chuyển đổi cho nhau cách dễ dàng và có thể sử dụng cho các dự án khác.


// list job 
const jobList = ['FE', 'BE'];

// function
var strategies = {
  checkRole: function(value) {
    return value === 'admin';
  },
  checkGrade: function(value) {
    return value >= 1;
  },
  checkJob: function(value) {
    return jobList.includes(value);
  },
  checkEatType: function(value) {
    return value === 'eat Dog';
  }
}

Vậy là mình đã viết xong chiến lược, việc cần làm tiếp theo đó chính là xác minh chiến lược đó


var Validator = function() {
  this.cache = [];

  // add su kien
  this.add = function(value, method) {
    this.cache.push(function() {
      return strategies[method](value);
    });
  };

  // check
  this.check = function() {
    for (let i = 0; i < this.cache.length; i++) {
      let valiFn = this.cache[i];
      var data = valiFn(); // check tai day
      if (!data) {
        return false;
      }
    }
    return true;
  };
}

Tại thời điểm này, các điều kiện mà dự án 1 cần để xác minh quyền là: Người dùng có phải là Admin không? Phải cấp 3 trở lên mới được chỉnh sửa bài....


var compose1 = function() {
  var validator = new Validator();
  const data1 = {
    role: 'admin',
    grade: 3
  };
  validator.add(data1.role, 'checkRole');
  validator.add(data1.grade, 'checkGrade');
  const result = validator.check();
  return result;
}

//console.log(compose1())

Tương tụ ở dự án khác, thì kiểm tra như sau: Người dùng có phải là Admin không? Và đồng thời làm ở BE (Back-End) hay không?


var compose2 = function() {
  var validator = new Validator();
  const data2 = {
    role: 'admin',
    job: 'BE'
  };
  validator.add(data2.role, 'checkRole');
  validator.add(data2.job, 'checkJob');
  const result = validator.check();
  return result;
}

console.log(compose2())
}

Đó chỉ vậy thôi bạn đã có thể dùng lại những mẫu thiết kế này cho các dự án khác và sau này. Có thể có nhiều cách khác nhau. Nhưng quan trọng là bạn phải tự mình đóng gói những tính năng cần thiết để cho đồng đội và dự án của mình có thể tái sử dụng lại một cách dễ dàng và triệt để.

Tác giả: Jos Hoàng Tiên