Hướng dẫn lập trình

Hướng dẫn lập trình thực hành với ví dụ rõ ràng cho Python, C++ và JavaScript. Nâng cao kỹ năng thiết kế, kiểm thử và hiệu năng.

Tích hợp Salesforce: giới hạn, nguyên tắc và chi phí thật

Một tích hợp Salesforce gần như không bao giờ hỏng vì giao thức. Xác thực là bài toán đã giải, ghi một bản ghi cũng vậy. Thứ kết liễu dự án là hạn mức yêu cầu mỗi ngày và hình dạng mô hình dữ liệu, cả hai thường lộ ra khoảng ba tuần sau khi lên sản xuất, khi tác vụ đêm bắt đầu trả lỗi và không ai giải thích nổi vì sao...

Phát triển plugin WordPress trụ được qua cập nhật lõi

Phần lớn dự án phát triển plugin WordPress đều đi theo một quỹ đạo giống nhau. Ai đó cần một biểu mẫu đặt lịch, một trình nhập dữ liệu hay thêm một trường ở trang thanh toán, lập trình viên viết ra, nó chạy được, rồi mọi người chuyển sang việc khác. Hai năm sau, website mắc kẹt ở một phiên bản WordPress cũ vì không ai...

Postmortem sự cố tạo ra thay đổi thật sự

Một buổi postmortem thì dễ tổ chức và khó làm cho hữu ích. Cuộc họp diễn ra, một tài liệu được viết ra, bốn hạng mục hành động được ghi lại, rồi sáu tháng sau chính sự cố đó lặp lại trong lúc ai đó tình cờ tìm thấy tài liệu cũ khi đang kiếm một thứ khác. Cụm từ không đổ lỗi chiếm gần hết sự chú ý trong các cuộc thảo...

Tài liệu kỹ thuật thực sự được đọc

Tài liệu kỹ thuật thất bại theo một cách rất cụ thể và rất dễ đoán. Ai đó viết thật nhiều trong hai tuần rảnh rỗi, rồi hệ thống thay đổi, không ai cập nhật lại, và trong vòng một năm tài liệu đó khẳng định những điều sai một cách đầy tự tin. Từ thời điểm ấy nó còn tệ hơn là không có gì, vì người tin vào nó sẽ hành động...

Onboarding lập trình viên hiệu quả ngay tuần đầu

Onboarding lập trình viên thường được đo bằng độ dài của buổi tiếp nhận thủ tục, và đó là đầu sai của vấn đề. Con số đáng quan tâm là một con số khác: bao lâu thì một kỹ sư mới có thể thay đổi một thứ gì đó mà vẫn chắc chắn mình không làm hỏng thứ khác. Ở phần lớn các nhóm, con số đó được tính bằng tháng chứ không phải...

Ký quỹ mã nguồn: ai thực sự cần đến nó

Ký quỹ mã nguồn, thường gọi theo thuật ngữ tiếng Anh là software escrow, tồn tại để trả lời một nỗi lo chính đáng: nhà cung cấp đã xây dựng và đang vận hành hệ thống trọng yếu của bạn biến mất khỏi thị trường, còn bạn ở lại với một thứ mà bạn phụ thuộc vào nhưng không thể bảo trì. Hợp đồng ký quỹ giao mã nguồn cho một...

Hợp đồng trọn gói hay time and materials?

Lựa chọn giữa hợp đồng trọn gói và time and materials thường được đóng khung như một lựa chọn về rủi ro, điều đó đúng, rồi ngay sau đó bị xử lý sai, vì cả hai bên đều mặc định rằng rủi ro biến mất thay vì chỉ chuyển chỗ. Rủi ro không biến mất. Trong thỏa thuận trọn gói, nhà cung cấp gánh rủi ro ước lượng sai và tính...

Phiên bản API: khi nào nên phá và cách không phá

Các cuộc tranh luận về phiên bản API hầu như luôn bắt đầu từ đầu sai, tức là từ chỗ đặt số hiệu phiên bản. Đó là quyết định ít hệ quả nhất trong toàn bộ chủ đề. Điều thực sự quan trọng là thay đổi nào mới cần đến một phiên bản mới, và phần lớn đội ngũ sai lầm theo hướng chủ quan: họ phát hành thứ mà họ tin là chỉ bổ...

RFP phần mềm: cách nhận báo giá so sánh được

Một bản RFP phần mềm, tức yêu cầu chào giải pháp, lẽ ra phải làm cho các nhà cung cấp trở nên so sánh được với nhau. Phần lớn lại đạt kết quả ngược lại, vì chúng mô tả một giải pháp đủ chi tiết để trói buộc câu trả lời, trong khi bỏ sót đúng những thông tin mà bất kỳ ai cũng cần để tính ra con số. Kết quả là năm bản...

Chi phí bảo trì phần mềm: khoản không ai dự trù

Chi phí bảo trì phần mềm là con số biến một dự án thành công thành cuộc trò chuyện khó khăn mười tám tháng sau đó. Phần xây dựng đã được lập ngân sách, phê duyệt và bàn giao. Còn những gì xảy ra sau khi hệ thống lên sóng thì được gọi gọn là “hỗ trợ” và gán cho một con số ai đó đoán ra, và con số ấy gần như luôn quá...