Nếu bạn vừa được giới thiệu một dự án mới, điều đầu tiên bạn tìm kiếm để có ý tưởng về cách thức hoạt động của nó?
Bạn có tìm kiếm thiết kế đầu tiên? Nếu có một thiết kế, bạn tìm kiếm gì trong đó? Sơ đồ lớp hoặc sơ đồ triển khai hoặc sơ đồ trình tự hoặc cái gì khác?
Hay bạn đi thẳng cho mã? Nếu vậy, làm thế nào để bạn hiểu làm thế nào các lớp khác nhau tương tác?
Câu trả lời:
Tôi bắt đầu với mã. Các tài liệu thiết kế riêng biệt, nếu có, có khả năng bị sai hoặc hiểu sai là không. Vì vậy, tôi bắt đầu bằng cách cố gắng theo dõi một số dòng đơn giản thông qua mã; nếu đó là một ứng dụng web, ví dụ, đó có thể là một yêu cầu hoặc một chuỗi các yêu cầu. Khi tôi đã làm điều đó, tôi có một bộ xương để hiểu thêm. Sau đó, tôi có thể quay lại và đọc các thiết kế hoặc tài liệu khác, nhưng tại thời điểm đó, tôi có một cái gì đó cụ thể để liên hệ với chúng, và để xác nhận chúng với, vì vậy tôi có thể phát hiện thông tin duff. Hoặc tôi chỉ có thể tiếp tục đọc mã, hoặc các trường hợp thử nghiệm, vv
Tôi sẽ bắt đầu ở cấp độ cao hơn. Nếu có bất kỳ tài liệu phải đối mặt với người dùng - hướng dẫn sử dụng hoặc hướng dẫn. Thất bại trong đó có một cái nhìn vào các yêu cầu cụ thể để bạn có một số ý tưởng về những gì phần mềm phải làm. Tôi sẽ nhìn vào thiết kế và cố gắng ánh xạ nó lên các tệp mã. Hy vọng rằng chúng được cấu trúc thành các thư mục theo một cách hợp lý. Sau đó tôi sẽ chọn một phần của thiết kế và đi vào các tệp để theo dòng mã mà không bị sa lầy vào chi tiết tốt.
Tôi bắt đầu bằng cách thiết lập một hệ thống phát triển. Tôi sử dụng các thủ tục tài liệu. Điều này cho phép con mèo ra khỏi túi về bao nhiêu tài liệu đồng bộ với thực tế.
Nó cũng cho tôi biết những gì phụ thuộc là. Vấn đề này
Bây giờ tôi đã có một thiết lập dành cho nhà phát triển, (và tôi đánh dấu tài liệu thiết lập bằng các sửa chữa khi tôi đi) Tôi xây dựng một phiên bản. Tôi cuối cùng đặt câu hỏi tất cả thông qua giai đoạn này.
Bây giờ nó đã được xây dựng, tôi thực hiện bài tập giới thiệu từ hướng dẫn sử dụng. Điều này cho tôi biết khoảng những gì hệ thống thực sự làm.
Bây giờ tôi có một manh mối một phần về hệ thống, tôi đọc các tài liệu thiết kế, mà bây giờ tôi tin rằng tỷ lệ với các tài liệu đã sai cho đến nay.
Khi tôi nhận được tài liệu hành vi thực tế, tôi có thể bắt đầu xem mã và xem những gì thực sự ở đó. Họ không bao giờ xếp hàng, nhưng bây giờ tôi biết bao nhiêu để tin.
Sau đó, tôi nhìn vào đầu ra IDE cho các bình luận "todo" và "fixme". Những thứ như "sửa lỗi trong phiên bản 2.0" cũng vậy.
Vì vậy, đó là tất cả về việc tìm hiểu tính chính xác và như mọi người chỉ ra, các tài liệu thiết kế riêng biệt hiếm khi được cập nhật hoặc chính xác, nhưng nó cho bạn biết mọi người đang nghĩ gì tại một thời điểm. Và tất nhiên, những người đó có lẽ không ở quanh để thẩm vấn.
Sở thích của tôi là bắt đầu với thiết kế để có cái nhìn tổng quan về dự án và cố gắng hiểu một số tính năng và / hoặc cấu trúc chính của nó trước khi đi sâu vào chi tiết.
Luôn luôn là thiết kế. Với mã, đáng để thực hiện các bước thiết lập dành cho nhà phát triển (kiểm tra nguồn, xây dựng dự án, thực hiện bất kỳ thay đổi cấu hình nào được yêu cầu) nhưng không có điểm nào cố gắng tìm hiểu cấu trúc của ứng dụng từ mã của nó. Điều đó chỉ cho bạn biết cấu trúc là gì, chứ không phải tại sao cấu trúc đó hoặc những gì các nhà phát triển khác nghĩ rằng những điểm nổi bật và điểm xấu là của kiến trúc. Những người bạn học được từ các sơ đồ và trò chuyện với bảng trắng với các nhà phát triển.
Đối với một phần mềm phức tạp, tôi sẽ tiếp cận nó một cách đại khái như thể đó là một dự án phát triển mới. Bắt đầu với những ý tưởng lớn - tầm nhìn, bối cảnh, phạm vi, các bên liên quan. Đọc qua một số tài liệu người dùng và có được một ý tưởng về cách nó được sử dụng. Nhận một số đào tạo người dùng với phần mềm nếu có thể (hoặc áp dụng). Sau đó bắt đầu xem xét các yêu cầu và tài liệu thiết kế để có được ý tưởng về cách thức hoạt động ở mức cao. Nói chuyện với các nhà thiết kế nếu họ vẫn còn xung quanh. Nhìn vào kiến trúc hệ thống theo các quan điểm khác nhau. Từ đó, bắt đầu đào sâu vào chức năng cốt lõi và xem xét một số mã, quay lại các yêu cầu và thiết kế khi cần thiết. Khi bạn nhìn vào mã, hãy chạy phần mềm để thấy nó hoạt động. Trong khi đó, hãy biên dịch một số tài liệu tóm tắt để tham khảo trong tương lai - bạn sở hữu Cliffs Notes. Chi nhánh cho đến khi bạn có một ý tưởng khá hay về cách tất cả hoạt động và khớp với nhau, nhưng tập trung vào các phần mà bạn sẽ làm việc cùng. Đến bây giờ bạn đã có sự hiểu biết từ trên xuống dưới cho toàn bộ hệ thống, hoặc ít nhất là các bộ phận có thể áp dụng cho bạn.
Tất nhiên, trong thế giới thực, bạn có thể không có thời gian để trải qua tất cả những điều này trước khi bạn phải bắt đầu bẩn tay, đặc biệt là trong các dự án lớn hơn. Nhưng đây là cách tôi sẽ làm nếu nó tùy thuộc vào tôi.
Bạn nên làm việc qua lại giữa chính mã và bất kỳ tài liệu thiết kế nào.
Bạn có thể bắt đầu bằng mã hoặc thiết kế, và nó không thực sự quan trọng. Đọc mã cho đến khi bạn thấy ổn và thực sự bối rối, sau đó kiểm tra tài liệu thiết kế. Hoặc, đọc các tài liệu thiết kế để có được một bức tranh cấp cao sau đó nhìn vào mã để xem nó trông như thế nào. Lặp lại gần như vô thời hạn miễn là bạn đang làm việc với mã.
Xin lưu ý rằng các tài liệu thiết kế hầu như luôn lỗi thời và không chính xác theo nhiều cách. Tuy nhiên, miễn là bạn ghi nhớ những điểm này, tài liệu lỗi thời vẫn giúp bạn hiểu được suy nghĩ của tác giả vào một thời điểm nào đó trong quá khứ. Nhiều vấn đề và mối quan tâm cấp cao sẽ vẫn còn hiệu lực, và rất có thể bạn sẽ có thể nhanh chóng hiểu được mã đã đến nơi như thế nào, nếu bạn thậm chí là một bức tranh về ngày mà tác giả nghĩ rằng nó sẽ xảy ra đi.
Khi bạn làm việc thông qua mã và thiết kế, hãy tạo các tài liệu của riêng bạn mô tả sự hiểu biết của bạn về mã ngày hôm nay. Có thể các tài liệu này là một hoặc hai bản phác thảo đơn giản, có thể chúng là các bản viết trong wiki, có thể chúng là một thứ khác. Đừng làm cho chúng quá phức tạp: không có tài liệu từ 30 trang. Chỉ cần lấy ý tưởng của bạn xuống, sẽ làm rõ suy nghĩ của bạn rất nhiều.
Nó phụ thuộc vào loại ứng dụng. Nếu đó là một ứng dụng tập trung vào dữ liệu, tôi thường bắt đầu với thiết kế cơ sở dữ liệu. Nếu nó có giao diện người dùng, bạn có thể chạy (hoặc thiết kế màn hình tốt), những ứng dụng đó cũng có thể cho bạn ý tưởng tốt về những gì ứng dụng thực hiện rất nhanh (nhiều nhất tôi chỉ nói vài giờ ở đây). Sau đó tôi bắt đầu đào sâu vào mã và nó sẽ có ý nghĩa hơn bởi vì tôi biết ứng dụng đang làm gì.
Tôi bắt đầu với các tài liệu thiết kế. Cụ thể, đặc điểm kỹ thuật - cho biết ý định của sự việc đang được xem xét.
Nếu có thể, sau đó tôi xem các ghi chú thiết kế và tài liệu để có được một hương vị chung về cách nó đã được thực hiện, quá trình suy nghĩ, phong cách và bản chất của những người liên quan.
Nếu có thể tôi sẽ nói chuyện với những người đã làm việc với nó - nó làm gì? Làm sao? Tại sao? Xác chết ở đâu?
Có một xu hướng giữa các nhà phát triển nhảy vào mã: "Hãy để tôi chỉ cho bạn mã này". Điều này tốt cho họ nhưng có xu hướng chiếm đoạt nhu cầu của tôi - đó là hiểu mức độ cao mang lại bối cảnh cho những thứ cấp thấp.
Nó sử dụng một lượng lớn năng lượng não để xem xét các đoạn mã nhỏ, ra khỏi bối cảnh hoàn chỉnh và hiểu bất cứ điều gì có ý nghĩa. Vì vậy, nếu có thể, làm cho các nhà phát triển nói về NGUYÊN TẮC, cấu trúc, đơn vị, mô-đun, bất cứ điều gì đều dẫn đến sự đánh giá cao của nhiệm vụ.
Chỉ sau đó nó là giá trị cố gắng để có được vào mã.
Trong sơ đồ lớn của mọi thứ, nhìn vào mã giống như nhìn vào một trang có đầy đủ 0 và 1. Có ý nghĩa nhưng phải mất một thời gian dài để tìm ra nó. Có được một hương vị của nơi để tìm và phần nào có ý nghĩa giúp thu hẹp không gian tìm kiếm.
Tất cả những gì đã nói - khi không có tài liệu, không có người và chỉ có mã - thì không có gì cho nó ngoài việc xem mã.
Trong trường hợp đó, tôi thường không thử và hiểu nó bằng cách đọc sâu chậm, tôi lướt nhanh, đọc lướt qua mọi thứ. Đôi khi đây chỉ là mở tệp và ngồi nhấn phím xuống trang. Bạn có thể nhận được sự đánh giá cao tuyệt vời của một bức tranh lớn chỉ bằng cách làm điều này. (Và trong một số trường hợp, tôi thậm chí còn xâu chuỗi các tệp thực thi và truy tìm chúng, tìm kiếm chữ ký và mẫu. Điều này đã có kết quả đáng kinh ngạc trong 20 năm qua.)
Tôi bắt đầu với các bài kiểm tra. Nếu các bài kiểm tra đơn vị và kiểm tra tích hợp được viết tốt, chúng mô tả các trường hợp sử dụng. Nếu chúng không được viết tốt, hoặc hoàn toàn không được viết (đáng buồn thay, điều này phần lớn là như vậy), tôi bắt đầu với các điểm nhập trong mã và khớp với những điểm có thiết kế.
Sau đó, tôi sẽ viết các bài kiểm tra cho từng trường hợp sử dụng, được phát hiện bởi cây bạn sẽ tìm thấy sau khi điều tra các điểm nhập cảnh, để thăm dò mã và sử dụng các tiện ích bảo hiểm mã để xem tôi đang thiếu gì. Các xét nghiệm này cho tôi biết chính xác làm thế nào mã hoạt động.
Tôi luôn cố gắng để thêm giá trị cho một cái gì đó tôi nhìn vào; kiểm tra viết, làm sạch mã, tái cấu trúc các hàm lớn (20+ dòng).
Tôi thấy rằng việc tạo tài liệu một mình không thêm bất kỳ giá trị thực nào vào mã vì nó không bao giờ tương tác với mã.
tốt, "thiết kế" là gì? S READN SÀNG? một sơ đồ uml? bạn có thể làm một tài liệu thiết kế nửa chừng (và hầu hết làm), bạn không thể mã nửa chừng
bất kỳ thiết kế nào chỉ đơn giản là sẽ là một ý kiến , trong khi mã là thực tế
tôi sẽ chỉ đề cập đến các tài liệu thứ cấp khi tôi không thể hiểu lý do của mã
đọc mã là một kỹ năng thiết yếu cho một nhà phát triển. bạn cũng có thể học nó ngay bây giờ, dù sao bạn cũng sẽ không thấy nhiều tài liệu hữu ích trong sự nghiệp của mình
Sau đó, tôi nhìn vào README, TODO và Changelog của nhà phát triển. Nếu tôi không hiểu tại sao phần mềm được viết, nó được viết như thế nào và nó sẽ đi đâu ... Tôi không sử dụng nó.
Thiết kế đầu tiên, sau đó mã, từ trên xuống nếu bạn muốn, vì vậy tôi hiểu bối cảnh ở mọi cấp độ tôi phải làm việc.
Nhưng nếu tôi phải thực hiện một thay đổi rất cụ thể, như sửa báo cáo hoặc tính toán, tôi chỉ cần xem mã.
Cụ thể hơn, cách tiếp cận "thiết kế đầu tiên" của tôi là cách này:
Tôi bắt đầu với mô hình de domain nếu có, nếu không có mô hình nào tôi xây dựng ít nhất là mô hình cơ bản (điểm khởi đầu tốt là mô hình dữ liệu). Nó định nghĩa "glosary" của ứng dụng và mối quan hệ giữa các đối tượng (các lớp).
Nó hình ảnh "những đối tượng được xử lý" bởi ứng dụng.
Sau đó, tôi tìm mô hình ca sử dụng để tìm ra "quy trình nào được thực hiện" bởi ứng dụng, mặc dù tôi thích bản đồ quy trình nếu là bản đồ, hiển thị các chuỗi quy trình.
Sau đó tôi nên có một bức tranh đẹp về ứng dụng và sau đó tôi có thể đi thiết kế thay đổi.
Nhân tiện, câu trả lời trên là trong bối cảnh của các ứng dụng kinh doanh.
Mã không nói dối. Chắc chắn ý tưởng tốt để có được một cái nhìn tổng quan về dự án đầu tiên để hiểu những gì nó làm. Tuy nhiên, nếu nhiệm vụ của bạn là tìm hiểu chi tiết về cách thức hoạt động của dự án, thì việc xem mã, ít nhất là đối với tôi, giống như nhìn vào một mảnh ghép hình theo từng mảnh trừ khi mỗi lớp bạn nhìn vào, bạn sẽ thêm một lớp khác mảnh ghép hình. Nếu mã được cấu trúc tốt, bạn có thể thấy một mẫu hình thành từ tên của các lớp mà không cần điều tra xem lớp đó làm gì. Trong nhiều trường hợp, bạn có thể nhận được gợi ý và manh mối từ mã sẽ hỗ trợ bạn thêm.
Cuối cùng, bạn có được ý tưởng không thể chối cãi về những gì chương trình làm, một trò chơi ghép hình đã hoàn thành. Tài liệu có thể không đầy đủ hoặc không chính xác, nhưng mã không bao giờ nói dối. Tất cả điều này bạn có thể làm mà không cần tìm hiểu từng phương pháp riêng lẻ làm gì. Không phải ai cũng có thể tìm hiểu về một dự án theo cách này, nhưng nếu bạn thực hiện nó thường xuyên, nó sẽ dễ dàng hơn với bạn, chưa kể rằng bạn có thể nhận được ý chính của một ứng dụng cỡ trung bình trong một vài giờ học. Mặc dù tôi cho rằng tất cả đều được ưu tiên.
Sau khi tôi thấy mã của mô-đun / điểm quan trọng nhất của ứng dụng: nhìn thấy mã, tôi có thể xác minh tính tốt của thiết kế.
Thí dụ:
Bạn phải làm việc trong việc quản lý ứng dụng của một ứng dụng web về báo cáo tài chính.
Sau khi tôi đọc mã về thông báo, ứng dụng bắt đầu và kết thúc (đối với khóa có thể xảy ra trong db), quy trình tạo dữ liệu chính phải báo cáo, v.v. (ví dụ: trong việc lưu trữ khí, quy trình chính là về tính toán trữ lượng gas trong khu vực lưu trữ của khách hàng với việc cung cấp và bơm, quá trình thứ cấp là việc thanh toán theo dữ liệu được tính toán trước đó)
Tôi sẽ đi với thiết kế đầu tiên sau đó mã đồng thời. Nó rất quan trọng vì mỗi dự án đều khác nhau. Bạn cần đưa ra một kế hoạch và mức độ cao của quy trình xử lý từ A đến Z trước khi bạn có thể bắt đầu làm việc trên các mã đồng thời. Mọi quyết định được đưa ra đều phải được ghi lại để các nhóm khác (hoặc chính bạn) đang / đang phát triển mã sẽ biết bản cập nhật mới nhất và những gì đã được xác nhận.
Nếu có một tài liệu thiết kế cấp cao tốt, tôi sẽ sử dụng nó. Nó phải được súc tích và cập nhật. Nếu nó quá dài dòng hoặc lỗi thời, tôi sẽ tìm mã.
Tất nhiên, nó phụ thuộc vào dự án, phải không? Một dự án cực kỳ phức tạp hoặc nhiều mặt có lẽ được tiếp cận tốt hơn thông qua tài liệu (nếu tài liệu đủ vững chắc.)
Theo tôi, một mô-đun đơn giản hoặc ứng dụng đơn giản, hầu như luôn được tiếp cận tốt nhất ở cấp mã.
Không có câu trả lời đúng cho mọi tình huống!