Video học lập trình mỗi ngày

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 tôi 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 đủ, và bai viết này tôi sẽ nói lên quan điểm của tôi về vấn đề này.

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

Đầu tiên ta nói về cụm từ này một chút trước khi tôi bắt gặp khoảnh khắc đáng yêu của bạn có kinh nghiệm 3 năm. Đó là sự hình thành kinh nghiệm của một một lập trình viên. Một dev có kinh nghiệm lập trình là phải có nhiều yếu tố khác nhau nhưng ở đây tôi chỉ lưu đến 4 yếu tố đó là: 

• Thời gian làm việc trên code? 
• Bao nhiêu dự án bạn đã tham dự? 
• 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?

Có bạn nào đã gặp những câu hỏi này thông qua các cuộc phỏng vấn chưa? Nếu có 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 thì tôi sẽ giải thích vì sao họ lại hỏi như thế? Nhưng quan trọn là câu cuối cùng đó là "Mức lương hiện tại của bạn tại công ty bao nhiêu?" 

Ở đây, có nhiều bạn hiểu nôm na là họ hỏi như vậy để xem mình được trả lương ở công ty cũ bao nhiêu mà trả lương cho mình đó mà. Cho nên mình cứ deal thêm chứ lo sợ gì chứ? Câu trả lời như vậy đúng nhưng sai, vì sao tôi lại nói vậy. Thứ nhất là bạn hiểu như vậy là cũng đúng thôi, vì bạn chưa gặp những người đàn anh từng trải, bạn bè của bạn cũng chỉ tầm như bạn mà thôi cho nên không một ai có thể phân tích cho bạn như thế nào hiểu cho đúng bản chất. Và bây giờ tôi sẽ nói thêm cho bạn về khía cạnh sai. Và tôi nhấn mạnh là đây là ý kiến riêng của mỗi cá nhân tôi không đánh đồng hết mọi tình huống. 

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ĩ hok 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ù anh có giỏi như thế nào thì anh cũng đang là ở vị trí đó nên không thể deal lương cho anh. 

Thứ hai đó là việc bạn kê khai lên 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ờ, tôi sẽ nói về một hoàn cảnh thực tế một chút. 

Đó là thời gian gần đây, mỗi lần họp dự án thì có một nhóm nhỏ luôn để xảy ra lỗi. Và khi fix lỗi này thì nó lại thêm một lỗi khác. Nghĩa là theo như tôi nghĩ, họ đã không kiểm soát được lỗi tốt. Có thể là tính năng được thêm vào mỗi ngày theo yêu cầu của khách hàng do đó có thể họ đã fix thủ công. Và kết quả thì tôi đã đoán đúng. Hay xem trường hợp thế nào?

Cách viết code lập trình

Khi tôi xem qua về chức năng phân quyền của nhóm họ, thì tôi đã phát hiện ra một chức năng mà tôi cho rằng công ty đã trả lương cho bạn ấy không xứng đáng, cụ thể là như sau, đương nhiên là tôi đã sửa lại chứ không lộ hêt dự án :D

function checkAuth(data) {
  if (data.role !== 'admin') {
    console.log('Khong phai admin, co the la lua dao');
    return false;
  }
  if (data.grade < 1) {
    console.log('Chua du level quan ly :D ');
    return false;
  }
  if (data.job !== 'FE') {
    console.log('Khong phai lam viec tai front-end');
    return false;
  }
  if (data.type !== 'eat dog') {
    console.log('Bo nay khong an thit cho');
    return false;
  }
}

Tôi tin rằng mọi người đều đã có thể viết mã này, nhưng chỉ hy vọng là dành cho những bạn fresher mà thôi. Vậy có vấn đề gì khi viết nó như thế này? 

• - 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 Bạn đã đủ hình dung ra chưa?

Và chắc chắn những bạn này cần đọc qua "7 JavaScript Design Pattern". Và quan trọng hay xem tôi đã viết lại như thế nào? Thiết kết mô hình chiến lược cho bản thân Định nghĩa: Để thực hiện một chức năng nào đó, có nhiều phương án để lựa chọn.  Và tình huống này làm tôi nhớ đến một câu chuyện mà hình như có nhắc đến bài viết "Tư duy lập trình qua một ví dụ đơn giản? Và Bạn đang ở đâu?". Ở bài viết đó là các tình huống được đưa ra để thay thế if...else  trong lập trình. Bạn nên tham khảo cũng hay lắm.

Tôi 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 một cách dễ dàng và có thể dùng lại cho những dự án khác. Chúng tôi sử dụng chế độ chiến lược để chuyển đổi logic sau👇

// 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';
  }
}

Chúng ta đã viết xong chiến lược, việc cần làm tiếp theo là xác minh nó

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 chúng ta đã 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ôi chỉ nói đến đây thôi, còn các chuyện khác các bạn cứ bạn luận tiếp...