Tôi biết cách lập trình và cách học lập trình, nhưng làm thế nào / nơi bạn học cách làm cho hệ thống đúng? [đóng cửa]


11

Có rất nhiều điều cần được xem xét khi tạo một hệ thống, ví dụ như hệ thống dựa trên web nơi người dùng đăng nhập và tương tác với nhau, tạo và chỉnh sửa nội dung. Bây giờ tôi phải suy nghĩ về bảo mật, xác nhận (tôi thậm chí không nghĩ rằng mình chắc chắn 100% những gì đòi hỏi), "đảm bảo người dùng không giẫm chân lên nhau" (thuật ngữ này?), Ngăn ngừa nhiều lỗi các trường hợp, đảm bảo dữ liệu cơ sở dữ liệu không trở thành vấn đề thông qua các tình huống ... bất ngờ? Tất cả những điều này tôi không biết làm thế nào hoặc học ở đâu, có một cuốn sách về loại công cụ này? Giống như tôi đã nói dường như có một sự khác biệt rất lớn giữa viết mã và thực sự viết đúng mã, biết ý tôi là gì không? Tôi cảm thấy như công việc lập trình hiện tại của tôi thiếu phần lớn những gì tôi đã mô tả và tôi có thể thấy những vấn đề mà nó gây ra sau này, và sau đó các vấn đề khó giải quyết hơn nhiều vì dữ liệu tồn tại và mọi người đang sử dụng nó. Vì vậy, bất cứ ai có thể chỉ cho tôi các cuốn sách hoặc tài nguyên hoặc tập hợp con lập trình thích hợp (?) Cho loại hình học tập này?

Tái bút: vui lòng sửa các thẻ của tôi, tôi không biết tôi đang nói về cái gì.

Chỉnh sửa: Tôi giả sử một số ví dụ tôi đã viết áp dụng cho các loại hệ thống khác, tôi chỉ không biết bất kỳ ví dụ hay nào khác vì tôi chủ yếu tham gia vào công việc web.

Câu trả lời:


10

Theo như tôi có thể nói, các lập trình viên chuyên nghiệp học những điều này theo ba cách chính:

  1. Học hỏi từ một kinh nghiệm tồi tệ - Bạn chạy qua một cái gì đó sai. Bạn sửa nó đi. Bạn nói, "Này, tôi không nên làm điều đó một lần nữa. Lần tới tôi sẽ làm X." Bạn rõ ràng trong độ dày của điều đó.
  2. Học trước một trải nghiệm tồi tệ - Cuối cùng, bạn học để thấy một số loại vấn đề sắp tới. Khi bạn làm thế, bạn sẽ cố gắng tránh nó. Có thể bạn đọc một cuốn sách, có thể bạn tìm kiếm trên web, có thể bạn thử một số thí nghiệm.
  3. Học hỏi từ các đồng nghiệp có kinh nghiệm - Điều này cho đến nay là dễ nhất, mặc dù nó vẫn không dễ dàng. Bí quyết là tìm hiểu xem đồng nghiệp có phản ứng với trải nghiệm tồi tệ vẫn còn liên quan hay không. Công nghệ di chuyển trên, sau tất cả.

Tôi khuyến khích bạn bắn cho cả ba. Tìm một nơi với các đồng nghiệp thông minh, có kinh nghiệm, những người sẽ đưa ra câu hỏi của bạn. Hãy chắc chắn rằng đó là một nơi cho phép bạn giao hàng sớm và thường xuyên, để bạn có thể thử nhiều thứ. Và dành thời gian cho nghiên cứu và suy ngẫm.


Đối với # 1), hãy nhớ rằng những trải nghiệm và sai lầm tồi tệ mà bạn học được không nhất thiết phải là của riêng bạn. Dành thời gian trên web, đi chơi ở nơi các lập trình viên làm, tìm hiểu một số câu chuyện kinh dị của họ về những sai lầm điên rồ mà họ đã mắc phải hoặc gặp phải, giữ chúng trong đầu khi bạn lập trình.
Shadur

1
Tôi đồng ý, Shadur, nhưng tôi nghĩ rằng một số trải nghiệm tồi tệ thực sự cần phải là của riêng bạn. Một số người cố gắng ngồi bên lề, chờ đợi cho đến khi họ có thể làm cho điều hoàn hảo. Nhưng họ thực sự cần phải vào đó và bắt đầu thực hiện nếu muốn cải thiện kỹ năng của họ.
William Pietri

4

Khi nói đến các ứng dụng web, có nhiều thông tin hay được biên soạn trong câu trả lời này hơn bất kỳ nơi nào khác tôi từng thấy.

Nhưng thực tế là, có rất nhiều điều cần biết để kết hợp tốt một hệ thống hoàn chỉnh. Có những nghiên cứu hỗ trợ 10.000 giờ vì số lượng thực hành cần thiết để đạt đến mức độ thành thạo, và phát triển hệ thống thông tin cũng không ngoại lệ.


Vì vậy, tôi đoán nó khác nhau cho những thứ khác nhau, eh?
MetaGuru

Nhiều vấn đề sẽ được nói, cụ thể cho các ứng dụng web và nhiều vấn đề sẽ chung chung hơn. Không chắc chắn tôi hoàn toàn hiểu những gì bạn đang hỏi tho.
quentin-starin

3

Tôi thích câu trả lời của William Pietri rất nhiều (+1), nhưng tôi tin rằng nó cần được thêm vào. Ngay cả giả định rằng những gì bạn có ý nghĩa của các hệ thống chỉ bao gồm phần mềm.

Nhưng trước khi đi vào phần thịt của nó, tôi không biết về một cuốn sách để giúp đỡ. Tất cả những gì tiếp theo, tôi học được từ kinh nghiệm (có nghĩa là ba điểm mà William đã thực hiện).

Những gì bạn đang nói về nhịp ở tối thiểu bốn vai trò rộng. Đôi khi một người có thể điền vào tất cả các vai trò đó, cho các dự án vừa và nhỏ, nhưng khi bạn bắt đầu vào các dự án lớn, bạn cần ít nhất tách biệt các vai trò đó ra. Khó có ai có thể trở thành chuyên gia về tất cả chúng theo bất kỳ cách có ý nghĩa nào.

  1. Phân tích kinh doanh

    Đó là người nói chuyện với khách hàng và chuyển các yêu cầu của họ thành thứ mà một kiến ​​trúc sư có thể hiểu được. Về cơ bản một danh sách các yêu cầu công thức đúng. Điều này bao gồm các yêu cầu chức năng rõ ràng (hệ thống này phải cung cấp những gì?), Nhưng cũng yêu cầu phi chức năng (các đặc điểm chung mà hệ thống phải đáp ứng là gì? Điều này có thể bao gồm bảo mật, độ tin cậy, tính sẵn sàng, khả năng phục hồi, hiệu suất, hiệu suất, độ bền các yêu cầu khác như vậy từ quan điểm người dùng).

    Đây là lần đầu tiên vượt qua những gì hệ thống phải làm, sự khởi đầu của suy nghĩ nghiêm túc.

  2. Kiến trúc hệ thống

    Người này sản xuất khung kỹ thuật cấp cao để làm việc. Họ đưa ra kế hoạch phù hợp với phác thảo. Các công cụ chung, kỹ thuật, cấu trúc. Họ chia nhỏ toàn bộ hệ thống thành các thành phần nhỏ hơn, cách chúng phù hợp với nhau, cách chúng phù hợp với thế giới bên ngoài ...

    Điều này giúp theo nhiều cách tinh chỉnh những gì cần phải suy nghĩ. Rất thường các vấn đề sẽ được phát hiện ở giai đoạn đó về các yêu cầu được viết bởi nhà phân tích kinh doanh. Quay lại với họ cho một số lần lặp lại để cải thiện sự hiểu biết của họ về những gì họ muốn và biểu hiện của họ về nó.

  3. Thiết kế hệ thống

    Vai trò này là về cách làm cho tất cả hoạt động. Đây có thể là công việc nhóm nhiều hơn một chương trình một người đàn ông. Nhưng có khả năng một nhà thiết kế chính sẽ giám sát toàn bộ thiết kế hệ thống. Người này phải đi sâu vào chi tiết và đảm bảo tầm nhìn của kiến ​​trúc sư là thứ thực sự có thể được xây dựng.

    Mong đợi tinh chỉnh hơn nữa kiến ​​trúc của hệ thống, và do đó có khả năng phân tích kinh doanh.

  4. Quản lý kiểm tra

    Vai trò này rất thường bị lãng quên. Nhưng vào cuối ngày nếu bạn không thể kiểm tra nó, làm thế nào bạn có thể chứng minh rằng bạn có thể xây dựng nó? Phải có đánh giá về kết quả của tất cả các giai đoạn: phân tích kinh doanh, kiến ​​trúc và thiết kế bởi một người có thẩm quyền trong thử nghiệm, người sẽ có thể làm nổi bật các thiếu sót và do đó cho phép sửa chữa sớm, trước khi bất kỳ mã nào được viết.

Đó là một bản tóm tắt ngắn.

Những kẻ / cô gái đó chỉ là người điều hành chung của các nhà máy trong chuỗi để suy nghĩ về những gì phải suy nghĩ.

Đối với các dự án phức tạp như ngân hàng lớn hoặc ứng dụng không gian chỉ cần lấy hai ví dụ (nghĩ nhiều hàng trăm đến hàng nghìn ngày), có nhiều chuyên gia về chủ đề khi chúng tôi gọi họ để xem xét và hỗ trợ các dự án ở mọi giai đoạn. Những vai trò này bao gồm phân tích bảo mật, kích thước hệ thống, năng lực, hiệu suất, cơ sở dữ liệu, phân cụm và nhiều lĩnh vực chuyên môn hẹp khác, bao gồm các lĩnh vực kinh doanh chính xác. Sự đa dạng của các vai trò phụ thuộc vào quy mô và độ phức tạp của các hệ thống.

Tất cả điều đó để nói rằng bạn không nên thử và biết tất cả, bạn sẽ không. Tuy nhiên, bạn có thể nắm bắt được bức tranh tổng thể và trong các dự án nhỏ, bạn có thể đi sâu vào nhiều hơn so với các dự án lớn, đơn giản vì mức độ phức tạp cho phép bạn trở nên tròn trịa hơn.

Nếu bạn muốn biết cách thiết kế hệ thống, thì bạn cần bắt đầu đặt câu hỏi bằng cách suy nghĩ bên ngoài hộp. Đặt mình đủ vào đôi giày của khách hàng và thử và nghĩ xem điều gì có thể sai, điều gì cần thử nghiệm. Sau đó, cùng với một khách hàng thực sự và thúc đẩy họ giải thích các phạm vi và giới hạn của hệ thống mà họ hình dung họ cần. Ngoài ra, bất cứ khi nào tôi nói 'khách hàng', bạn phải hiểu rằng điều này bao gồm một số người rất khác nhau. Có người sử dụng hệ thống hàng ngày cho những gì nó được thiết kế để làm. Có nhà điều hành, hỗ trợ kỹ thuật, người quản lý cần một số báo cáo hoặc người khác, kiểm toán viên, nhóm cơ sở hạ tầng, các bên liên quan đã trả tiền cho nó, người quản lý chất lượng cần phương tiện để kiểm tra hệ thống của bạn ... Hãy hỏi tất cả họ (và nếu họ là một người, yêu cầu họ đặt tất cả những chiếc mũ này cùng một lúc), vì vậy hãy hỏi họ tất cả những gì họ cần và bạn sẽ có một khởi đầu tốt khi biết yêu cầu hệ thống của bạn là gì. Từ đó bạn có thể rút ra kiến ​​trúc, và từ đó thiết kế.

Đối với các hệ thống phức tạp (dù chỉ là phần mềm hoặc tích hợp với phần cứng theo nghĩa chung nhất), không chỉ một người không đủ cho mỗi bốn vai trò tôi liệt kê ở trên, mà bạn cần quản lý dự án ngay cả định nghĩa về hệ thống phải làm, hãy để một mình các giai đoạn khác.

HPH, asm.


2

Ở đây để tìm hiểu, có một cuốn sách về loại công cụ này?

Không phải "một cuốn sách". Rât nhiêu sach.

Không có con đường hoàng gia

Như tôi đã nói dường như có một sự khác biệt rất lớn giữa viết mã và thực sự viết đúng mã

Đúng.

Bạn đang nói về "kiến trúc", lập trình lớn.

Bước 1. Đọc rất nhiều mã. Rất nhiều. Hãy nghĩ về những điều bạn muốn làm. Tìm các dự án nguồn mở liên quan. Đọc mã. Tất cả.

Bước 2. Đọc thêm mã. Hơn rất nhiều.

Bước 3. Đọc sách về kiến ​​trúc.


2
Đọc đọc đọc. Nhưng tôi phải đề nghị nó không giống với những gì bạn học được khi bạn thực sự triển khai các hệ thống thực sự.
quentin-starin

@qes: Câu hỏi là "bạn học cách làm cho hệ thống đúng cách?" Bạn không học được điều đó bằng cách xây dựng các hệ thống thực sự tồi tệ. Thật vậy, thực hiện các hệ thống thực sự là điều ngược lại hoàn toàn với việc học.
S.Lott

3
Từ Code Complete, một trong những điều tôi thích nhất: "Lĩnh vực công nghệ phần mềm khiến việc sử dụng bị hạn chế một cách bất thường các ví dụ về những thành công và thất bại trong quá khứ. Nếu bạn quan tâm đến kiến ​​trúc, bạn sẽ nghiên cứu bản vẽ của [kiến trúc sư nổi tiếng] ... thăm một số tòa nhà ... ".
Jacob

@ S.Lott: ai nói bất cứ điều gì về việc làm điều đó xấu?
quentin-starin

@qes: không đọc nghệ thuật trước, tỷ lệ làm tốt một chương trình quy mô lớn là gì? Đối với một thiên tài như bạn, có thể người ta có thể đơn giản viết các chương trình tốt mọi lúc và mọi quy mô. Nhưng đối với những người khác đã không nhìn vào lập trình quy mô lớn, bắt đầu bằng cách cố gắng thực hiện một hệ thống lớn mà không đọc bất cứ điều gì là một cách để viết một cái gì đó chứa rất nhiều sai lầm mà không có gì có thể học được từ nó. Trải nghiệm của bạn có thể khác, nhưng tôi biết rằng tôi không đủ thông minh để làm việc mà không đọc trước.
S.Lott

1

Để khuếch đại đọc nhiều sách ....

Bây giờ bạn biết bạn có một vấn đề, có một số điểm trong việc bảo bạn đọc những cuốn sách này. (Trước khi bạn thực hiện một số công việc thực tế, có rất ít điểm để thảo luận về những cuốn sách này)

Các mẫu thiết kế của Gamma, Helm, Johnson và Vlissides Ngôn ngữ mẫu của thiết kế chương trình 1,2,3 và 4.

Nhưng đừng cố gắng áp dụng mọi patter ở mọi nơi bạn thấy nó có thể được sử dụng

đó cũng là một điều xấu

Hi vọng điêu nay co ich.


1

Cách tốt nhất để học cách làm bất cứ điều gì là làm điều đó. Nếu bạn muốn học cách nói tiếng Pháp, bạn phải nói tiếng Pháp, đọc tiếng Pháp và viết tiếng Pháp và đọc về tiếng Pháp và đi đến Pháp và nói chuyện với người Pháp bằng tiếng Pháp. Nếu bạn muốn biết chơi piano, bạn phải thực sự chơi piano. Bạn phải chơi những bài hát đơn giản và học cấu trúc của piano và cấu trúc của âm nhạc. Bạn phải học cách đọc nhạc và cách thể hiện âm nhạc qua piano bằng ngón tay. Bạn phải tìm hiểu âm nhạc nghe như thế nào và loại đàn piano nào có thể tạo ra so với những gì guitar hoặc sáo hoặc saxophone có thể làm.

Lập trình hoàn toàn giống nhau. Nếu bạn biết cách thiết kế cơ sở dữ liệu, bạn phải thiết kế cơ sở dữ liệu. Nếu bạn muốn hiểu về mật mã, hãy thực hiện các thuật toán mã hóa và các giao thức mã hóa. Nếu bạn muốn viết phần mềm có thể phục vụ đồng thời nhiều người dùng, bạn phải hiểu cách IO của đĩa, IO mạng và luồng hoạt động. Để hiểu cách thức hoạt động, bạn có mã viết và đọc từ tệp, truyền dữ liệu qua mạng và đồng bộ hóa quyền truy cập vào tài nguyên. Tất cả điều đó đòi hỏi phải thực hành.

Một "hệ thống" nói chung chỉ là một bộ sưu tập các thứ. Các mảnh phối hợp để tạo thành một tổng thể. Để xây dựng một cái gì đó lớn, bạn phải xây dựng một loạt các phần nhỏ. Vì vậy, nếu bạn muốn học cách xây dựng hệ thống, hãy bắt đầu xây dựng hệ thống. Lấy một vấn đề, chia thành từng mảnh và thực hiện từng phần một. Cuối cùng, bạn sẽ có một "hệ thống" tích hợp. Có thể bạn sẽ thất bại một vài lần trên đường đi, nhưng điều đó không sao cả. Nếu bạn không thất bại, điều đó thường có nghĩa là bạn không cố gắng đủ.

Ngoài ra, tôi khuyên bạn nên đi học để học Khoa học Máy tính. Điều đó sẽ không giúp quá nhiều với phần "thực hành". Bạn sẽ phải tự làm điều đó, nhưng nó sẽ giúp với phần tiếp xúc. Bạn sẽ học được rất nhiều, về hầu hết mọi thứ liên quan đến cách máy tính và hệ thống máy tính hoạt động, rất khó để tự học.


1
+1, mặc dù tôi sẽ đề nghị rằng chỉ cần làm là không đủ. Bạn sẽ không biết liệu bạn đã làm tốt hay xấu cho đến khi bạn xem lại cùng một mã sau khi một thời gian trôi qua. Và thậm chí sau đó, bạn có thể biết có gì đó không ổn, nhưng không làm thế nào để cải thiện nó. Một cách để rút ngắn tất cả những điều đó là đảm bảo nhiều phản hồi quảng cáo từ những người có kinh nghiệm hơn về những gì bạn đang cố gắng học. Vì vậy, có, "làm" là rất quan trọng, nhưng phản hồi về những gì bạn làm thậm chí có thể nhiều hơn để tăng tốc quá trình học tập.
Marjan Venema
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.