Lập trình đôi (tiếng Anh: Pair Programming) là kiểu lập trình đòi hỏi hai kỹ sư phần mềm cùng tham gia một nỗ lực lập trình chung trên một máy trạm, nghĩa là chỉ có một màn hình, một bàn phím. Mỗi người thực hiện việc mà người kia hiện không làm. Ví dụ, người này gõ các bộ test đơn vị (unit test), người kia nghĩ về các lớp đầu vào (input) sẽ thỏa mãn bộ test đó; hoặc người này viết mã còn người kia quan sát để hướng dẫn hoặc kiểm lỗi.… Xem thêm “Lập trình cặp hay pair programing nghĩa là gì?”

Bài viết này chúng ta sẽ làm rõ các vấn đề
1. Technical debt là gì?
2. Khi nào gặp?
3. Phòng tránh và hạn chế như nào?
4. Làm sao để thay đổi?

Technical debt là gì? – Khi nào gặp?
Theo dịch thuật, technical debt có nghĩa là nợ kĩ thuật. Diễn giải ra, nợ kĩ thuật là khi vì tính chất, yêu cầu của dự án, khi code, chúng ta:
– Bỏ qua bước thiết kế hệ thống.… Xem thêm “Technical debt hay câu chuyện về nợ kĩ thuật”

Xuất phát từ mấy vấn đề nên muốn cover lại kiến thức về static và singleton.

– Một là để hiểu rõ thêm vấn đề
– Hai là làm rõ thêm vấn đề

Vậy static có đặc điểm gì? Khi nào nên dùng nó?
Singleton thì sao? Dùng thế nào? Các vấn đề cần lưu ý khi sử dụng?

Ok, xắn ✋ vào tìm hiểu static trước.

Định nghĩa: một class static sẽ không cho bạn tạo một cài đặt.… Xem thêm “Tiếp cận lại về static và singleton”

– Bài viết dựa trên môi trường làm việc là MacOs.
– Yêu cầu kĩ năng research cơ bản.
– Biết sơ qua các khái niệm: docker, kitematic, sqlserver, terminal (lol).

Cài đặt môi trường:
B1: Cài docker và sqlserver, 2 thằng này thì khá rõ để làm gì rồi ha. (hướng dẫn)
B2: Cài Kitematic, để quản lý các container (link)
B3: Chạy docker, chạy kitematic và start sql trong docker.
Lưu ý: Bỏ qua bước 2 và bước 3 nếu đã chạy sqlserver từ bước 1.… Xem thêm “Tạo ứng dụng asp net core code first đầu tiên”

Một trong các đòi hỏi lớn của việc quản lý danh mục sản phẩm là phải thiết kế để đáp ứng các nhu cầu về hiệu năng và tích hợp với các hệ thống khác. Để đáp ứng các yêu cầu tốt, thì phải được thiết kế từ tổng thể ngay từ đầu. Có vậy mới tạo ra sự phát triển liền mạch, nhất quán giúp đảm bảo tính ổn định, cũng như tiến độ làm việc.

Đầu tiên chúng ta bắt đầu với bài toán quản lý sản phẩm với các nghiệp vụ phức tạp. Ví dụ hệ thống quản lý sản phẩm của các trang thương mại điện tử (Amazon, shoppe, tiki..).

Với bất kì sản phẩm phần mềm nào, chúng ta đều có chung mục đích thiết kế:

– DRY (Don’t Repeat Yourself), các nghiệp vụ được phân tách rõ ràng, cô đọng và tập trung cao.
– Có thể mở rộng, sửa đổi các thành phần độc lập.

Ở bài trước mình đã giới thiệu với các bạn về UnitOfWork Design Pattern.

Nhắc lại vể lợi ích của UOW

• Quản lý danh sách các đối tượng logic nghiệp vụ được thay đổi trong một transaction.
• Khi một transaction được complete, tất cả thay đổi sẽ được gửi tới database như một big unit of work

Bài toán:

Để hình dung rõ hơn, lần này chúng ta sẽ xem xét bài toán thực tế khi quản trị hệ thống muốn xóa một đơn hàng.… Xem thêm “Unit Of Work và Repository Pattern – Song kiếm hợp bích”