Tôi đã đọc rất nhiều sách cho các ngôn ngữ lập trình khác nhau, Java, Python, C, v.v. Tôi hiểu và biết tất cả các điều cơ bản của ngôn ngữ và tôi hiểu các thuật toán và cấu trúc dữ liệu. (Tương đương với hai năm học lớp khoa học máy tính)

NHƯNG, tôi vẫn không thể tìm ra cách viết một chương trình làm bất cứ điều gì hữu ích.

Tất cả các sách lập trình chỉ cho bạn cách viết ngôn ngữ, nhưng KHÔNG làm thế nào để sử dụng nó! Các ví dụ lập trình đều rất cơ bản, như xây dựng một danh mục thẻ cho thư viện hoặc trò chơi đơn giản hoặc sử dụng thuật toán, v.v. Họ không chỉ cho bạn cách phát triển các chương trình phức tạp thực sự có ích gì!

Tôi đã xem các chương trình nguồn mở trên SourceForge , nhưng chúng không có ý nghĩa nhiều với tôi. Có hàng trăm tệp trong mỗi chương trình và hàng ngàn dòng mã. Nhưng làm thế nào để tôi học cách làm điều này? Không có gì trong bất kỳ cuốn sách nào tôi có thể mua trên Amazon sẽ cung cấp cho tôi các công cụ để viết bất kỳ chương trình nào trong số này.

Làm thế nào để bạn đi từ việc đọc Giới thiệu về Java hoặc Lập trình Python, hoặc Ngôn ngữ lập trình C, v.v. để thực sự có thể nói, tôi có một ý tưởng cho chương trình X? Đây có phải là cách tôi đi về việc phát triển nó?

Có vẻ như có rất nhiều liên quan đến việc viết một chương trình hơn là bạn có thể học trong một cuốn sách hoặc từ một lớp học. Tôi cảm thấy như có một cái gì đó.

Làm thế nào tôi có thể được đưa vào đúng đường?

Xây dựng các chương trình phức tạp hơn đi kèm với kinh nghiệm. Khi tôi lập trình lần đầu tiên, tôi nghĩ rằng tôi đã làm tốt nếu nó dài hơn 25 dòng (và tôi phải sử dụng thanh cuộn) Bây giờ tôi viết hàng trăm dòng mỗi ngày trong cùng một ứng dụng dự án.

Bạn có thể thấy trang này thú vị "Dạy lập trình trong mười năm" http://norvig.com/21-days.html

BTW: Rất khó để bắt đầu một chương trình. Một nhà văn có thể gọi nó là "khối nhà văn". Thay vào đó tôi đề nghị bạn bắt đầu viết mã và cải thiện nó. Đừng ngại xóa những phần lớn không làm những gì bạn cần. Bắt đầu lại, lần này bạn sẽ viết với một ý tưởng tốt hơn về những gì bạn đang làm. Bắt đầu lại và bạn sẽ thấy bạn không cần một nửa những gì bạn đã viết lần trước. Khi một tác giả viết một câu chuyện, phải mất một thời gian dài, rất nhiều văn bản và viết lại, v.v ... rất nhiều đánh giá và phản hồi và nó chỉ hoàn thành khi nó phải được xuất bản (phát hành)

Tôi luôn bị choáng ngợp bởi các dự án rất lớn, giống như những dự án bạn tìm thấy trên SourceForge hoặc GitHub. Tôi tự hỏi làm thế nào bất cứ ai, hoặc thậm chí một nhóm, có thể hiểu những gì đang xảy ra trên 10 hoặc 100 tệp, với hàng ngàn và hàng ngàn dòng mã.

Không ai làm. Ít nhất là ban đầu.

Các dự án là những thứ hữu cơ. Những gì bắt đầu như một ý tưởng thực sự đơn giản, có thể nhanh chóng mở rộng thành một khối lượng lớn công việc. Đây là, tôi nghĩ, lý do chính cho sự phát triển lặp lại thay vì cách tiếp cận thác nước cổ điển.

Hãy nghĩ đến việc xây dựng một chiếc xe hơi. Mặc dù bên ngoài có vẻ khá đơn giản, nhưng bạn chỉ cần tìm ra một cách nhỏ để khám phá ra rằng có rất nhiều cân nhắc, đánh đổi và các trường hợp vô tội cần phải xử lý.

Thí dụ:

Trong trường hợp của một dự án bán lớn, nó thường bắt đầu nhỏ. "Tôi muốn xây dựng một máy chủ bộ đệm". Vì vậy, bạn dành một vài ngày để hack, và đến một cái gì đó hoạt động, nhưng có thể được cải thiện đáng kể. Vì vậy, bạn thêm khái niệm về luồng.

Sau đó, bạn chạy vào các vấn đề tương tranh do luồng đó. Vì vậy, bạn sửa chữa bằng cách thay đổi cấu trúc dữ liệu đồng thời.

Bây giờ quá trình đã chậm lại. Vì vậy, bạn thay đổi cấu trúc dữ liệu đồng thời thành cấu trúc dữ liệu thông thường, nhưng cung cấp các cơ chế khóa để đồng bộ hóa.

Mọi thứ dường như đang chạy tốt, ngoại trừ người dùng bắt đầu phàn nàn rằng các hoạt động không phải là nguyên tử và dữ liệu đang bị hỏng.

Vì vậy, bạn thêm vào một số hoạt động nguyên tử cổ điển, như tăng và lưu. Điều này hoạt động, và người dùng của bạn đang hạnh phúc. Nhưng ai đó mở một vé hỏi liệu có thể thực hiện các hoạt động danh sách không.

Vì vậy, bạn dành một hoặc hai tuần để xây dựng tính năng đó. Vào khoảng thời gian này, một người bạn quyết định giúp bạn. Bạn làm việc với nó cùng nhau, hoàn thành và phát hành nó.

Hai vé mở. Có một lỗi trong quá trình xử lý danh sách và có một số trường hợp hiếm hoi đang bế tắc.

Bạn của bạn làm việc với lỗi xử lý danh sách, trong khi bạn giải quyết bế tắc. Bạn nhận ra rằng việc viết lại khá quan trọng đối với các hoạt động nguyên tử cần phải xảy ra.

... và vì vậy nó đi.

Điều này có vẻ khá điển hình về cách một dự án phát triển. 10 hoặc hơn các tập tin đã tăng lên 20 trong một vài tuần. Các tính năng mới được thêm vào mà không nằm ngoài kế hoạch ban đầu. Sửa lỗi kết hợp được thêm vào để phát triển mã lớn bất thường.

Lời khuyên của tôi:

Đừng trở nên quá tải. Nếu bạn có một ý tưởng, thực hiện các phần chức năng. Nếu nó đáng để theo đuổi sau đó, hãy thêm từng chút một. Hãy để dự án của bạn phát triển tự nhiên.

Ngay cả chương trình lớn nhất cũng bắt đầu với một ý tưởng và được viết từng dòng một.

Cách tốt nhất (có lẽ là duy nhất) để học cách viết các chương trình trong thế giới thực là bắt đầu thực hiện nó. Khi bạn gặp vấn đề, bạn tìm kiếm trên web hoặc hỏi ở đây để có giải pháp cho những vấn đề đó. Cuối cùng, bạn sẽ có được kinh nghiệm và phải hỏi ít thường xuyên hơn.

Tuy nhiên, có một số điều mà bạn cần lưu ý ngay từ đầu:

• Hầu như không có ứng dụng lớn nào được viết hoàn toàn từ đầu những ngày này. Bạn có thể hoàn thành nhiều việc hơn trong thời gian ngắn hơn nhiều nếu bạn sử dụng các thư viện và khung chất lượng cao hiện có. Bắt đầu với những điều này thường cảm thấy khá bực bội và nhiều công việc hơn là tự mình làm, nhưng điều đó gần như không bao giờ thực sự đúng.
• Suy nghĩ cẩn thận về cách bạn cấu trúc chương trình của bạn (cách thiết kế nó) là rất quan trọng một khi các chương trình của bạn trở nên lớn hơn. Dành thời gian cho việc đó và đọc một số sách về thiết kế (tôi đặc biệt khuyên dùng "Mã sạch") và kỹ thuật phần mềm cũng như về các vấn đề cơ bản về kỹ thuật.

Những gì bạn đang nói là kỹ thuật phần mềm nhiều hơn là lập trình. Đó là một chút kiến ​​trúc, một chút "thực tiễn tốt nhất" và "các mẫu thiết kế", một chút làm việc với những người khác. Mặc dù có những cuốn sách có thể giúp đỡ, nhưng phần lớn đến từ kinh nghiệm. Không ai bắt đầu viết, nói, Microsoft Word.

Hãy nghĩ về một chương trình lớn, "thực sự" mà bạn muốn viết. Bây giờ hãy nghĩ về các phần khác nhau mà bạn cần xây dựng để làm cho nó hoạt động theo cách bạn muốn. Ví dụ, trong trò chơi góc nhìn thứ nhất hiện đại, bạn sẽ cần một công cụ đồ họa 3D, AI không phải người chơi, mô-đun âm nhạc / âm thanh, công cụ vật lý và mô-đun cấp cao nhất để thực thi các quy tắc của trò chơi (biết "bản đồ", cách các nhân vật khác nhau tương tác, v.v.). Và sau đó là tác phẩm nghệ thuật và thiết kế nhân vật và âm nhạc, không ai trong số đó là mã mà là cần thiết để trò chơi được hoàn thành.

Bây giờ: Cái nào trong số này bạn sẽ tự xây dựng và bạn sẽ nhận được ở nơi nào khác? Hầu hết các dự án phần mềm lớn không được lập trình từ đầu. Có lẽ bạn sẽ sử dụng một công cụ 3D và mô-đun âm nhạc / âm thanh sẵn có và chỉ lập trình những thứ làm cho trò chơi của bạn trở nên độc đáo. OK, vì vậy bạn phải tìm ra mô-đun bên thứ ba nào bạn sẽ sử dụng, sẽ liên quan đến các yếu tố như chi phí, ngôn ngữ họ làm việc với, tính năng nào họ có, cách thiết kế API của họ (nghĩa là hoàn thành nó như thế nào là, nó phù hợp với phong cách lập trình cá nhân của bạn như thế nào, v.v.). Có thể bạn sẽ viết "bằng chứng về khái niệm" hoặc các chương trình thử nghiệm bằng cách sử dụng một hoặc hai ứng cử viên cho các mô-đun của bên thứ ba khác nhau để đảm bảo họ sẽ làm tất cả những điều bạn cần và dễ dàng cho bạn sử dụng.

Ngoài ra, ngay cả mã bạn muốn tự viết có thể là một công việc quá lớn để bạn một mình hoàn thành trong khung thời gian bạn có trong đầu. Bạn cần bao nhiêu lập trình viên khác làm việc trong dự án? Làm thế nào bạn sẽ chia công việc? Làm thế nào các mô-đun khác nhau sẽ được thiết kế để tất cả chúng phù hợp với nhau mặc dù chúng được viết bởi những người khác nhau? Làm thế nào tất cả các bạn sẽ làm việc trên cùng một mã nguồn mà không xóa sạch các thay đổi của nhau (câu trả lời: kiểm soát phiên bản, cực kỳ hữu ích khi bạn làm việc một mình nhưng không thể thiếu khi làm việc với người khác).

Khi bạn đã tìm ra mô-đun nào bạn muốn viết trong nhà, bạn thực hiện quy trình tương tự. Chỉ ra các phần của mỗi mô-đun, làm thế nào chúng nên khớp với nhau, và bạn sẽ tự viết và những gì bạn sẽ nhận được ở nơi khác. Tiếp tục phá vỡ mọi thứ cho đến khi mỗi mảnh đủ nhỏ để bạn giữ trong tâm trí, để bạn nói, "vâng, tôi có thể viết điều đó!" Và sau đó làm như vậy. Khi bạn làm, bạn sẽ gặp những trở ngại không lường trước được trong cách các phần khác nhau của chương trình của bạn khớp với nhau. Đây sẽ là những bực bội, nhưng chúng là cơ hội để bạn tìm hiểu thêm về nghề của bạn, và nên được xem theo cách đó.

Ban đầu, bạn sẽ chỉ có thể giữ các phần rất nhỏ trong chương trình của mình - giả sử, các chức năng riêng lẻ - trong tâm trí của bạn, và do đó bạn sẽ phải chia nhỏ mọi thứ trước khi bắt đầu viết mã. Khi bạn có được kinh nghiệm, bạn sẽ suy nghĩ về các chức năng thay vì cần phải suy nghĩ về các chức năng và bắt đầu suy nghĩ về các đối tượng. Và sau đó bạn sẽ suy nghĩ trong các đối tượng và suy nghĩ về các mô-đun lớn hơn. Cuối cùng, bạn sẽ suy nghĩ theo các mô-đun và suy nghĩ về các chương trình thực, lớn, thực.

Và sau đó bạn sẽ khám phá ra rằng bạn vẫn còn nhiều điều phải học ... nhưng cứ thế. Nếu, là một lập trình viên, bạn không bao giờ ngừng học hỏi, bạn đã lỗi thời và sẽ được thay thế bằng một mô hình mới hơn.

Dù sao, đừng sợ, và đừng lo lắng nếu điều này nghe có vẻ ... khủng khiếp hoặc không thể và rốt cuộc bạn không thực sự muốn trở thành một lập trình viên. Nó không dành cho tất cả mọi người. Tôi yêu âm nhạc và món tráng miệng, và tôi có thể chơi phím một chút và nấu một số món ăn, nhưng tôi không sẵn sàng dành thời gian để trở thành một nhạc sĩ tuyệt vời hoặc một đầu bếp bậc thầy.

Nếu hóa ra bạn không muốn trở thành một lập trình viên viết các ứng dụng lớn, thực, trên máy tính để bàn, thì có nhiều loại công việc lập trình khác. Bạn có thể trở thành một lập trình viên nhúng, ví dụ. Có những thách thức nhất định, thú vị liên quan đến việc viết các chương trình nhúng và bạn đang thực hiện công việc hữu ích, nhưng thông thường các chương trình này nhỏ hơn các ứng dụng trên máy tính để bàn. Hoặc bạn có thể viết các ứng dụng web. Trên Web, thật dễ dàng để gắn các bit chức năng lại với nhau, vì vậy bạn có thể viết (ví dụ) một hệ thống nhận xét Web và nó sẽ hữu ích ngay cả khi đó không phải là toàn bộ ứng dụng Web. Thật dễ dàng để cải thiện dần các công cụ trên Web, vì vậy bạn có thể bắt đầu với (giả sử) một ứng dụng thư Web cơ bản và theo thời gian, phát triển nó thành một cái gì đó như Gmail. (Nhưng đừng làm vậy, vì sau đó bạn sẽ cạnh tranh với Gmail.)

Nếu bạn không muốn trở thành một lập trình viên, nhưng vẫn muốn làm việc với máy tính, có thể bạn có thể đi vào CNTT hoặc một số lĩnh vực kỹ thuật khác. Trong những trường hợp này, việc biết lập trình nhiều như bạn đã làm là rất hữu ích, bởi vì các đồng nghiệp của bạn thậm chí có thể không có nhiều như vậy. Hoặc, bạn biết đấy, trở thành một nhạc sĩ nếu điều đó hấp dẫn, bởi vì (giống như hầu hết các lĩnh vực) nó liên quan đến máy tính ngày nay. Viết các chương trình nhỏ điều khiển các tệp âm thanh hoặc MIDI theo nhiều cách thông minh khác nhau, do đó giúp bạn trở thành một nhạc sĩ giỏi hơn. Bạn sẽ thấy rằng bất kỳ kỹ năng lập trình nào bạn có thể được áp dụng trong nhiều lĩnh vực để giúp bạn hoàn thành công việc tốt hơn.

Bạn sẽ không tìm ra cách lập trình trừ khi bạn phải đối mặt với một nhiệm vụ thực sự. Không có lý thuyết nào có thể thay thế một nhiệm vụ trong thế giới thực đơn giản. Trước khi bắt đầu thực hiện các kịch bản rw, tôi đã ngây thơ đọc rất nhiều sách, với tất cả các ví dụ, nhưng khi tôi gặp phải một vấn đề thực sự, tôi không thể thu thập tất cả kiến ​​thức lý thuyết của mình để hoàn thành nhiệm vụ. Nếu bạn là người bắt đầu, tôi khuyên bạn nên nhận các nhiệm vụ từ bất cứ nơi nào bạn có thể. Đừng nghĩ rằng chúng vô dụng trừ khi bạn giải quyết chúng. Bước đầu tiên hãy thử giải quyết các vấn đề về cấu trúc dữ liệu, như sắp xếp danh sách được liên kết, thực hiện DFS, BFS trên cây, biểu đồ, v.v. Không chỉ cải thiện kỹ năng mã hóa của bạn, mà điều quan trọng hơn, nó sẽ cải thiện kỹ năng phân tích và thuật toán , mà tin tưởng tôi là một kiến ​​thức có giá trị. Sau đó, khi bạn sẽ biết rằng bạn có thể đá với con trỏ, đệ quy,

Dòng dưới cùng. Đó là tất cả về thực hành. Chỉ cần tiếp tục đào và mã, mã, mã.

Bắt đầu với các trò chơi trên máy tính, giống như mọi người khác đã làm. Một trò chơi hay là cả thử thách lập trình và thiết kế, cần suy nghĩ cẩn thận về cấu trúc bên trong và nó sử dụng các thư viện hệ thống theo cách dạy nhiều, nhưng không có xu hướng phá vỡ mọi thứ và không yêu cầu "lý do chính đáng với kết quả tốt" giống như phần mềm "hữu ích" thực sự.

Quy tắc chung là sau khi viết đủ thứ, một số loại giác ngộ sẽ không thể tránh khỏi xảy ra.

Một điểm hay để bắt đầu (nếu bạn cảm thấy thích C) là http://gamedev.net/ , đặc biệt là http://nehe.gamedev.net/ . Ngoài ra còn có nhiều điểm tốt khác để bắt đầu: D

Bạn đang xem toàn bộ chương trình lớn và dường như là không thể. Nhưng toàn bộ điều này được tạo thành từ những chương trình nhỏ ngu ngốc như những chương trình mà bạn đang nói "đừng làm gì hữu ích."

Những gì bạn cần là kinh nghiệm chia nhỏ các nhiệm vụ phức tạp lớn thành các nhiệm vụ đơn giản nhỏ. Đó là gốc rễ của tất cả các chương trình. Phần còn lại chỉ là ngữ nghĩa.

Cũng giống như lái xe hoặc nấu ăn, lập trình là điều bạn học để làm bằng cách làm. Thực hành là không thể thay thế.

Nếu các ví dụ trong sách giáo khoa đã quá cơ bản đối với bạn, điều đó thật tuyệt! Thời gian để di chuyển cho một cái gì đó phức tạp hơn - và bạn đã có thể tìm ra một số bài tập thử thách cho chính mình.

Hoặc, nếu bạn có một ý tưởng cụ thể trong đầu, hãy chia nó thành bit. Giải một tập con nhỏ của bài toán trước. Sau đó mở rộng. Khi việc tích hợp mã mới vào mã hiện tại của bạn trở nên khó khăn, sau đó bạn thiết kế lại mọi thứ.

Viết một kịch bản 200 dòng. Sau đó bắt đầu cải thiện nó.

Featuritis sẽ giúp bạn có tới 100 tệp nguồn và vài trăm KLOC ngay lập tức :)

"Họ không chỉ cho bạn cách phát triển các chương trình phức tạp thực sự làm bất cứ điều gì hữu ích!"

Nếu không có định nghĩa về "hữu ích" thì thực sự chúng ta không thể làm gì nhiều để đưa bạn đi đúng hướng.

Chúng tôi không biết bạn thất bại như thế nào, hoặc điều gì đang xảy ra. Chúng tôi không thể biết bạn đang theo dõi bài hát nào.

Bằng cách nào đó, bạn có một khái niệm trong đầu rằng bạn không giao tiếp.

Phần mềm - lập trình - là tất cả về việc đưa một khái niệm ra khỏi đầu bạn vào một số ngôn ngữ (Python, Java, tiếng Anh, bất cứ điều gì).

Một bước quan trọng trong lập trình (và đặt câu hỏi) là xác định các điều khoản của bạn. Bạn có ý nghĩa gì khi "làm bất cứ điều gì hữu ích"? Hãy rất rõ ràng, rất đầy đủ và rất chính xác.

Tôi được hỏi câu hỏi này mọi lúc, ví dụ như làm thế nào để bắt đầu. Thật đơn giản. Đây là một bước từng bước.

1. Nghĩ ra ý tưởng. Âm thanh như bạn đã có điều đó.
2. Đơn giản hóa ý tưởng của bạn đến cốt lõi cơ bản của nó - điều mà bạn nghĩ rằng bạn có thể giải quyết được
3. Bố trí UI trên một tờ giấy hoặc khăn ăn, bất cứ điều gì.
4. Hãy thử và bố trí UI trong môi trường phát triển của bạn.
5. Nếu bạn gặp khó khăn, google, google, google, đặt câu hỏi về stackoverflow, sử dụng crap sống từ các tài nguyên internet để nhận trợ giúp. Hỏi bạn bè và đồng nghiệp là lập trình viên để giúp bạn trong các tình huống cụ thể. Quay trở lại bước 4.
6. Bắt đầu viết logic của ứng dụng của bạn. Nếu bạn gặp khó khăn, hãy đến bước trước và thử lại.
7. Không lâu nữa, bạn sẽ có một cái gì đó hoạt động sớm.

Tạo một cái gì đó nhỏ. Đừng bận tâm, chương trình của bạn sẽ là thứ 1000 làm điều đó.

Một vài ý tưởng:

• đồng hồ (đầu tiên là kỹ thuật số, sau đó là tương tự),
• người tạo labirynth tự động,
• hiển thị cấu trúc thư mục,
• nghe album mp3,
• Vân vân.

Chọn nền tảng, công cụ là một phần của nhiệm vụ.

Ok, hãy bắt đầu với ý tưởng của bạn cho chương trình X, thứ gì đó hữu ích và hãy phá vỡ nó:

• Sử dụng giấy, sơ đồ tư duy hoặc phần mềm lập sơ đồ để bố trí luồng / luồng logic của chương trình.

• Vì bạn chỉ mới bắt đầu, hãy chọn MỘT trong số các mặt hàng đó (tốt nhất là gần đầu) và chia nhỏ hơn nữa.

• Viết mã của bạn cho điều đó trước và sử dụng nó để xây dựng

Chương trình X có cần mở tệp, thao tác và tạo tệp đầu ra không? Xem nếu bạn có thể mở và lặp lại tập tin như bước đầu tiên của bạn. Bạn có muốn một giao diện người dùng đẹp? Xây dựng một chương trình có thể chạy chương trình echo tập tin của bạn, v.v. Bạn sẽ không chỉ xây dựng mã bạn có thể sử dụng trong chương trình phức tạp của mình từng bước mà còn xây dựng kiến ​​thức ngôn ngữ của bạn khi bạn phải tìm kiếm và tra cứu thông tin.

Như đã nói - Gnome đã không được xây dựng trong một ngày :-)

(đã trả lời ở trên trong các ý kiến ​​rồi. Đề nghị gửi câu hỏi này dưới dạng câu trả lời sau khi câu hỏi được mở lại.)

Bạn bắt đầu với một vấn đề - một cái gì đó bạn muốn giải quyết - bất kể bạn nghĩ nó phức tạp đến mức nào. Sau đó, bạn nhận vấn đề này và bạn viết nó ra và bắt đầu chia nó thành những vấn đề nhỏ hơn. Sau đó, bạn phá vỡ những vấn đề nhỏ hơn, vv cho đến khi bạn có một cái gì đó nguyên thủy mà bạn đã biết cách giải quyết hoặc có thể làm như vậy với một số nỗ lực. Bạn bắt đầu mã hóa từng phần này và sắp xếp chúng thành các hàm khác nhau hoặc các lớp khác nhau, v.v.

Sau đó, bạn làm việc trên các vấn đề phụ tiếp theo. Khi bạn đang làm việc trên từng vấn đề, bạn có thể viết các trường hợp thử nghiệm nhỏ và thực sự thấy bạn tiến triển thành hiện thực. Sẽ luôn có những thách thức trên đường đi, nhưng không có lúc nào sẽ thấy nó là một cái gì đó quá vĩ đại để thậm chí tiếp cận (những gì dường như đang đối phó với bây giờ). Điều này đúng với lập trình và nhiều thách thức trong cuộc sống. Họ quan trọng là để phá vỡ nó.

Đối với những gì để làm - ý tưởng. Bạn có thể cố gắng phát minh ra một cái gì đó mới, nhưng bạn cũng có thể lấy thứ gì đó mà bạn có thể có niềm đam mê và đã tồn tại, nhưng chỉ cần làm cho nó tốt hơn hoặc thậm chí chỉ khác biệt. Tôi hiện đang viết một ứng dụng chỉnh guitar cho Android trong thời gian rảnh. Tôi biết đã tồn tại nhiều ứng dụng điều chỉnh guitar khác, nhưng tôi nghĩ đây sẽ là một dự án thú vị và đầy thách thức nên tôi đã tiếp tục. Lúc đầu, điều đó dường như là không thể, nhưng sau khi tôi giải quyết vấn đề thành những bước nhỏ hơn, nó thực sự kết hợp với nhau một cách tốt đẹp. Chia rẽ và chinh phục và kiên trì với mục tiêu của bạn.

Một trong những điều khó nhất khi bạn là người mới bắt đầu là đặt ra các mục tiêu thực tế cho những gì "làm thế nào tôi có thể cải thiện" -các vấn đề nên có ở cấp độ hiện tại của bạn.

Do đó tôi sẽ đề nghị bạn chọn thực hành giải các bài tập nhỏ, vì khả năng hoàn thành chương trình theo một đặc điểm kỹ thuật nhất định là một điều rất có giá trị đối với mọi người lập trình để kiếm sống.

Tôi sẽ đề nghị bạn xem xét kỹ hơn về http://projecteuler.net/ , nơi có rất nhiều bài tập và hệ thống "kiểm tra câu trả lời" tự động, cho phép bạn làm việc theo tốc độ của riêng bạn. Các bài tập được diễn đạt tốt, nhưng có thể đòi hỏi bạn phải suy nghĩ. Một số thậm chí có thể yêu cầu bạn phải suy nghĩ rất nhiều, nhưng thậm chí không giải quyết được những điều đó, sẽ dạy cho bạn một cái gì đó hữu ích.

Từ ngữ đầy đủ của vấn đề 1 là:

Nếu chúng ta liệt kê tất cả các số tự nhiên dưới 10 là bội số của 3 hoặc 5, chúng ta sẽ nhận được 3, 5, 6 và 9. Tổng của các bội số này là 23.

Tìm tổng của tất cả các bội số của 3 hoặc 5 dưới 1000.

Bạn có nghĩ rằng bạn có thể giải quyết điều này? Sau đó làm điều đó!

Bạn cần kinh nghiệm trong thế giới thực !! . Không có cuốn sách nào có thể dạy bạn điều đó!

Bạn phải học cách đọc mã của người khác, cách duy trì nó, cách ghét họ (cả mã và người viết mã) cách cải thiện nó, làm thế nào để nghĩ rằng bạn có thể làm điều đó tốt hơn và vài tháng sau tôi hét to lên ' Sẽ giết ai đã từng viết đoạn mã này !!! Chỉ để tìm ra trong kiểm soát phiên bản nguồn đó là bạn!

Bạn phải hiểu sách rất cụ thể và đôi khi cho những người đã biết cách phát triển phần mềm.

Vì vậy, tôi sẽ đề nghị bạn tìm một số công việc lập trình. Nếu cần, áp dụng cho cấp nhập cảnh cơ bản nhất. Có lẽ bạn sẽ không kiếm được nhiều tiền như bạn nghĩ, nhưng hãy sử dụng một vài tháng để tìm hiểu cách phần mềm được phát triển trong thế giới thực (và nó không phải lúc nào cũng hoàn hảo và với tất cả những thực tiễn tốt nhất mà chúng ta đọc trên web , nhiều lần, chất lượng mã rất thấp, tùy thuộc vào nơi bạn làm việc, nhưng đó là một phần của trải nghiệm)

Tiếp tục đọc sách của bạn, bạn sẽ tìm ra, mỗi năm bạn hiểu thêm một chút (hoặc khác nhau) cùng một chủ đề, bởi vì bạn có thể thấy nó biết với kính kinh nghiệm.

Nếu bạn quản lý để có được một công việc với các nhà phát triển tài năng, tốt hơn nhiều. Học hỏi từ họ, đừng sợ phạm sai lầm.

Cho đến khi bạn phải sửa lỗi khẩn cấp sản xuất trực tiếp đầu tiên của mình, bạn sẽ không biết lỗi phần mềm là gì!

:)

Hãy thử một dự án nguồn mở, xem bạn có thể phù hợp không. Bắt đầu bằng cách tải xuống nguồn và xem bạn có thể lấy một số vé không

Khi tôi muốn học một ngôn ngữ mới, tôi thường cố gắng thực hiện một số biểu đồ fractal. Bằng cách đó, bạn sẽ có phản hồi ngay lập tức nếu nó hoạt động và nó rất bổ ích. Và có rất nhiều cách bạn có thể cải thiện một fractal. Việc thực hiện ngây thơ của mandelbrot chậm như địa ngục.

Nó không hữu ích lắm, nhưng bạn học được rất nhiều và thật tuyệt khi nhìn vào.

Lập trình là về giải quyết vấn đề và giao tiếp, không viết nhiều mã. Mã chỉ là một điều cần thiết, bạn thường nên cố gắng viết ít mã hơn, không nhiều hơn.

Nếu bạn không biết bắt đầu từ đâu, có lẽ bạn không gặp vấn đề gì!

Nhìn vào Linux và các hệ thống tương tự Unix khác: tất cả chúng đều bao gồm nhiều ứng dụng nhỏ chỉ làm một việc, nhưng làm tốt điều đó .

Khi tôi cần một tập lệnh để tìm 10 tệp lớn nhất trong một thư mục trên máy tính của mình, tôi đã không đọc sách. Tôi chỉ googled và sử dụng một trong những giải pháp hiện có. Tôi đã viết bất kỳ mã? - Không. Vấn đề đã được giải quyết chưa? - Đúng. Chương trình một dòng này có hữu ích không? - Heck vâng.

Các chương trình với hàng ngàn dòng mã thường được viết bởi nhiều hơn một lập trình viên. Bạn sẽ không thể viết toàn bộ hệ điều hành một mình và bạn không cần phải viết. Họ cũng thường sử dụng các mánh gian lận như kiểm soát phiên bản và kiểm tra đơn vị .

Phân chia và chinh phục.

Nó đơn giản hoặc khó như vậy.

Khi tôi bắt đầu lập trình, tôi yêu thích các trò chơi máy tính. Vì vậy, tôi bắt đầu viết các trò chơi của riêng mình, ngay khi tôi có bất kỳ công cụ nào trong tay để làm điều đó.

Hoàn toàn tự nhiên, trò chơi đầu tiên của tôi là một cuộc phiêu lưu văn bản. Tương tự như vậy, bạn có thể bắt đầu với một câu đố hoặc một cái gì đó, hoặc một số trò chơi đoán.

Ngoài ra, bạn có thể bắt đầu với một cái gì đó, như máy đánh bạc (bạn không thực sự cần hoạt hình, hoặc thậm chí là hình ảnh. Chỉ cần sử dụng A = apple, L = chanh, S = start, P = Plum, v.v.).

Điều này sẽ dạy cho bạn những điều cơ bản để xử lý một số đầu vào của người dùng, duy trì trạng thái trò chơi và tạo đầu ra tương ứng.

Tôi đi xuống con đường này khá xa. Tôi dần dần học được cách đọc trạng thái bàn phím hoặc chuột, cách sử dụng mã đồ họa. Tôi đã học được nhiều hơn về ngôn ngữ (tôi bắt đầu với PASCAL) và sử dụng ngôn ngữ này để cải thiện các trò chơi hiện có của tôi hoặc chỉ bắt đầu một cái gì đó mới.

Tôi nghĩ rằng các trò chơi thực sự tuyệt vời để học lập trình. Ngay cả với ít kinh nghiệm, bạn có thể tạo ra những điều nhỏ nhặt, mang lại cho bạn những khoảnh khắc tự hào nhỏ. Bởi vì bạn tạo ra một cái gì đó, đó là niềm vui. Xây dựng các ứng dụng thực tế là khá vô nghĩa, bởi vì phải mất rất nhiều công sức để tạo ra thứ gì đó, điều đó thực sự hữu ích, trong khi thật đơn giản để tạo ra một trò chơi nhỏ, lại gây nghiện.

Bạn có thể thực sự muốn sử dụng một ngôn ngữ giáo dục (trong trường hợp của tôi, đây là PASCAL và khi nhìn lại, tôi nghĩ rằng nó đã được chứng minh là một lựa chọn khá tốt). Rất nhiều trong số chúng đặc biệt nhằm mục đích tạo ra các trò chơi và như vậy.

Tạo các ứng dụng không chỉ là tạo các thuật toán. Bạn phải thiết kế các tính năng, bạn cần tổ chức và cấu trúc mã của mình theo các lớp và mô-đun khác nhau. Không giống như các vấn đề khá "nguyên tử" mà bạn đưa ra ở trường đại học, các ứng dụng đôi khi được phát triển tốt nhất theo cách tăng dần. Bạn bắt đầu với một cái gì đó và bạn thêm những thứ trên đầu trang của nó. Vì vậy, đã có một cái gì đó để bắt đầu (như trong một số ngôn ngữ được liệt kê trong bài viết trên wikipedia), bạn tiết kiệm cho mình rất nhiều sự thất vọng và bắt đầu tạo ra một cái gì đó ngay lập tức. (Một đồng nghiệp của tôi bắt đầu lập trình bằng cách viết quake 2 mod). Tại một số điểm, bạn sẽ đến để tìm ra những hạn chế của các công cụ dễ sử dụng này, nhưng cho đến lúc đó, bạn sẽ có cái nhìn sâu sắc và hiểu biết hơn rất nhiều. Có lẽ là đủ,

Ở trường đại học, có một lớp gọi là thực hành lập trình về cơ bản đã dạy đoạn đường nối này. Ban đầu, bạn được cấp UI cho một ứng dụng mua sắm cơ bản và phải viết mã phụ trợ, tháng cuối cùng là Tetris từ đầu. Tôi nghĩ rằng khoảng 50% sinh viên mới (không học lại lớp) đã thất bại, bởi vì việc gia tăng từ nhỏ đến lớn là vô cùng khó khăn.

Tôi muốn đề xuất một hoặc nhiều điều sau đây:

• Tải về một dự án nguồn mở và thêm một cái gì đó. Nó không phải là hữu ích hay tốt, nhưng bạn sẽ phải xem cấu trúc, điều này sẽ cho bạn cảm giác về dự án lớn được xây dựng như thế nào.

• Chỉ cần thiết kế dự án cuối cùng của bạn trên giấy, với các mũi tên cho phụ thuộc. Nếu bạn đang làm rắn, bạn có thể có đầu rắn, đuôi rắn, thức ăn, không gian trống, tường, bảng, hướng hiện tại, v.v. Có thể giúp bạn nhận ra nếu dự án của bạn lớn hơn nhiều so với bạn nghĩ.

• Lấy một dự án cơ bản, và làm cho nó ngày càng lớn hơn. Bạn có thể sẽ thực hiện nhiều thao tác tái cấu trúc và hy vọng bạn sẽ học được cách thực hiện các dự án nhỏ hơn có thể dễ dàng thêm vào.

• Nếu bạn biết ai đó có kinh nghiệm, hãy cho họ biết ý tưởng của bạn cho một dự án và yêu cầu họ viết các lớp của bạn + một số phương pháp quan trọng, có thể sẽ mất một giờ hoặc lâu hơn. Bằng cách đó bạn có thể chỉ cần điền vào các phương thức và luôn biết bạn cần làm gì tiếp theo.

Cuối cùng, bất cứ điều gì bạn làm, có lẽ bạn nên sử dụng một mẫu thiết kế cơ bản MVC (Model, View, Controller). Không đi sâu vào chi tiết, hãy đặt chế độ xem (UI) của bạn vào 1+ lớp, bộ điều khiển của bạn (Đầu vào, đầu ra, v.v.) thành 1+ lớp và Mô hình của bạn (Logic, Dữ liệu, về cơ bản là mọi thứ khác) vào một số lớp. Đó là một cách dễ dàng để có được tổ chức cơ bản.

Hãy nhớ rằng, bước này là khó khăn. Đúng là một số người đơn giản là không thể lập trình, nhưng có lẽ bạn chỉ bị mắc kẹt ở giai đoạn này. Chúc may mắn!

Đầu tiên, bạn đã thực hiện các điều kiện tiên quyết bằng cách tham gia các lớp học, đọc tài liệu tham khảo, xem các dự án nguồn mở và tò mò với các câu hỏi. Tôi nhấn mạnh điều này bởi vì cá nhân tôi đã gặp phải những câu hỏi tương tự trước khi người đó thực hiện bất kỳ công việc chân nào từ phía họ (cụ thể là các cá nhân phá vỡ các lớp học và hy vọng sẽ rút ngắn). Bây giờ, tôi nghĩ lại khi chúng tôi có phòng thí nghiệm về máy Turing và tại thời điểm đó tôi cảm thấy đó không phải là chương trình thực sự. Đây là những kinh nghiệm bạn sẽ giữ mà bất cứ ai thực hiện các bước ngắn đều bỏ qua.

• Đăng ký dự án sinh viên. Tôi đã tham gia với (CSUA) một nhóm sinh viên có cùng chí hướng để xây dựng một trò chơi cho gian hàng lễ hội vào năm cuối của tôi. Nếu bạn tiếp tục thích nó và nghĩ rằng bạn muốn mở rộng sự tham gia của mình, hãy thực sự tận dụng các nguồn lực. Tìm hiểu về các dự án, nói chuyện với bạn cùng lớp, giáo sư của bạn và thực tập.

• Ngồi với một lập trình viên giàu kinh nghiệm. Đã có khoảng ba lần trong lịch sử của tôi khi tôi xem chương trình của một người khác thực sự truyền cảm hứng. Đối với họ, họ chỉ viết mã và suy nghĩ thành tiếng. Không cường điệu, tôi cảm thấy như tôi đã thu hút được nhiều hơn từ việc lắng nghe họ hơn là tôi sẽ tự mình làm nhiều năm. Nếu bạn gặp nhiều hơn, bạn giàu có hơn nhiều. Chúng tôi may mắn được ở trong thời đại mà chúng tôi có thể xem video, kiểm tra kho lưu trữ nguồn hoàn chỉnh và tìm kiếm một kho kiến ​​thức trực tuyến khổng lồ ngay lập tức. Nó không thay thế cho trải nghiệm trực tiếp, nhưng khi không có người cố vấn, đó là một cải tiến đáng kể so với vật liệu truyền thống. Tuy nhiên, nhìn vào mã thô của người khác có thể không dẫn đến bất cứ điều gì. Bạn sẽ muốn có một cái gì đó trong tâm trí và một trình sửa lỗi tốt để bước vào logic. Một trong những khoảnh khắc yêu thích nhất của tôi là tạo ra một bản mod Quake và bản thân nó không phải là bản mod có gì đáng nhớ. Nó đã nhìn thấy logic trong trò chơi của Carmack. Bản mod chỉ là một lý do để tôi lao vào.

• Thực hành giải thích và trả lời các câu hỏi được đặt ra bởi đối tác phòng thí nghiệm của bạn. Tình nguyện giúp dạy. Có thể thành lập một nhóm nghiên cứu và yêu cầu mỗi thành viên trở thành một chuyên gia về một chủ đề của lớp. Sau đó nướng người đó và có họ nướng bạn. Khi bạn buộc phải trả lời các câu hỏi, bạn sẽ có nghĩa vụ phải tự tìm hiểu câu trả lời. Khi bạn có thể giải thích các khái niệm rõ ràng cho người khác, bạn đã làm phong phú thêm sự hiểu biết của mình đến mức bạn có thể truyền đạt nó bên ngoài một cuốn sách và suy nghĩ của bạn.

• Cuối cùng, đừng sợ học một cách khó khăn, bị bẩn tay, phạm sai lầm. Điều này cũng có thể được gọi là kinh nghiệm. Như một ví dụ thực tế hơn liên quan đến câu hỏi của bạn về các dự án có cơ sở mã khó sử dụng và số lượng tệp lớn, hãy thực hiện bài tập này: sử dụng một tệp duy nhất cho công việc của bạn. Thực sự tôi không nói đùa. Câu hỏi rất giống nhau này thực sự đã xuất hiện tại công ty hiện tại và trước đây của tôi. Ở đây, một nhà phát triển khác quan sát thấy rằng tôi thích giữ một tệp cho mỗi lớp. Điều này có vẻ xa lạ với anh ta và, trong một vấn đề liên quan, anh ta cũng không thích các lớp học một phần. Vì vậy, một cách để bạn có được cảm giác khi nào hoặc nơi thích hợp để phân tách logic thành các tệp riêng biệt sẽ bắt đầu chỉ bằng một tệp duy nhất. Sau khi bạn đã thực hành quy tắc một tệp trên nhiều dự án, hy vọng sẽ tăng độ phức tạp, bạn có thể chạy vào một dự án nơi bạn có quá nhiều lớp trong một tệp mà bạn cảm thấy khó đọc hoặc do kiểm soát phiên bản trở nên khó cộng tác. Tại thời điểm này, bạn muốn tạo các tệp riêng biệt để nhóm các lớp khác nhau. Với sở thích của bạn, bạn có thể quyết định sớm rằng bạn thích tất cả các lớp dữ liệu trong một tệp. Sau đó, có lẽ sau này, bạn có thể quyết định rằng bạn thích các tệp riêng biệt ngay cả giữa các lớp dữ liệu dưới dạng một nhóm.

Bạn không cần phải có một ý tưởng tuyệt vời để bắt đầu lập trình một cái gì đó. Tôi sẽ bắt đầu từ phần dễ dàng. Giống như, một chương trình mà bạn đã sử dụng nó. Cố gắng làm một cái gì đó mà bạn đã biết làm thế nào nó hoạt động. Đối mặt với vấn đề của bạn, vì vậy bạn sẽ học nó nhanh hơn. Khi bạn có nhiều kinh nghiệm hơn, bạn sẽ bắt đầu có một số ý tưởng tốt về các chương trình để làm cho cuộc sống của bạn dễ dàng hơn trong khi lập trình, hoặc chỉ là một chương trình tốt để làm điều gì đó mà bạn chưa từng nghĩ về nó trước đây. Tôi đã lập trình Java được gần một năm và các ngôn ngữ khác trong một vài năm. Phải mất thời gian để bắt đầu làm những gì tôi thực sự muốn làm. Tôi chỉ bắt đầu làm những thứ của riêng tôi. Cảm ơn StackOverflow. Tôi đã không biết về nó trước đây.

Vì vậy, có rất nhiều câu trả lời vì vậy hãy tha thứ cho tôi nếu tôi lặp lại nhiều điều đã được nói, nhưng đây là 2 xu của tôi.

Đầu tiên chọn một ý tưởng. Bất kỳ ý tưởng sẽ tốt, một cái gì đó đơn giản có thể sẽ tốt hơn sau đó lớn. Các dự án có xu hướng phát triển trong phạm vi của chúng rất nhanh (một số người gọi đó là tính năng creep).

Tiếp theo làm một bộ xương cho dự án. Điều này sẽ đòi hỏi một chút kiến ​​thức về kiến ​​trúc và thiết kế và có thể bạn sẽ hiểu sai trong mười lần đầu tiên bạn thử nó - tôi đã làm. Đơn giản chỉ cần đặt ra một cấu trúc tệp tốt và có thể là một bộ mã nhỏ hiển thị các phần quan trọng của hệ thống.

Lưu bộ xương trong VCS của bạn (chọn chất độc của bạn với cái này và giữ khi nó dẫn đến một cuộc chiến thần thánh). Khi bạn đã bắt đầu sử dụng VCS, liên tục sử dụng nó cho các thay đổi nhỏ sẽ trở thành bản chất thứ hai, nhưng hãy đảm bảo bắt đầu.

Bây giờ chọn một tính năng nhỏ, nhưng quan trọng cho hệ thống và làm cho nó. Đừng lo lắng về việc đảm bảo rằng bạn có mọi thứ được gói gọn một cách hoàn hảo và nó có thiết kế "tốt nhất" (sẽ phát triển cùng với hệ thống). Chỉ cần nhận được một cái gì đó sẽ làm việc. Ngoài ra nhận được một số bài kiểm tra đơn vị sẽ giúp đảm bảo bạn biết những gì đã xảy ra khi một cái gì đó bị phá vỡ, nếu bạn chạy các bài kiểm tra thường xuyên.

Xây dựng hệ thống của bạn. Đây cũng sẽ là thời điểm tốt để có được một hệ thống xây dựng tự động và tích hợp liên tục. Nếu bạn không biết chúng là gì thì hãy học nó và thử, hoặc tiếp tục tự chịu rủi ro; một trong hai cách tiếp tục làm việc

Bây giờ chọn một tính năng khác và lặp lại và lặp lại và lặp lại.

Một khi bạn nghĩ rằng nó hoạt động tốt, hiển thị nó cho một người bạn. Người bạn không cần phải biết cách lập trình hoặc thậm chí biết chương trình đó làm gì. Một người bạn sẽ cảm thấy tốt khi hiển thị cho ai đó và hai người sẽ giúp bạn biết chính xác những gì hệ thống làm.

Nếu bạn đạt đến điểm mà bạn rất tự tin với những gì bạn đã làm, hãy phát hành trực tuyến và thử và nhận phản hồi. Một trung tâm lưu trữ hoặc chương trình con reditt lập trình viên có thể cung cấp cho bạn một số lời chỉ trích mang tính xây dựng. Hãy thử và tìm một giáo sư CS / SE và để anh ấy / cô ấy nhìn vào nó. Có thể hỏi một lập trình viên chuyên nghiệp. Chỉ cần có ý kiến ​​lập trình viên khác.

Khi bạn hoàn thành (hoặc có thể trước đó), bạn sẽ nhận ra rằng mã bạn đã viết ban đầu tệ hơn rất nhiều so với những gì bạn đã thực hiện gần đây. Điều đó là hoàn toàn tự nhiên và xảy ra với tất cả chúng ta. Bây giờ bạn cần tìm một dự án mới và tìm hiểu một cái gì đó mới - có thể là một chiến lược thử nghiệm mới hoặc cách sử dụng Kiến trúc hướng dịch vụ.

Một cái gì đó có thể giúp đỡ là nghĩ về một vấn đề đơn giản mà bạn gặp phải hàng ngày trong đó một cái gì đó bạn có thể làm bằng bút chì và giấy có thể được thay thế bằng một chương trình.

Điều này cung cấp cho bạn một vấn đề tương đối đơn giản với một giải pháp khá nổi tiếng chỉ cần một mức độ tự động hóa. Hãy nhớ rằng điều này không cần phải là MS Word / Wordman / NotePad tiếp theo; chỉ cần một cái gì đó giải quyết vấn đề (đơn giản) của bạn.

Ví dụ, một vấn đề mà tôi tiếp tục thực hiện khi làm việc với một ngôn ngữ mới là một ứng dụng máy chấm công đơn giản. Ứng dụng này được sử dụng để theo dõi số giờ có thể thanh toán cho các dự án khác nhau trong một ngày. Một chương trình khá đơn giản với rất nhiều vấn đề nhỏ, như cách bạn xử lý khởi động lại vào giữa ngày hoặc làm thế nào để bạn thêm / xóa các mục khỏi danh sách của mình.

Tôi nghĩ một phần của vấn đề là khi bạn đọc sách lập trình, họ chỉ dạy bạn ngôn ngữ. Họ không đề cập rằng để lập trình hầu hết mọi thứ, bạn cần truy cập để lập trình LIBRARIES và SDKS, v.v. Chỉ cần biết ngôn ngữ không may là không đủ.

Tôi đoán vấn đề của bạn xuất phát từ: 1. sự nhầm lẫn giữa lý thuyết và thực tiễn, và cũng là ... 2. ... bạn phải nhận ra rằng mã của bạn sẽ được chạy bởi mã của người khác. 3. bạn không thể mã hóa một cái gì đó nếu bạn không biết gì về những gì bạn có thể làm. 4. Bạn biết một nửa khó khăn

1. Biết một ngôn ngữ bằng lý thuyết không có nghĩa là bạn "nói" nó: đó là sự khác biệt giữa đọc tiếng Anh và nói nó. Ngoài ra số lượng lớn các công cụ khác nhau có sẵn để biên dịch, liên kết, chỉnh sửa mã nguồn sẽ khiến đầu bạn quay cuồng.

2. khi học cách lập trình, hầu hết thời gian thiết bị đầu cuối được sử dụng để nhập / xuất văn bản, bởi vì đây là cách đơn giản nhất để xử lý lập trình. Trong thực tế, các lập trình viên sử dụng các thư viện (như Qt), các khung (django tôi đoán) và các mã phím tắt khác để có hiệu quả. Tất nhiên, nếu bạn cảm thấy bạn có thể tự viết bánh xe của mình, đừng phát minh lại và đọc sách về thiết kế trình biên dịch và thiết kế kernel: có rất nhiều điều để học trong những điều này: có thể bạn cảm thấy thật ngu ngốc khi bỏ các ứng dụng không đòi hỏi nhiều về công nghệ.

3. Phát minh ra một cái gì đó! Tất nhiên bạn có thể làm một trình soạn thảo văn bản, một trò chơi, v.v. Vấn đề là, bạn sẽ không làm những điều đó nếu bạn không thấy bất kỳ lý do nào: những chương trình này sẽ vô dụng đối với bạn nếu mọi thứ bạn nghĩ đã được thực hiện . Cá nhân tôi vẫn mơ ước có thể mã hóa giao thức p2p phi tập trung giống như facebook với trò chuyện, tin nhắn ngoại tuyến, v.v ... tất cả trong một để có thể sử dụng với các thiết bị nhúng không dây. Internet mang đến rất nhiều khả năng, đừng quên suy nghĩ về nó.

4. Trên thực tế, lý thuyết là cần thiết để thực hành, nhưng đó không phải là tất cả: thuật toán và kỹ thuật không phải là một phần của lý thuyết lập trình, có rất nhiều mô hình và cách "chuẩn" khác để thực hiện mã của bạn: mẫu thiết kế, danh sách liên kết, Vân vân.

Có lẽ bạn có thể chọn một ngôn ngữ kịch bản để bắt đầu. Tôi bắt đầu lập trình với ngôn ngữ C. Theo tôi, ngôn ngữ C rất dễ để bắt đầu, nhưng cần nhiều thời gian hơn để biết thuật toán và một cái gì đó về hệ điều hành. Và mỗi khi tôi tập thể dục chỉ đơn giản là với GUI GUI, điều đó khiến tôi chán nản.

Và sau đó tôi đã chọn một ngôn ngữ kịch bản có tên ActionScript để bắt đầu. Ngôn ngữ kịch bản là ngôn ngữ hướng đối tượng và nó có thể điều khiển hành vi của phim Flash. Ngôn ngữ kịch bản dễ dàng thực hiện một số công việc gần với miền vấn đề , giống như trace("HelloWorld")trong ActionScript để xuất ra một chuỗi. Và nó có một IDE mạnh mẽ để cho phép bạn kiểm tra nếu chương trình của bạn đang diễn ra tốt đẹp.

Nói một cách dễ hiểu, nếu bạn muốn bắt đầu lập trình một cách nhanh chóng , một ngôn ngữ kịch bản có thể là một lựa chọn tốt :-)

Viết một đặc tả. Bạn muốn chương trình của bạn làm gì? Các màn hình (nếu là chương trình dựa trên giao diện người dùng) logic, đầu vào / đầu ra, v.v. Giữ phạm vi giới hạn ở những gì bạn có thể làm trong một khoảng thời gian hợp lý (một tuần? Một tháng?).

Sau đó xây dựng nó. Bám sát đặc điểm kỹ thuật, làm cho nó hoạt động theo những gì đặc điểm kỹ thuật cần. Chắc chắn bạn sẽ gặp phải phiền nhiễu, chắc chắn bạn sẽ phải thực hiện một số nghiên cứu vì bạn chưa bao giờ phải đối mặt với một vấn đề cụ thể nào trước đây, nhưng bạn sẽ xây dựng một cái gì đó bạn muốn xây dựng. Điều này khác với việc xây dựng một cái gì đó mà bạn chỉ có thể xây dựng.

Khi bạn hoàn thành, hãy cấu trúc lại mã của bạn, cố gắng làm cho nó hiệu quả hơn. Sau đó, nếu bạn nghĩ rằng chương trình của bạn vẫn chưa được thực hiện, hãy bắt đầu lại, cải thiện đặc tả, cải thiện mã và tiếp tục làm điều này.

Hãy nhớ rằng, hầu hết các phần mềm thương mại đều giải quyết được nhu cầu .. Điều rất quan trọng là xác định nhu cầu và giải pháp để đáp ứng nhu cầu đó trước khi thực sự giải quyết vấn đề. Và khi nhu cầu ngày càng lớn hơn, phần mềm của bạn cũng sẽ phát triển theo thời gian!