Tôi nên hỏi nhóm phát triển trước trong cuộc họp duy nhất (1-3 giờ) của tôi?

Question

Có dự án Ruby on Rails (1.8, 2.3.2). Phiên bản đầu tiên của dự án đã được thực hiện bởi một số tổ chức. Tôi sẽ triển khai các phiên bản tiếp theo của dự án này mà không cần bất kỳ sự trợ giúp nào từ tổ chức này. Tôi sẽ có thể nói chuyện với các nhà phát triển từ nhóm phát triển trước đó trong cuộc họp (1-3 giờ).

thống kê dự án: ~ 10k LỘC, 1.0/0.6 mã để kiểm tra tỷ lệ, rspec

gì thắc mắc về dự án bạn có thể khuyên bạn nên yêu cầu?

Answer 1

Đầu tiên xem xét toàn bộ dự án và tìm ra càng nhiều càng tốt để bạn có ngữ cảnh và thực sự có thể hiểu những gì họ nói với bạn.

Hỏi

• Nếu bạn có thể ghi lại cuộc nói chuyện
• Để biết tổng quan kiến ​​trúc
• Tại sao họ làm quyết định kiến ​​trúc nhất định trên một
• Một danh sách đầy đủ các phụ thuộc (nếu bạn không thể hình theo cách của riêng bạn)
• Những vấn đề lớn nhất là
• Những phần nào của dự án luôn là/Không bao giờ được cố định
• gì gót chân Achilles của dự án là
• gì sẽ gây ra những cơn đau đầu lớn nhất
• vấn đề an ninh gì đang có và những gì khó khăn là để sửa chữa nó
• bạn sẽ làm gì tiếp theo nếu bạn là tôi?
• Những gì bạn nên biết rằng bạn đã không hỏi (câu hỏi quan trọng nhất)

Ngoài ra, không thể phán xét, bạn muốn họ để lộ ra bất kỳ vấn đề họ biết về. Có thể có rất nhiều điều sai trái với ứng dụng mà họ đang bối rối, mà bạn cần phải biết sớm hơn là sau này. Họ sẽ không mở ra cho bạn nếu họ không tin tưởng bạn.

Answer 2

Tôi sẽ yêu cầu hướng dẫn mã. Không phải từng dòng, nhưng nhiều hơn cho cấu trúc tổng thể của dự án, mối quan hệ giữa các mô-đun riêng lẻ, v.v.

Answer 3

Tìm hiểu lý do. Làm thế nào là dễ dàng, đủ để nhìn thấy trong codebase, nhưng tại sao đôi khi không thể tìm ra, và sẽ cắn bạn trong ass.

Ví dụ:

Phần nào của ứng dụng là vấn đề hiệu suất lớn nhất? Vấn đề nào đã được giải quyết? Đó vẫn là vấn đề?

Tại sao bạn chọn mẫu/công cụ/thư viện x? Bạn đã cân nhắc điều gì khác? Tại sao?

Điều này hy vọng. (Nhấn một số gỗ.) Giúp bạn tránh phải vượt qua cùng một đường cong học tập và những sai lầm mà đội đầu tiên phải đối phó, và sẽ cung cấp cho bạn cái nhìn sâu sắc về nơi đội đầu tiên thực sự lựa chọn kém, thay vì thực hiện lựa chọn dựa trên các yếu tố bạn chưa tính đến.

Answer 4

Hỏi xem các tính năng mới có gây ra bất kỳ thay đổi lớn nào đối với mã hiện có (kiến trúc) hay không và ý nghĩa của nó với các phần phụ thuộc khác của ứng dụng.

Cũng nhận được email của họ, vì bạn sẽ có thêm câu hỏi.

Answer 5

Một trong những điều quan trọng nhất, theo ý kiến ​​của tôi, là nhận được nhiều tài liệu kỹ thuật nhất có thể trước khi gặp họ. Bạn nên cố gắng đi vào cuộc họp càng được thông báo càng tốt, để bạn không chỉ biết những lĩnh vực nào bạn cần tập trung nhiều nhất, mà còn phải có kiến ​​thức từ trước về cách một số hệ thống con liên quan với nhau.

Ngoài ra, đừng ngại hỏi họ sẽ làm gì khác, nếu có cơ hội. Một số ý tưởng hay nhất đến quá muộn trong quá trình phát triển sẽ được triển khai - có thể là do tính khả dụng của thư viện, thay đổi yêu cầu, thay đổi đội ngũ, v.v.

Answer 6

Mang cookie (hoặc pizza, bia hoặc rượu nếu thích hợp); bạn sẽ muốn họ có những kỷ niệm tích cực về bạn khi bạn gọi với những câu hỏi.

Chỉnh sửa: để đặt câu trả lời của tôi dưới dạng câu hỏi: "Tôi có thể cung cấp cho bạn cookie được nướng tại nhà không?"

Answer 7

Có lẽ bạn đã làm điều này rồi, nhưng tôi sẽ đảm bảo bạn có thể:

• Thanh toán phiên bản mới nhất
• Chạy tất cả các cuộc di cư
• Chạy tất cả các bài kiểm tra
• Triển khai (ngay cả khi tới máy chủ dàn dựng)
• Chạy ứng dụng cục bộ

Trước khi bạn đi đến cuộc họp, vì vậy bạn có thể chắc chắn rằng bạn có thể vào thời điểm kết thúc.

Answer 8

Những thứ khác mà có thể có ích

• mô hình dữ liệu
• wireframes UI
• dữ liệu theo dõi lỗi/dữ liệu theo dõi vấn đề
• người là những khách hàng/người đại diện cho khách hàng
• cấu hình môi trường phát triển
• vị trí kiểm soát nguồn, v.v.
• giải thích về cài đặt cấu hình đặc biệt

Answer 9

Wow! Tất cả các câu trả lời tuyệt vời, phải xuống đến các tập tin cookie.

đóng góp của tôi cho rằng đây là một trong của bạn và chỉ có cơ hội để truy cập vào nhóm dev cũ, do đó bạn cần phải kick nó lên một notch:

1. Agenda. Chia họp thành nhiều phần, ví dụ:

   • Một cách nhanh chóng (15 phút) giới thiệu và tổng quan vòm
   • Một ngày một với thành viên trong nhóm.
   • thiết kế xem xét như một nhóm, vv

2. Positive Energy. Đặc biệt là nếu mối quan hệ vốn khó khăn, hãy tập trung tích cực bằng cách postulating: những cải tiến nào bạn sẽ đưa vào phiên bản tiếp theo - (viết lại không phải là một lựa chọn, đúng Joel) - nắm bắt mọi sắc thái, và đi sâu hơn mức độ thoải mái của họ chỉ gần hơn kết thúc.

3. Trình điều khiển. Sử dụng một người điều phối cuộc họp thiết kế được đào tạo. Họ có thể giúp chuẩn bị cho cuộc họp, tiến hành phỏng vấn trước cuộc họp, thiết kế chương trình nghị sự. Trong cuộc họp, họ có thể điều khiển cường độ và tập trung. Họ cũng có thể đề xuất các hình thức nắm bắt những gì có thể là một số tiền hợp lý của thông tin.

Ngoài ra, tôi sẽ cố gắng xác định tất cả các tạo tác thiết kế ngoài mã, nếu có và tìm hiểu chính xác nó như thế nào. Điều này có thể bao gồm việc đánh giá thiết kế các yếu tố chính của các tài liệu này để xem xét hệ thống được xây dựng như thế nào.

Don