Mẹo hay kỹ thuật để sử dụng khi bạn không biết cách viết mã? [đóng cửa]

Tôi có một nền tảng là nhà thiết kế UI. Và tôi nhận ra rằng hơi khó để tôi viết một đoạn logic. Đôi khi tôi hiểu đúng, nhưng hầu hết thời gian, tôi kết thúc với một cái gì đó hacky (và nó thường mất rất nhiều thời gian). Và không phải là tôi không thích lập trình, thực tế, tôi bắt đầu thích nó nhiều như thiết kế. Chỉ là đôi khi tôi nghĩ rằng tôi tốt hơn trong việc xử lý màu sắc một hình dạng, thay vì số và logic (nhưng tôi muốn thay đổi điều đó).

Những gì tôi thường làm là tìm kiếm giải pháp trên Internet, sao chép ví dụ và chèn nó vào ứng dụng của tôi (tôi biết đây không phải là một cách thực hành tốt).

Tôi đã nghe nói rằng một mẹo là viết logic bằng tiếng Anh thông thường dưới dạng nhận xét trước khi viết mã thực tế.

Những mẹo và kỹ thuật khác tôi có thể sử dụng?

Bước chân em bé.

Phá vỡ một vấn đề lớn thành những vấn đề nhỏ hơn. Sau đó giải quyết các vấn đề nhỏ hơn.

Điểm thưởng nếu bạn có thể sao lưu các giải pháp của mình cho các vấn đề nhỏ hơn bằng các bài kiểm tra đơn vị tự động.

Tôi thường viết mọi thứ ra giấy trong khi tôi đang suy nghĩ mọi thứ. Bằng cách đó, tôi có thể viết mã giả hoặc thực hiện các bản vẽ (thường là cả hai) và tôi không phải lo lắng về những hạn chế của phần mềm vẽ hoặc những gì có thể phù hợp với nhận xét.

Tôi thấy rằng nếu tôi đang làm một cái gì đó ít nhất là phức tạp nhẹ, tôi thực sự cần phải đưa mọi thứ xuống giấy trước, nếu không tôi sẽ kết thúc với một cái gì đó hacky, như bạn đã đề cập.

Nếu tôi kết thúc với một cái gì đó hacky, nó thường gần như hoạt động. Đôi khi tôi có thể hack nó cho đến khi nó cuối cùng cũng hoạt động, đôi khi thì không. Nếu tôi dành thời gian để viết nó ra giấy, nó thường hoạt động mà không gặp quá nhiều khó khăn.

Tôi nghĩ rằng bạn đã trả lời câu hỏi của riêng mình và tôi không có ý nói theo cách xấu - đó là một lời khuyên phổ biến rằng cách tốt nhất để học cách viết mã chỉ đơn giản là viết mã. Cá nhân tôi sẽ cố gắng tránh sao chép mã trực tiếp từ một nguồn trừ khi nó hoàn toàn rõ ràng về những gì đang diễn ra (nghĩa là, không nhất thiết phải có một cách tốt khác để làm gì đó), mặc dù nhiều vấn đề như vậy là cú pháp. Dành thời gian để hiểu những gì đang diễn ra và làm thế nào bạn (hoặc người khác) đang thực hiện nó là vấn đề quan trọng nhất.

Trong thời gian tôi học cách phát triển, tôi đã thấy rằng làm việc với các công nghệ MVC là một cách tuyệt vời để hiểu cách thiết kế, chẳng hạn như Rails (những gì tôi đang làm việc với ngay bây giờ) hoặc iOS / Cocoa Touch . Bởi vì bạn đang làm việc trong một môi trường thiết kế hướng đối tượng như vậy, một khi bạn bắt đầu suy nghĩ về các mô hình và logic của chúng bị tách khỏi chế độ xem (với các bộ điều khiển là chất keo gắn kết chúng), bạn cũng bắt đầu suy nghĩ về cách thức bạn có thể giữ cho các đối tượng của mình được trừu tượng hóa một cách hợp lý, nhưng (hy vọng!) không phức tạp.

Điều này dựa trên kinh nghiệm của riêng tôi, tất nhiên, nhưng tôi hy vọng những suy nghĩ của tôi về câu hỏi của bạn có thể giúp ích được gì đó.

Ngoài các câu trả lời đã được đưa ra, một trong những cách tốt nhất để bắt đầu nhảy là tìm hiểu từ một ứng dụng đơn giản và nơi có sẵn mã nguồn.

Đây là nơi các kho lưu trữ xã hội như Github tỏa sáng. Một nơi đáng kinh ngạc để duyệt qua cho ví dụ. Và khi bạn tìm thấy một cái, bạn có thể lập tức chọn nó là của riêng bạn và làm những gì bạn muốn cho ứng dụng, vì vậy một khi bạn đã có nó:

• bạn có thể chạy nó
• điều chỉnh nó ở đây và ở đó và xem mọi thứ thay đổi như thế nào
• khi bạn cảm thấy thoải mái hơn, bạn thực hiện những thay đổi lớn hơn
• bạn sẽ sớm thấy bạn đang thực sự học

Một lựa chọn khác là sử dụng các triển khai tham chiếu ví dụ cổ điển được ghi lại ở nhiều nơi khác nhau. Ví dụ, khung công tác Spring của Java sử dụng ví dụ "Cửa hàng thú cưng" đáng kính. Tôi nghĩ bạn thậm chí có thể tìm thấy ví dụ đó trên Github.

Các khung / công nghệ khác như khung Grail của Groovi sử dụng các tác phẩm kinh điển khác như ứng dụng Sách để duy trì và xem Sách và Tác giả, v.v.

Tùy chọn cuối cùng mà tôi đã thử là theo dõi một cuốn sách lập trình tốt và bắt đầu nhập các ví dụ bằng tay và đưa chúng vào một kho lưu trữ như Github; điều này có ít nhất hai lợi ích: 1) có một tài liệu tham khảo cho bạn với những ghi chú của riêng bạn sẽ giúp bạn ghi nhớ những điều hay ho theo cách mà bạn sẽ nhớ và 2) nếu bạn gặp khó khăn, bạn có thể dễ dàng nhờ bạn bè hoặc đồng nghiệp xem mã của bạn và kêu vang với lời khuyên.

Khoa học và đặc biệt là lập trình thực sự được xây dựng dựa trên kinh nghiệm của người khác. Nói một cách hình tượng, sao chép / dán và sau đó điều chỉnh cho đến khi bạn hiểu là những gì giúp các nhà phát triển trở thành kỹ sư.

Hãy tưởng tượng bạn phải làm một báo cáo về vấn đề của bạn cho người khác.
Phân tích vấn đề. Cố gắng xây dựng nó rõ ràng như bạn có thể. Viết mã giả, vẽ sơ đồ.
Hãy suy nghĩ về những gì có thể gây ra vấn đề và tại sao cách tiếp cận của bạn là sai.
Tự hỏi bản thân nếu có bất kỳ quan điểm nào khác mà bạn có thể xem vấn đề của mình.
Đừng chỉ làm điều đó trong tâm trí của bạn, hãy đặt nó trên giấy (hoặc một tài liệu trên máy tính của bạn).

Nếu không điều gì giúp bạn ngay lập tức, hãy cố gắng không suy nghĩ về vấn đề này trong một thời gian. Chúc bạn ngủ ngon Vẫn không có giải pháp? Hãy thử giải quyết vấn đề của bạn hoặc tìm kiếm giải pháp SO.

Nếu vẫn thất bại, hãy đặt câu hỏi trên SO (hoặc Lập trình viên SE nếu nó phù hợp hơn với câu hỏi cụ thể của bạn). Hãy chắc chắn thực sự bao gồm "báo cáo" của bạn (hoặc các phần quan trọng của nó) khi đặt câu hỏi.
Khi bạn nhận được câu trả lời, hãy tự hỏi tại sao cách tiếp cận của bạn không hiệu quả và điều gì có thể giúp bạn tự mình đi đến giải pháp. Nó có thể giúp bạn tìm ra giải pháp cho một số vấn đề bạn gặp phải trong tương lai đòi hỏi một cách tiếp cận tương tự.

Tôi đồng ý với suy nghĩ trên giấy. Theo quy định, trước tiên tôi xác định mọi mục thông tin mà tôi sẽ cần và nơi nó sẽ đến từ đâu. Nó không cần phải thanh lịch, chính xác. Câu hỏi logic kinh doanh và chiến lược thiết kế thường đến trong quá trình này.

Cùng với đó, với tư cách là một nhà phát triển java làm việc từ đầu đến cuối trên một ứng dụng, tôi tiếp tục phân chia mọi thứ theo các bậc: trình bày, web, logic nghiệp vụ và lớp truy cập dữ liệu. Khi tôi có thời gian, tôi thường viết tên lớp của mình trong phần này.

Cuối cùng, tôi luôn nỗ lực để chạy thử nghiệm cho phần cuối, trước khi tôi viết mã. Bạn có thể kết nối mọi thứ một cách thanh lịch, nhưng nếu bạn không thể nhấn vào mặt sau: ví dụ: cơ sở dữ liệu hoặc dịch vụ web, nó sẽ không hoạt động!

Một số nguyên tắc phát triển dựa trên thử nghiệm giúp ích rất nhiều ở đây.

Một trong những cách tốt nhất để giải quyết các vấn đề phức tạp là giải quyết nó cho các trường hợp sử dụng cụ thể và sau đó khám phá ra một khái quát. Sử dụng TDD thúc đẩy chính xác điều đó. Bạn tạo một trường hợp thử nghiệm đơn giản và làm cho nó hoạt động, sau đó tạo một trường hợp thử nghiệm khác và làm cho nó hoạt động. Cuối cùng, bạn thấy nếu có một số khái quát hóa bạn có thể thực hiện cho phép bạn xử lý cả hai trường hợp thử nghiệm với cùng một logic. Nếu bạn có thể, thì nó có thể sẽ xử lý rất nhiều trường hợp thử nghiệm khác. Vì bạn có thể chạy tất cả các trường hợp thử nghiệm của mình bất cứ lúc nào, bạn có thể thoải mái cải thiện logic của mình mà không phải lo lắng về việc phá vỡ một cái gì đó. Bằng cách này, một giải pháp hacky không phải là hacky.

Phát triển dựa trên thử nghiệm cũng thúc đẩy

• chia nhỏ các vấn đề lớn thành các vấn đề nhỏ hơn, để dễ dàng có được phạm vi kiểm tra tốt.
• suy nghĩ trước về những gì bạn thực sự muốn đạt được trước khi bạn bị sa lầy vào các chi tiết của việc thực hiện.
• tránh kỹ thuật quá mức bằng cách cố gắng làm cho các bài kiểm tra vượt qua theo cách đơn giản nhất có thể, và các giải pháp đơn giản thường là những giải pháp tốt nhất.

Thực sự có một cuốn sách trả lời chính xác câu hỏi đó:

Cách thiết kế chương trình - Giới thiệu về lập trình và tính toán của Matthias Felleisen, Robert Bruce Findler, Matthew Flatt và Shriram Krishnamurthi

Họ hiện đang làm việc trên một phiên bản thứ hai , và sau đó, một tập thứ hai (Cách thiết kế các thành phần).

Điều thực sự thú vị về cuốn sách này là nó cung cấp cho bạn một bộ công thức để thiết kế các chương trình. Nói cách khác, nó cung cấp cho bạn các hướng dẫn từng bước mà bạn có thể (bán) không ngừng làm theo để thiết kế một chương trình.

Hoặc, nói một cách khác: nó chứa một tập hợp các chương trình để viết chương trình, để bạn không phải tìm ra cách viết một chương trình: các tác giả đã tìm ra nó cho bạn!

Ngoài các câu trả lời ở trên, đôi khi không phải là để biết chính logic mà là để biết khuôn khổ và ngôn ngữ mà bạn làm việc cùng. Mỗi khuôn khổ hoặc ngôn ngữ đều có đặc điểm riêng và nó giúp ích rất nhiều cho việc làm quen với điều đó.