Sở hữu tập thể mã nguồn

,
Sở hữu tập thể mã nguồn động viên mọi người đóng góp ý tưởng mới cho tất cả các phần dự án. Bất cứ lập trình viên nào cũng có thể thay đổi bất kỳ dòng mã lệnh để thêm chức năng, sửa lỗi, cải tiến thiết kế hoặc tái cấu trúc. Không một ai trở thành “cổ chai” đối với những thay đổi cả

6 bước giúp bạn sống sót qua quá trình chuyển đổi DevOps

, ,
DevOps có ở mọi nơi và nếu bạn không phải đang ở giai đoạn giữa của một chương trình chuyển đổi sang DevOps thì có lẽ bạn cũng sắp trải nghiệm rồi. Dưới đây là 6 bước xoa dịu nỗi đau và giúp bạn tồn tại sau quá trình chuyển đổi

TDD gây hại cho kiến trúc

,
Một tranh luận liên quan là: Bạn càng có nhiều kiểm thử, việc thay đổi mã sản xuất càng khó khăn; bởi vì rất nhiều bài kiểm thử có thể bị hỏng và đòi hỏi phải chỉnh sửa.

Chàng kỹ sư trẻ

,
Tôi muốn lãnh đạo một nhóm và có thể đưa ra những quyết định quan trọng về cơ sở dữ liệu, framework, máy chủ web, và tất cả mọi thứ.

 Flaccid Scrum

, , ,
Những gì đã xảy ra là họ đã thiếu sự đầu tư cho chất lượng tự thân của phần mềm do mình làm ra. Nếu bạn phạm sai lầm đó, bạn sẽ sớm thấy năng suất của mình bị sụt giảm

Lập trình tinh gọn

,
Với quy tắc đơn giản, các nhóm làm việc có thể tiếp tục cải tiến các quy trình và các sản phẩm mà không cần có những hướng dẫn chi tiết hoặc quy trình phức tạp.

Thợ lành nghề

,
Mẫu thiết kế và Phương pháp trong cuốn Phát triển Phần mềm Linh hoạt (Agile Software Development) của Robert C. Martin, nhà xuất bản Prentice Hall, 2002.

Mã sạch

,
Cuốn sách này viết về điều đó – lập trình tốt – và đầy những mã lệnh. Chúng ta sẽ soi xét mã lệnh theo nhiều hướng khác nhau. Ta sẽ nhìn mã từ đầu đến cuối

Kiểm thử đơn vị trong XP

,
Kiểm thử đơn vị là một trong những kỹ thuật cốt lõi của Extreme Programming (XP). Nhưng cách kiểm thử đơn vị của XP có đôi chút khác biệt. Trước hết, bạn nên tự tạo hoặc tải một khung làm việc cho kiểm thử đơn vị nào đó, để từ đó xây dựng nên những bộ kiểm thử đơn vị tự động. Sau đó, bạn nên tiến hành kiểm thử tất cả các lớp trong hệ thống. Những phương thức getter và setter đơn giản thì nên bỏ qua. Bạn cũng nên áp dụng luật kiểm thử trước, rồi mới viết mã lệnh.

[XP] Tính đơn giản là chìa khóa

,
Việc thiết kế đơn giản luôn mất thời gian hơn việc thiết kế phức tạp. Vì vậy, hãy làm những việc đơn giản nhất mà trước mắt hoạt động. Nếu bạn thấy có chỗ nào đó phức tạp thì hãy thay thế nó bằng thứ đơn giản. Lúc này, việc thay thế mã phức tạp của bạn sẽ luôn nhanh và rẻ hơn so với khi bạn lãng phí nhiều thời gian vào nó.

[XP] Không bao giờ thêm chức năng sớm

,
Giữ cho hệ thống gọn gàng với những chức năng được thêm vào mà bạn đoán chúng sẽ được sử dụng sau này.

Có phải thiết kế đã chết?

,
Martin Fowler là diễn giả, nhà tư vấn và tác giả của rất nhiều sách có ảnh hưởng về phát triển phần mềm, thiết kế và phân tích hướng đối tượng, UML, mẫu thiết kế, các phương pháp phát triển phần mềm linh hoạt, và cả XP. Thấy được những băn khoăn của nhiều người mới bắt đầu thực hành XP và Agile về vai trò của thiết kế nên chúng tôi quyết định dịch một bài viết rất quan trọng của ông có tên “Có phải thiết kế đã chết?”

Tích hợp Liên tục (Continous Integration – CI)

,
CI (Continous Integration – tích hợp liên tục) là một quy trình / công cụ giúp nhóm phát triển ngay lập tức nhận diện được những ảnh hưởng của một commit (một đoạn code hay một chức năng được thêm vào) với toàn bộ hệ thống nhằm phản ứng tức thì để đảm bảo toàn hệ thống hoạt động như mong đợi.

Lập trình Cặp: chúng ta giúp nhau thành công

,
Lập trình Cặp (Pair-Programming) là cách hai lập trình viên cùng làm việc trên chỉ một máy tính, một người lái (driver), một người làm hoa tiêu (navigator), thú vị hơn bạn tưởng tượng nhiều. Việc hoán đổi vai trò liên tục giúp cho giao tiếp thông suốt, họ cùng nhau hoàn thành công việc tốt hơn và nhanh hơn khi họ làm một mình.

[XP] Khi phát hiện ra lỗi

,
Khi tìm ra một lỗi, bạn sẽ tạo kiểm thử để ngăn chặn lỗi đó tái xuất hiện. Thông thường thì một lỗi trong quá trình phát triển cần phải có một bản kiểm thử chấp nhận để ngăn chặn nó xảy ra.

6 hiểu nhầm về DevOps cần tránh

,
Chúng ta rất hứng khởi về sự phát triển của DevOps. Nhưng khi việc ứng dụng tăng lên, sẽ có những nhận thức khác nhau về DevOps. Chúng ta thấy điều này đang diễn ra.