Tôi nên lập kế hoạch và bắt đầu một dự án như thế nào?

Mỗi khi tôi bắt đầu một dự án, tôi quyết định vào những thời điểm quan trọng để thay đổi hoàn toàn các lớp cốt lõi và bị cuốn vào những lỗi tối nghĩa. Tôi cố gắng lên kế hoạch nâng cao và thường bắt đầu từ một chân tốt nhưng sau đó tôi đi đến một ngày khác và quyết định tôi muốn làm điều đó 'một cách khác'.

Có một tiêu chuẩn nào, khi bắt đầu một dự án như vạch ra các lớp và bắt đầu với các bài kiểm tra đơn vị không? Một quy ước tốt khi lập kế hoạch và bắt đầu một dự án vừa.

Dự án cuối cùng và bắt đầu là một mô phỏng chuyển động phóng - tôi biết, có thể dự đoán được.

Khi bạn lập kế hoạch, đừng lên kế hoạch trước mọi điều có thể về ứng dụng. Lập kế hoạch trong các bước bé. Là gì chức năng tối thiểu tuyệt đối bạn cần phải bắt đầu sử dụng các ứng dụng? Bắt đầu từ đó

Khi bạn bắt đầu dự án của mình, chỉ mã ra chức năng tối thiểu tuyệt đối. Khi bạn viết mã ra, hãy chắc chắn rằng bạn đang viết mã tốt, sạch với đóng gói thông minh . Điều này sẽ giảm thiểu các lỗi xuất phát từ việc thay đổi sau này.

Lặp lại chức năng tối thiểu đó cho đến khi bạn hài lòng với nó. Sau đó bắt đầu thêm các chức năng và cải tiến mới, từng cái một. Một lần nữa tập trung vào viết mã tốt, sạch với đóng gói thông minh.

Nếu bạn lập kế hoạch theo các bước bé và viết mã sạch, nó sẽ giảm thiểu số lượng thay đổi bạn thực sự cần thực hiện. Khi bạn viết xong tính năng đầu tiên đó, bạn sẽ chấp nhận các mẫu mà nền tảng ứng dụng của bạn sẽ sử dụng. Nếu có vấn đề với nền tảng đó, các tính năng tiếp theo của bạn sẽ nhanh chóng tiết lộ vấn đề. Nó sẽ dễ dàng hơn để xem làm thế nào mảnh tích hợp với nhau. Những thay đổi bạn thực hiện nên, tại thời điểm này, gây ra sự gián đoạn tối thiểu.

Có vẻ như kế hoạch của bạn không giúp được gì. Điều đó không có gì đáng ngạc nhiên vì bạn không có đủ kinh nghiệm để lập một kế hoạch khả thi. Giải pháp rất đơn giản. Dừng kế hoạch quá nhiều. Chỉ cần chấp nhận rằng bạn sẽ viết và viết lại mã khi bạn đi. Điều đó ổn, bởi vì mã là miễn phí, ngoại trừ thời gian của bạn. Nếu bạn đang viết một ứng dụng UI, chỉ cần bắt đầu với một cửa sổ trống và thêm một chút cho đến khi bạn hoàn thành. Khi bạn có nhiều kinh nghiệm, các dự án của bạn sẽ đi nhanh hơn. Lo lắng vì bạn đang thay đổi mã giống như một sinh viên âm nhạc lo lắng về tất cả các ghi chú bị lãng phí trong thực tế.

Không ai thực sự biết thiết kế tốt nhất sẽ là gì cho đến khi họ đã mã hóa một số lượng nhất định của nó. Do đó, bí quyết để thiết kế tốt là nhận ra rằng bản nháp đầu tiên của bạn chắc chắn là không tối ưu, và có kế hoạch viết lại các phần nhỏ hơn sớm hơn và thường xuyên hơn . Thay vì loại bỏ một chương trình gần như hoàn chỉnh, hãy viết lại các dòng hoặc hàm hoặc lớp ngay khi bạn nhận ra thiếu sót của chúng.

Các lập trình viên giàu kinh nghiệm thường không hiểu nó ngay trong bản thảo đầu tiên. Những gì đi kèm với kinh nghiệm là khả năng nhận ra một thiết kế xấu sớm hơn và khả năng viết lại nhanh hơn.

Theo kinh nghiệm của tôi, vấn đề này sẽ biến mất khi bạn có thêm một số kinh nghiệm - bạn có cảm giác về những gì hoạt động và những gì không. Ngoài ra, đóng gói tốt có thể giảm chi phí thay đổi thiết kế. Các mô-đun của bạn được đóng gói càng chặt chẽ thì càng rẻ để thay đổi sau này. Hãy coi đó là một động lực tuyệt vời để giữ cho các lớp học của bạn tách biệt.

http://nathanmarz.com/blog/suffering-oriented-programming.html

Điều này giải quyết vấn đề của bạn. Ông bắt đầu bằng cách đơn giản là đảm bảo rằng phần mềm là có thể, tạo mẫu và tạo ra nó. Sau đó, anh ta bắt đầu lấy mã và phá vỡ nó. Sau đó, anh tối ưu hóa nó.

Có hai khía cạnh để thiết kế một ứng dụng. Đầu tiên là quyết định những gì ứng dụng của bạn có thể làm. Thứ hai là thiết kế làm thế nào để làm điều đó. Những thay đổi đối với những gì nó làm là khá quan trọng và tùy thuộc vào sự trưởng thành của ứng dụng (và sự thay đổi hướng của ứng dụng) được tiếp cận tốt nhất dưới dạng viết lại thay vì làm lại.

Khía cạnh thứ hai là làm thế nào. Sử dụng thử nghiệm đơn vị và thực hành phát triển nhanh, bạn có thể giảm thiểu tác động của việc thay đổi cách thực hiện một chức năng cụ thể thông qua tái cấu trúc. Một phần của việc học cách tận dụng những kỹ thuật đó là thực hành thực hành.

Tôi sẽ đưa ra lời khuyên tôi đã dành thời gian và thời gian một lần nữa. Chọn một dự án thú cưng. Viết nó với khả năng tốt nhất của bạn. Học một cái gì đó mới và áp dụng những gì bạn đã học để cải thiện cách bạn tiếp cận phát triển dự án đó.

Ví dụ, bắt đầu với một danh sách Todo. Làm cho nó đơn giản ... thậm chí không lo lắng về việc lưu trữ cơ sở dữ liệu lúc đầu. Chỉ cần làm cho nó hoạt động. Bây giờ bắt đầu xây dựng trên nền tảng đó. Có thể bạn muốn tìm hiểu MVVM và WPF ... bạn đã biết cách triển khai danh sách việc cần làm trong bộ nhớ, vì vậy bạn có một vấn đề ít hơn để giải quyết. Bây giờ bạn muốn đặt nó ở nơi nhiều người dùng có thể tải danh sách việc cần làm của họ từ cơ sở dữ liệu. Bạn đã giải quyết trong bộ nhớ và trình bày riêng biệt, vì vậy bạn có thể tập trung vào việc truy cập dữ liệu. Từ đó, bạn có thể mở rộng ứng dụng để có một mô hình miền phức tạp hơn (ví dụ: thay đổi từ danh sách Todo sang giải pháp quản lý dự án), giao diện web hoặc thậm chí làm cho nó chạy trên thiết bị di động. Chìa khóa để thực hiện công việc này là chọn một thứ gì đó có thể hoàn thành bởi bạn mà bạn có thể đánh dấu tiến bộ và bạn có thể phát triển theo thời gian.

Theo kinh nghiệm của tôi, thiết kế hệ thống thường mất nhiều thời gian hoặc lâu hơn so với mã hóa thực tế. Khi bạn nói "lập kế hoạch trước", bạn thực sự có kế hoạch gì? Có thể đi học cũ và sử dụng một trong những phương pháp thiết kế đã thử và thử nghiệm. Hoặc đi học cũ và viết mã giả trước khi viết mã thực tế.

Tôi nghĩ bạn phải tự hỏi tại sao bạn lại thay đổi mọi thứ vào những thời điểm quan trọng thay vì gắn bó với kế hoạch ban đầu. Là kế hoạch ban đầu còn thiếu sót? Hoặc bạn đã có một khoảnh khắc sâu sắc cho thấy một cách tốt hơn để làm mọi thứ. Nó thực sự tốt hơn hay chỉ khác nhau?

Khi bạn đạt được exp, bạn sẽ cần phải viết lại / cào và bắt đầu lại, ít thường xuyên hơn. Viết ra vấn đề bạn đang cố gắng giải quyết. Viết ra những mô tả lớp mơ hồ mà bạn nghĩ rằng bạn sẽ cần, viết lên cách thức sẽ cần phải tương tác. Nhận một ý tưởng về cách mọi thứ sẽ làm việc sau đó mã. Đừng dành hàng tấn thời gian để viết ra mọi tài sản, phương pháp của các lớp học của bạn. Ở giai đoạn này, bạn đang cố gắng để có được góc nhìn 50 nghìn về những gì bạn phải làm. Một khi bạn bắt đầu viết mã nếu bạn cần viết chi tiết hơn, hãy tìm nó. Nếu không chỉ bắt đầu mã hóa.

Lý do bạn thấy điều này rất khó là vì bạn có một ý tưởng, nhưng bạn không thực sự có một ý tưởng hoàn chỉnh những gì bạn muốn nó làm. Nếu bạn đang thực hiện dự án của riêng mình và bạn không có khách hàng để cho bạn biết họ muốn gì, thì bạn phải là khách hàng của riêng bạn. Đặt mình vào vị trí của khách hàng và bắt đầu xây dựng một danh sách mong muốn không thể.

Nói cách khác, khi bạn bắt đầu Đừng thiết kế BẤT CỨ NÀO !!! .

Khi bạn có một danh sách lớn những việc bạn muốn hệ thống thực hiện, hãy ưu tiên mọi thứ và quyết định chức năng tối thiểu sẽ là gì để hệ thống cơ bản hoạt động. Đây có thể là một chức năng cơ bản duy nhất hoặc toàn bộ màn hình, nhưng nó cần phải là một cái gì đó bạn cảm thấy - vì khách hàng sẽ đủ hữu ích để kiểm tra.

Vì vậy, danh sách mong muốn của các tính năng + ưu tiên cơ bản = Yêu cầu .

Một khi bạn có tất cả những điều đó, hãy làm một thiết kế cấp cao. Chỉ cần ngồi và suy nghĩ về những gì hệ thống của bạn sẽ cần để có được một vài ưu tiên đầu tiên và chạy. Thay đổi suy nghĩ của bạn nếu bạn muốn, nhưng đây là nơi bạn có thể muốn tăng đột biến một số mã hoặc cấu hình hệ thống để tìm hiểu thêm về những gì có thể. Chỉ đi đủ xa để xác nhận ý tưởng cơ bản của bạn về một thiết kế.

Tức là: NGAY BÂY GIỜ bạn có thể thưởng thức các nhà thiết kế của bạn thôi thúc .

Sau khi hoàn thành, bạn bắt đầu thực hiện các tính năng của mình. Tạo cho mỗi tính năng một đặc tả chức năng cơ bản. Điều này có thể đơn giản như một bộ sưu tập các báo cáo tính năng. Câu chuyện thẻ nếu bạn thích. Điều này cho phép bạn phát triển ý tưởng của mình một chút và tạo ra một tập hợp các câu lệnh sẽ trở thành đặc tả mà bạn sẽ kiểm tra và xây dựng triển khai của mình.

Khóc Havoc, hãy trượt những con chó của ... Code !!

Từ đó, thực hiện các thử nghiệm của bạn để phù hợp với thông số kỹ thuật của bạn, sau đó cho mỗi thử nghiệm, hãy viết mã của bạn. Xây dựng, "phát hành", sau đó lặp lại với tính năng tiếp theo cho đến khi bạn quyết định dự án hoàn thành đủ.

Nó thực sự có kinh nghiệm, nhưng cách tiếp cận này tôi đã tìm thấy là một công thức đơn giản để giúp bạn tập trung tâm trí vào những việc cần làm, thay vì bị nhốt vào một chu kỳ trì hoãn vô tận do cố gắng làm quá nhiều Một lần.

Sau khi bạn đã thực hiện các điều cơ bản như thiết lập mục tiêu dự án, nhận danh sách các yêu cầu của bạn và khóa bất kỳ giao diện nào với các hệ thống bên ngoài.

Sau đó, bạn cần thực hiện một ca sử dụng hoặc "câu chuyện" cho mọi tương tác của người dùng. Các tập đã được viết về những gì làm cho một trường hợp hoặc câu chuyện sử dụng "tốt" và có nhiều biến thể. Các trường hợp sử dụng là công cụ thiết kế hiệu quả nhất mà tôi đã gặp. Chúng giúp nhận chức năng bị thiếu đồng thời loại bỏ các yêu cầu không cần thiết và loại bỏ thiết kế của bạn xuống các yếu tố cần thiết. Như tôi đã nói các phương pháp khác nhau nhưng hầu hết các nhà quảng cáo đều đồng ý về: -

• văn bản tiếng Anh ngắn gọn súc tích.
• "Mục tiêu hướng" hoạt động tốt nhất tức là "Khỉ lấy một quả nho" tốt hơn "Khỉ đẩy nút đỏ".
• cấm thuật ngữ kỹ thuật. Không có "pulldowns", "hộp văn bản". Một trường hợp sử dụng tốt nên độc lập với bất kỳ công nghệ giao diện nào. Bạn sẽ có thể sử dụng trường hợp sử dụng cho hệ thống dựa trên HTML và sử dụng nó cho hệ thống kích hoạt bằng giọng nói mà không có bất kỳ thay đổi nào đối với trường hợp sử dụng. (điều này rất khó để làm nhưng đáng giá!).
• Nhằm mục đích giảm 50% số từ của bản nháp đầu tiên của bạn, loại bỏ bất kỳ bước và thông báo không cần thiết nào.

Hơn bạn đã sẵn sàng để chỉ định các lớp học chính của bạn:

UML- Ngôn ngữ mô hình hóa phổ quát. Là công cụ tiêu chuẩn để thiết kế các lớp học. Bạn chỉ định các thành viên công khai và phương thức của mỗi lớp và liên kết chúng lại với nhau trong một mô hình đồ họa rõ ràng.

Kết hợp với sơ đồ trình tự, mô hình dữ liệu, bạn có thể xác minh và cải thiện thiết kế của mình trước khi bất kỳ mã hóa nào diễn ra.

Thay đổi sự tập trung của bạn vào kết quả mà bạn muốn đạt được và cân nhắc lợi ích tiềm năng của việc học / thử thực hiện mới với nguy cơ đi xuống một con đường khiến bạn quay trở lại tại quảng trường.

Trong trường hợp bạn kết thúc tại một hình vuông, tất cả sẽ không bị mất vì bạn đã có kinh nghiệm.

Nếu bạn có thời hạn (nghe có vẻ như bạn đang lập trình cho vui) thì điều này thực sự khó khăn. Nếu bạn liên tục đi một chiều, bạn có nguy cơ sử dụng các phương pháp lỗi thời khi thời gian trôi qua. Nếu bạn liên tục đi theo con đường khác, bạn có nguy cơ gây ra hậu quả của việc sản xuất đầu ra với tốc độ chậm hơn (tốc độ chậm hơn tùy thuộc vào kết quả của cuộc phiêu lưu học tập của bạn).

Tôi đã từng làm rạo rực công việc, hoàn thành công việc nhanh chóng sau năm năm, và rồi một ngày tôi nhận ra mình đang trở nên không hiện tại trong bộ kỹ năng của mình.