Thảo Trịnh -
  • Chuyện đọc
  • Lập trình
    • Học nghề
    • Làm thợ
    • Agile Mindset
      • Agile Project Management (APM)
      • Tư duy linh hoạt
  • Nói chuyện vui
Thảo Trịnh -
Chuyện đọc
Lập trình
    Học nghề
    Làm thợ
    Agile Mindset
    Agile Project Management (APM)
    Tư duy linh hoạt
Nói chuyện vui
  • Chuyện đọc
  • Lập trình
    • Học nghề
    • Làm thợ
    • Agile Mindset
      • Agile Project Management (APM)
      • Tư duy linh hoạt
  • Nói chuyện vui
Lập trình

Lập trình cặp hay pair programing nghĩa là gì?

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. Người ta khuyên rằng hai người nên luân phiên đổi vai trò, khoảng nửa giờ một lần. Xem thêm

June 29, 2019by thaotrinh
Lập trình

Technical debt hay câu chuyện về nợ kĩ thuật

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.
– Bỏ qua design pattern.
– Bỏ qua SOLID.
– Bỏ qua coding conventions.
– Thực hiện hotfix mà chưa đánh giá hết rủi ro.
– Nhằm đáp ứng yêu cầu về deadline, chọn giải pháp chưa thực sự tối ưu để giải quyết vấn đề.
– Copy paste thì nhanh hơn là refactor code.
Với khá nhiều “bỏ qua” và cách tiếp cận giải quyết bài toán như vậy. Dự án sẽ tồn đọng các vấn đề về kĩ thuật, lớn dần theo thời gian. Cho đến thời điểm, dự án sẽ lâm vào trạng thái sửa chữa, cập nhật thì mệt mỏi, đập đi xây lại thì không đủ nguồn lực, thời gian, kinh tế. Xem thêm

June 21, 2019by thaotrinh
Lập trình

Tiếp cận lại về static và singleton

tiep-can-lai-ve-static-va-singleton/

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. Nghĩa là bạn sẽ không thể sử dụng từ khoá new để tạo object. Muốn sử dụng methods và properties cần khai báo thêm từ khoá static và gọi trực tiếp bằng tên lớp. Xem thêm

June 20, 2019by thaotrinh
.NET, Database

Tạo ứng dụng asp net core code first đầu tiên

– 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). Xem thêm

June 19, 2019by thaotrinh
Công nghệ

Mô hình CQRS-ES

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.

June 14, 2019by thaotrinh
Công nghệ

Thiết kế hệ thống phần mềm với mô hình CQRS

Đầ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.
– Linh hoạt trong việc phát triển.
– Dễ dàng test và bảo trì. Xem thêm

June 12, 2019by thaotrinh
.NET, Công nghệ

Unit Of Work và Repository Pattern – Song kiếm hợp bích

Để 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. Chúng ta cần xóa dữ liệu ở 2 bảng Orders và OrderDetails.

Theo cách làm thông thường, chúng ta sẽ xóa dữ liệu bảng OrderDetails trước, sau đó xóa dữ liệu bảng Orders. Với cách làm này rủi ro xảy ra nếu sau khi xóa dữ liệu bảng OrderDetails xong, một exception xảy ra (ví dụ kinh điển là mất mạng) lúc này dữ liệu bảng Orders chưa được xóa, dẫn tới việc không đảm bảo tính toàn vẹn dữ liệu và có thể gây lỗi hệ thống khi truy xuất đơn hàng.

Để giải quyết bài toán này. Chúng ta sử dụng pattern UnitOfWork, thực hiện việc xóa dữ liệu ở 2 bảng trong cùng 1 transaction. Bất kì ngoại lệ nào xảy ra, dữ liệu sẽ được rollback. Nếu thao tác xóa dữ liệu thành công, transaction sẽ được commit.

June 8, 2019by thaotrinh

Tìm kiếm

Tags

5whys Agile Apache blockchain C# CQRS Daily Scrum database DDD deadlocks Dependency Injection Dependency Inversion Design Pattern docker ebook git Good Developer growth mindset kinh tế Pair programing Repository Retrospective Risk Management Scrum Scrumban Scrum Guide Scrum Master Senior Senior Developer singleton solid sống Technical debt UI UnitOfWork UX Viết Động lực

Bài viết mới

Hãy agile đi

Hãy agile đi

Nói chuyện về vấn đề

Nói chuyện về vấn đề

Hỏi 5 lần tại sao

Hỏi 5 lần tại sao

Tư duy linh hoạt là gì

Tư duy linh hoạt là gì

Không phải làm bao nhiêu mà là tạo ra bao nhiêu

Không phải làm bao nhiêu mà là tạo ra bao nhiêu

Một cuộc đời đáng sống

Một cuộc đời đáng sống

Chuyên mục

  • Chuyện đọc
  • Lập trình
    • Agile Mindset
      • Agile Project Management (APM)
      • Tư duy linh hoạt
    • Công nghệ
      • .NET
      • Blockchain
      • Database
    • Học nghề
    • Làm thợ
  • Uncategorized
    • Gã
    • Nói chuyện vui
    • Product
      • Design