Gần đây tôi đã tốt nghiệp đại học và bắt đầu làm lập trình viên. Tôi không thấy khó giải quyết các vấn đề "kỹ thuật" hoặc gỡ lỗi với những điều tôi muốn nói có 1 giải pháp.

Nhưng dường như có một loại vấn đề không có một giải pháp rõ ràng - những thứ như kiến ​​trúc phần mềm. Những điều này làm tôi bối rối và khiến tôi đau khổ vô cùng.

Tôi dành hàng giờ để cố gắng quyết định làm thế nào để "kiến trúc sư" các chương trình và hệ thống của tôi. Ví dụ: tôi có chia logic này thành 1 hoặc 2 lớp không, làm cách nào để đặt tên cho các lớp, tôi nên đặt riêng tư hay công khai, v.v. Những loại câu hỏi này chiếm quá nhiều thời gian của tôi và nó làm tôi rất thất vọng. Tôi chỉ muốn tạo chương trình - kiến ​​trúc bị nguyền rủa.

Làm thế nào tôi có thể vượt qua giai đoạn kiến ​​trúc nhanh hơn và vào giai đoạn mã hóa và gỡ lỗi mà tôi thích?

Hoàn hảo là kẻ thù của tốt.

Điều đó nói rằng, bạn không nên cắt góc. Thiết kế phần mềm sẽ có tác động lâu dài hơn và giúp bạn (và đồng nghiệp) tiết kiệm hàng tấn thời gian và công sức trong tương lai. Sẽ mất nhiều thời gian hơn để có được đúng. Hầu hết thời gian dành cho lập trình không phải là gõ bàn phím, mà bằng một bảng trắng tìm ra cách giải quyết vấn đề.

Nhưng bạn cũng không nên lo lắng về sự hoàn hảo. Nếu hai thiết kế chiến đấu đến bế tắc, điều đó có nghĩa là chúng có khả năng giống nhau. Chỉ cần đi với một. Không phải là bạn không thể thay đổi mọi thứ một khi bạn tìm ra những sai sót trong thiết kế đó.

(Và hy vọng nó cũng sẽ giúp ích khi bạn phát hiện ra rằng không chỉ có một cách để gỡ lỗi / giải quyết các vấn đề kỹ thuật.)

Đối với các chương trình đơn giản và nhỏ (ví dụ với ít hơn mười nghìn dòng mã nguồn), bạn có thể kiến ​​trúc chúng trong khi viết mã. Nếu bạn áp dụng cách tiếp cận phát triển lặp và tăng dần , bạn sẽ dần dần đưa ra quyết định về kiến ​​trúc: vì vậy hãy viết vài chục dòng mã (thêm một số tính năng vi mô duy nhất), cải thiện chúng cho đến khi không có cảnh báo nào trở lại từ trình biên dịch của bạn, hãy kiểm tra xem trình gỡ lỗi của bạn và lặp lại.

Tôi có phân chia logic này thành 1 hoặc 2 lớp không, làm cách nào để đặt tên cho các lớp, tôi nên đặt riêng tư hay công khai, v.v. Những loại câu hỏi này chiếm quá nhiều thời gian của tôi

Họ không nên. Và họ không quan trọng đến mức đó đối với một chương trình nhỏ (vì các chương trình nhỏ, đơn giản dễ cải thiện hơn, ví dụ như thay đổi tên, v.v ...). Bạn chỉ cần nhất quán và ưu tiên khả năng đọc mã nguồn của bạn. Thỉnh thoảng bạn có thể thấy cần phải cấu trúc lại một số phần nhỏ trong chương trình của mình (và đó không phải là vấn đề lớn).

So sánh điều này với nhiều dự án phần mềm miễn phí (ngay cả những dự án lớn như nhân Linux). Các nhà phát triển đã không dành nỗ lực đáng kể "kiến trúc" trong giai đoạn đầu. UML gần như không bao giờ được sử dụng trong phần mềm miễn phí . Ngoài ra, bạn sẽ học được khá nhiều bằng cách nghiên cứu mã nguồn của một số dự án phần mềm miễn phí.

Là một người mới, bạn sẽ làm việc trong một dự án phần mềm lớn trong một nhóm, nơi bạn có thể tin tưởng đơn giản vào nhà phát triển cấp cao (người đưa ra quyết định kiến ​​trúc) hoặc bạn sẽ làm việc một mình trong các dự án nhỏ (thông thường, ít hơn vài chục nghìn dòng mã nguồn). Trong trường hợp sau, bạn sẽ đưa ra quyết định kiến ​​trúc gia tăng, thỉnh thoảng tái cấu trúc ứng dụng của bạn, sau đó "thiết kế kiến ​​trúc" sẽ phát triển tự nhiên.

Làm thế nào tôi có thể nhanh chóng vượt qua giai đoạn kiến ​​trúc và vào giai đoạn mã hóa và gỡ lỗi mà tôi thích?

Đối với các dự án phần mềm nhỏ, mất ít hơn một năm làm việc, rất dễ dàng: không làm kiến ​​trúc. Có lẽ dành nửa giờ để suy nghĩ về thiết kế tổng thể. Sau đó bắt đầu viết mã, với cách tiếp cận phát triển lặp và tăng dần : viết vài chục dòng, biên dịch mã (với tất cả các cảnh báo và thông tin gỡ lỗi được bật, ví dụ như g++ -Wall -Wextra -gvới GCC cho C ++) cho đến khi bạn không nhận được cảnh báo nào (và chuyển nó vào một nguồn tĩnh đơn giản bộ phân tích mã, nếu bạn có một, ví dụ như bộ phân tích clang ), hãy kiểm tra mã đó với trình gỡ lỗi , cam kết nó với kiểm soát phiên bản của bạn (ví dụ git), rửa sạch và lặp lại. Tuy nhiên, hãy chắc chắn để tránh nợ kỹ thuật: khi một cái gì đó có mùi hôi, hãy thực hiện (bằng cách tái cấu trúc và thực hiện lại) để cải thiện nó.

Mặt khác, trong môi trường nhóm, công việc kiến ​​trúc đòi hỏi phải thảo luận ban đầu để xác định trách nhiệm của mọi thành viên trong nhóm. Cuộc thảo luận đó được dẫn dắt bởi nhà phát triển cấp cao (người không phải là người mới). Đọc về phát triển phần mềm nhanh và Tháng huyền thoại .

Tôi chỉ muốn tạo chương trình, kiến ​​trúc bị phá hủy.

Trực giác tuyệt vời (ít nhất là cho các dự án nhỏ). Vì vậy, hãy suy nghĩ vài phút về chương trình của bạn và bắt đầu mã hóa nó bằng cách tiếp cận phát triển lặp lại và tăng dần : mã hóa vài chục dòng và đảm bảo chúng hoạt động tốt, sau đó lặp lại. Trước đó, nghiên cứu mã nguồn (và quan sát kiến ​​trúc) của các dự án phần mềm miễn phí tương tự và nói chung là thực hiện một số công việc và nghiên cứu thư mục.

Trong một số trường hợp, hãy nghĩ về cách tiếp cận siêu lập trình : có những tình huống bạn muốn tạo một số "tệp nguồn" (ví dụ bao gồm sử dụng trình tạo trình phân tích cú pháp như bison , trình tạo mã keo như SWIG , Google protobuf và đôi khi bạn có thể muốn viết tập lệnh đơn giản - hoặc sử dụng một bộ tiền xử lý chung như GPP - để phát ra một số mã C ++ hoặc Java của bạn để tránh mã hóa lặp đi lặp lại).

Tái bút Tôi là một kỹ sư nghiên cứu, có bằng tiến sĩ về khoa học máy tính và 40 năm kinh nghiệm và tôi chưa bao giờ làm "kiến trúc" như câu hỏi của bạn, trong khi đã làm việc thành công trên một số dự án cỡ trung bình và một vài dự án lớn (chính trình biên dịch GCC ). Đối với tôi "kiến trúc" chỉ là giai đoạn lập kế hoạch cho công việc của vài ngày hoặc vài tuần tới (và tôi thường làm điều đó trong khi mơ hoặc ngủ và chắc chắn không có máy tính, và thường không có bút chì). Ngoài ra, khi viết tài trợ nghiên cứu , tôi bằng cách nào đó và không hoàn chỉnh thiết kế một kiến ​​trúc.

NB: một số dự án phần mềm cần nhiều kiến ​​trúc hơn các dự án khác. Ví dụ: nếu bạn viết hệ thống điều khiển của tim nhân tạo hoặc robot phẫu thuật thần kinh, bạn sẽ không hoạt động giống như khi viết ứng dụng điện thoại di động trung bình. Xem thêm Norvig's Dạy bản thân lập trình trong trang mười năm .

Có ba phương châm tôi muốn ghi nhớ.

• "Mọi thứ nên được làm đơn giản nhất có thể, nhưng không đơn giản hơn"

  Để lấy ví dụ của bạn về "một hoặc hai lớp?", Tôi hỏi, "đâu là giải pháp đơn giản hơn?"

• "Không có lỗi rõ ràng" so với "Rõ ràng là không có lỗi"

  Thứ hai là thích hợp hơn!

  Và đó là lý do tại sao nó cần phải đơn giản, tức là bạn có thể suy luận về nó. Một lớp lớn có thể (hoặc có thể trở nên) quá lớn và quá phức tạp để giải thích, trong trường hợp đó, bạn chia nó thành nhiều lớp nhỏ hơn, trong đó bạn có thể nói "Mỗi lớp đều nhỏ và làm theo những gì nó sẽ làm - và giao diện của chúng rất đơn giản và chúng kết hợp đúng cách. "

  1. Mã phải chạy trong lý thuyết (tức là trong đầu của bạn).
  2. Sau đó, nếu nó không hoạt động trong thực tế, bạn có thể gỡ lỗi cho đến khi thực hành phù hợp với lý thuyết.

  Một người mới đôi khi không bận tâm đến bước 1, tức là chạy nó trong đầu của bạn (ví dụ vì nó quá phức tạp) - nhưng trong trường hợp đó, nó chỉ chạy "một cách tình cờ" chứ không phải "trên lý thuyết", có thể là do bạn trốn tránh T đã kiểm tra nó đủ để tìm ra lỗi không rõ ràng.

• Luật pháp của Gall

  Đây được gọi là "tái cấu trúc".

  Trong thực tế điều này có nghĩa là:

  1. Bắt đầu với một hệ thống đơn giản [ny] hoạt động
  2. Bây giờ là lúc để thêm một tính năng mới
  3. Tái cấu trúc hệ thống hiện có để dễ dàng thêm tính năng mới

  4. Thêm tính năng mới

  5. ... và lặp lại như trên

  Điều này phù hợp với phương châm như YAGNI tức là không tái cấu trúc (lo lắng về kiến ​​trúc) trước khi bạn cần ... nhưng tạo kiến ​​trúc phù hợp ngay lúc đó, tức là khi bạn cần nó cho một số mục đích cụ thể.

Những gì bạn có thể làm là bắt đầu với số lượng trừu tượng tối thiểu mà bạn cần. Ví dụ, một lớp Người trong một tệp. Bây giờ khi bạn tiếp tục thêm mã và các tính năng, bạn bắt đầu thấy những thứ cần được chuyển sang một bản tóm tắt khác. Ví dụ, nguyên tắc trách nhiệm duy nhất (S của RẮN) cho bạn biết không có các phương thức liên quan đến phân tích địa chỉ trong lớp Người. Vì vậy, bây giờ bạn biết rằng bạn cần một lớp Địa chỉ.

Nhưng thật tốt khi dành chút thời gian để suy nghĩ về "số lượng trừu tượng tối thiểu" trông như thế nào đối với hệ thống của bạn. Bắt đầu từ một kiến ​​trúc đủ tốt và cải thiện nó khi bạn đi.

chỉnh sửa: @Basile answer đưa ra một ví dụ về cách bạn có thể lặp lại và cải thiện kiến ​​trúc tối thiểu của mình.

Thời gian dành cho việc nghĩ về kiến ​​trúc của một hệ thống không phải là lãng phí thời gian.

Tôi tin rằng câu hỏi của bạn có thể được đánh giá lại là "làm thế nào tôi có thể hiệu quả hơn với việc đưa ra quyết định kiến ​​trúc?".

Câu trả lời ngắn gọn của tôi cho điều đó sẽ là: bạn cần khám phá các nguyên tắc cốt lõi sẽ cho phép bạn đưa ra quyết định một cách đáng tin cậy và hiệu quả và sau đó bạn cần phải thực sự ra ngoài và định hình một phần mềm trong thế giới thực. Đây sẽ là một hành trình dài tìm kiếm kiến ​​thức, thử nghiệm và sai sót và phát triển cá nhân.

-

Và để có câu trả lời dài hơn ...

Trước tiên tôi nên làm rõ các khái niệm: Tôi sử dụng kiến trúc từ để mô tả cấu trúc của một hệ thống phần mềm phức tạp khi tôi làm việc với các quy trình, dịch vụ, API và cơ sở dữ liệu. Tôi sử dụng thiết kế từ để mô tả cấu trúc của chỉ một phần trong một hệ thống phức tạp hơn, khi tôi đang làm việc với các lớp, hàm và thư viện. Đây là những định nghĩa của tôi, một số người có định nghĩa khác nhau. Nhưng trong bối cảnh này, tôi tin rằng bạn đang nói về thiết kế .

Tôi nghĩ có 3 điều quan trọng cần ghi nhớ khi thảo luận về chủ đề này:

• kiến trúc và thiết kế tồn tại mà không có chúng được mô tả rõ ràng thông qua các sơ đồ hoặc tài liệu, cũng không có chúng được duy trì bởi một nhóm hoặc một người (một kiến trúc sư ). Bất kỳ hệ thống nào cũng có kiến ​​trúc nội tại và thiết kế nội tại có thể được mô tả sau thực tế.

• phát triển phần mềm không phải là lập trình, nó là lập trình theo thời gian. Tôi đang làm cho sự khác biệt này bởi vì tôi nghĩ rằng đó là một trong những điểm mù lớn nhất đối với những người đến trong ngành (bao gồm cả bản thân tôi, tại một thời điểm). Điều này có nghĩa là, so với các dự án đại học hoặc các dự án cá nhân, làm việc trên một hệ thống phần mềm trong thế giới thực phức tạp hơn theo cấp số nhân, bởi vì bất kỳ quyết định kiến ​​trúc nào cũng sẽ có tác động lớn đến sự phát triển của hệ thống. Quyết định của bạn bây giờ sẽ trở lại ám ảnh bạn, đảm bảo.

• bởi vì kiến ​​trúc và thiết kế tồn tại theo nguyên tắc và bởi vì cơ sở mã là một sinh vật phát triển theo thời gian, kiến ​​trúc và thiết kế cũng cần phải phát triển. Họ sẽ tiến hóa một cách có kiểm soát thông qua các quyết định có ý thức được đưa ra vào thời điểm xác chết, hoặc họ sẽ tiến hóa một cách hỗn loạn, được thúc đẩy bởi mã hóa. Điều này rất quan trọng để hiểu, bởi vì nó có nghĩa là cách tiếp cận truyền thống của "kiến trúc sư đầu tiên và viết mã thứ hai" là thiếu sót. Tất nhiên, khi bắt đầu một dự án từ đầu, một số công việc kiến ​​trúc và thiết kế cần phải được thực hiện trước. Nhưng khác với điều đó, sẽ có rất nhiều quyết định về kiến ​​trúc và thiết kế vẫn được đưa ra trong khi phát triển hệ thống.

Để chắt lọc những điều trên hơn nữa, điều rất quan trọng là phải nhận thức được thực tế rằng bạn sẽ đưa ra quyết định thiết kế trong khi viết mã, có ý thức hoặc không. Bạn nên cố gắng đưa ra nhiều quyết định một cách có ý thức và phê phán, vì bất kỳ quyết định nào được đưa ra nhẹ đều có thể ảnh hưởng lớn đến công việc trong tương lai (tác động này thường thể hiện ở cơ sở mã trở nên rất khó thay đổi để sửa lỗi hoặc triển khai các tính năng). Robert C. Martin minh họa điều này rất đẹp, với dữ liệu, trong cuốn sách "Kiến trúc sạch" (mà tôi rất khuyến khích bằng cách này).

Vì vậy, bây giờ chúng ta biết tại sao kiến ​​trúc và thiết kế là quan trọng, các nguyên tắc cốt lõi có thể cho chúng ta một khuôn khổ phù hợp để đưa ra quyết định tốt là gì? Tôi đã có câu hỏi này sớm hơn trong sự nghiệp của mình, tôi cảm thấy như thiếu một cái gì đó trong bộ công cụ của mình nhưng không biết gì, không biết làm thế nào để mô tả nó hoặc đi tìm nó. Tôi sẽ chia sẻ một số nguyên tắc mà tôi đã khám phá theo thời gian và tôi hy vọng chúng sẽ giúp cuộc sống của bạn dễ dàng hơn một chút:

• có thể chọn một tập hợp các thủ thuật mã hóa rất đơn giản nhưng mạnh mẽ bằng cách đọc cuốn sách "Tái cấu trúc: Cải thiện thiết kế của mã hiện tại" của Martin Fowler. Có quá nhiều thứ để liệt kê ở đây, nhưng đây là những quyết định thời gian mã hóa rất thấp mà bạn có thể thực hiện để cải thiện đáng kể cấu trúc mã của mình và giúp bạn đưa ra quyết định thiết kế. Cuốn sách cũng là một trường hợp tốt để tích hợp kiểm thử đơn vị vào quy trình công việc cá nhân của bạn và cách viết mã kiểm tra.

• đặc biệt đối với OOP, bạn nên xem xét các nguyên tắc RẮN . Chúng hơi trừu tượng và khó khăn để bao bọc tâm trí của bạn lúc đầu, nhưng rất mạnh mẽ. Tôi khuyên bạn nên bắt đầu với 2 người đầu tiên để có được lợi ích nhanh nhất:

Nguyên tắc trách nhiệm duy nhất : một lớp chỉ nên có một trách nhiệm duy nhất (nghĩa là chỉ thay đổi một phần trong đặc tả của phần mềm sẽ có thể ảnh hưởng đến đặc tả của lớp).

Nguyên tắc mở / đóng : "Các thực thể phần mềm Nên mở để mở rộng, nhưng đóng để sửa đổi."

• khái niệm thành phần trên thừa kế

  nguyên tắc rằng các lớp nên đạt được hành vi đa hình và tái sử dụng mã theo thành phần của chúng (bằng cách chứa các thể hiện của các lớp khác thực hiện chức năng mong muốn) thay vì kế thừa từ lớp cơ sở hoặc lớp cha.

• các khái niệm về khớp nối ("mức độ phụ thuộc lẫn nhau giữa các mô-đun phần mềm") và sự gắn kết ("mức độ mà các yếu tố bên trong mô-đun thuộc về nhau.")
• các DRY (Do not Repeat Yourself) khái niệm
• các khái niệm tách lệnh / query ( "mọi phương pháp, hoặc phải là một lệnh mà thực hiện một hành động, hay một truy vấn mà trả về dữ liệu cho người gọi, nhưng không phải cả hai")
• khái niệm về hệ thống trạng thái so với trạng thái không trạng thái (quy tắc của tôi là: tránh xử lý trạng thái; xây dựng hệ thống không trạng thái càng nhiều càng tốt).

Tất nhiên, đây chỉ là khái niệm, không phải quy tắc. Bước đầu tiên là hiểu họ và nhận thức về họ. Tiếp theo thực sự sử dụng chúng trong thực tế và xây dựng kinh nghiệm khi nào bạn nên theo dõi họ và khi nào bạn không nên làm theo. Và sau đó là một quá trình liên tục tinh chỉnh sự hiểu biết của bạn về các khái niệm này, các mặt tiêu cực và các tương tác phức tạp của chúng với nhau.

Tôi nghĩ lời khuyên quý giá nhất tôi có thể dành cho bạn là: hãy kiên nhẫn với chính mình. Bạn chỉ bắt đầu xuống một con đường dài nhưng đầy đủ. Tiếp tục thực hành và thử nghiệm, lưu ý những gì hoạt động và những gì không và bạn sẽ chỉ trở nên tốt hơn theo thời gian.

Hầu hết những gì bạn mô tả không phải là kiến ​​trúc thực sự (quan trọng) - đặt tên tốt và thiết kế lớp tốt là thứ nên là bản chất thứ hai đối với bạn. Điều này chỉ đơn giản là sẽ tốt hơn khi bạn càng nhiều mã. Hữu ích nhất cho những mối quan tâm như vậy thường là lập trình cặp - nó giúp làm rõ những vấn đề như vậy và giúp bạn học cách này hiệu quả.

Trường hợp kiến ​​trúc là cần thiết TRƯỚC KHI dự án:

1. Tập hợp các yêu cầu chính xác và các yêu cầu phi chức năng (tôi cần hỗ trợ bao nhiêu yêu cầu / giây?). Bất kỳ lỗi nào trong giai đoạn này sẽ dẫn đến địa ngục mã hóa - tích hợp các ý tưởng bị bỏ lỡ sau khi thực tế là tốn thời gian, gây phiền nhiễu và đôi khi không thể. Tôi biết điều này không thú vị bằng mã hóa, nhưng cố gắng lấy mã để làm một cái gì đó mà nó không được thiết kế thậm chí còn ít thú vị hơn.

2. Nếu thích hợp, hãy xác định bối cảnh giới hạn của hệ thống của bạn và đảm bảo rằng bạn có vốn từ vựng của mình, ví dụ: nếu doanh nghiệp nói về "Frobbels", hãy đảm bảo bạn đặt tên lớp / giao diện, v.v. bằng "*** Frobbels". Nghe có vẻ tầm thường, nhưng nếu bạn nói về quy trình công việc, trong khi doanh nghiệp nói về hoạt động, dịch thuật sẽ gây khó chịu rất nhanh.

3. Nếu bạn làm việc với nhiều người / nhóm mô tả giao diện của bạn sớm và đảm bảo mọi giả định và vấn đề đều được mọi người hiểu - nếu bạn không có bối cảnh chung, tích hợp sẽ rất "vui". Ví dụ: bạn xây dựng một trình tạo hình ảnh chuối, nhưng frontend-dev của bạn cần một trình tạo hình ảnh táo. Hoặc bạn xây dựng một cái gì đó có thể trả lời 100 yêu cầu / giây, nhưng 10000 r / giây là cần thiết.

Lưu ý: điều này bị ảnh hưởng nhiều bởi công việc của tôi trên kiến ​​trúc microservice. Làm thế nào phục vụ được xây dựng nội bộ, cũng có thể được kiến ​​trúc - nhưng hầu hết thời gian nó ít quan trọng hơn việc có được bức tranh lớn.

Tôi sẽ không ném một loạt các thuật ngữ và chữ viết tắt cho bạn (hầu hết trong số đó hầu như không được thỏa thuận bởi phần lớn các lập trình viên / kỹ sư phần mềm). Thay vào đó, hãy xem xét những điều sau đây:

1. Bạn đang học - bạn không lãng phí thời gian, bạn đang thử các cách tiếp cận khác nhau và học những gì hiệu quả. Bạn có thể làm điều này mà không cần lên kế hoạch trước nhiều, bằng cách đi sâu vào một vấn đề với giải pháp đầu tiên xuất hiện và thay đổi nó nếu hoặc khi nó không hoạt động. Nếu nó hoạt động tốt, tuyệt vời! Bạn đã tìm thấy một giải pháp đơn giản cho một vấn đề. Các giải pháp đơn giản chỉ tốt nếu chúng hoạt động tốt, và đôi khi chúng đủ tốt .

2. Mọi thứ đều là sự đánh đổi - bạn có thể thiết kế cùng một hệ thống theo nhiều cách khác nhau, đánh đổi thời gian và không gian, sự phức tạp và linh hoạt, trừu tượng và dễ đọc, hoặc bất kỳ một trong nhiều sự đánh đổi có thể. Không có giải pháp nào là hoàn hảo về mọi mặt và không có quy tắc nào là không có ngoại lệ trong công nghệ phần mềm. Bất cứ ai nói với bạn nếu không là ngây thơ hoặc bán một cái gì đó.

3. Là một sinh viên tốt nghiệp gần đây, mã hóa và gỡ lỗi có thể rất thú vị, nhưng điều này sẽ mất dần theo thời gian và các kỹ năng bạn đang học sẽ phục vụ tốt cho bạn khi có.

4. Tôi sẽ lập luận rằng phần mềm xây dựng là nghệ thuật / thủ công hơn là kỹ thuật. Nghệ thuật tuyệt vời không chỉ là về những nét vẽ riêng lẻ, mà là về những quyết định và sự đánh đổi cấp cao được thực hiện bởi nghệ sĩ / nghệ nhân.

Tôi sẽ cố gắng trả lời câu hỏi này xuất phát từ quan điểm phát triển web (có nghĩa là: đến từ một lĩnh vực mà mọi người thống khổ về kiến ​​trúc rất nhiều). Tôi sẽ bắt đầu với việc giải thích lý do tại sao mọi người quan tâm đến kiến ​​trúc và sau đó sẽ phác thảo các cách để vượt qua phần kiến ​​trúc nhanh hơn.

Kiến trúc thực hiện hai điều cho mã của bạn:

1. Nó làm cho nó dễ dàng hơn để hiểu mã của bạn cho bạn và những người khác.
2. Nó giúp cấu trúc mã của bạn theo cách giúp mở rộng và tích hợp mã dễ dàng hơn.

Kiểu mã giúp đọc một phần cụ thể của mã dễ dàng hơn, bằng cách cung cấp cho bạn các quy ước mà bạn có thể nhận ra và sử dụng để điều hướng qua nó. Tương tự như vậy, một kiến ​​trúc tốt giúp bạn xác định nơi bạn thực sự sẽ tìm thấy mã xử lý một tính năng cụ thể. Ví dụ, trong hầu hết các dự án web, kiến ​​trúc liên quan chặt chẽ đến cách sắp xếp các thư mục và tệp. Trên flipside, một kiến ​​trúc tốt thực sự sẽ giúp bạn suy nghĩ ít hơn về mã, bởi vì nó nên có một vị trí trực quan nơi có bất kỳ đoạn mã nào.

Ngoài ra, một kiến ​​trúc tốt cung cấp một tốc ký để tránh nhiều cạm bẫy có thể khiến mã của bạn không được sử dụng dễ dàng. Một lần nữa, nếu bạn đưa ra quyết định kiến ​​trúc, nó sẽ thiết lập một quy ước giúp bạn suy nghĩ ít hơn về cách viết mã.

Bây giờ phần mà bạn thực sự ở đây cho:

Bạn có thể làm gì thông qua phần kiến ​​trúc nhanh hơn:

1. Đừng làm thế

Như nhiều câu trả lời đã chỉ ra. Trước tiên hãy tự hỏi nếu bạn thực sự cần kiến ​​trúc. Nếu bạn sẽ không có nhiều mã (và bạn có thể chắc chắn chắc chắn rằng dự án sẽ không phát triển trong tương lai gần), bạn có thể bỏ qua phần kiến ​​trúc và ghép lại một cái gì đó đơn giản hoạt động. TUY NHIÊN, nếu bạn sớm bắt đầu sự nghiệp, tôi sẽ sử dụng cơ hội để thực hành bất cứ khi nào bạn có thể. Tại một số điểm bạn sẽ thực hiện các dự án lớn hơn và tại thời điểm đó có lẽ sẽ muộn để học.

Ngoài ra, bạn có thể làm gì để kiến ​​trúc bớt đau đớn:

1. Làm sớm
2. Lấy trộm
3. Học / Bám sát nó
4. Đừng làm quá

Quyết định về kiến ​​trúc nên là một phần đầu của quá trình lập kế hoạch. Ngay khi bạn có ý tưởng về loại ứng dụng / chương trình / trang web nào bạn sẽ thực hiện, bạn nên suy nghĩ về loại kiến ​​trúc nào sẽ hỗ trợ điều này.

Tại thời điểm này là thời gian để ăn cắp một cách vô tư. Có rất nhiều tài liệu về cách thiết lập đúng kiến ​​trúc chương trình và một số lượng đáng kể các trường hợp sử dụng được bao phủ bởi các nguyên mẫu kiến ​​trúc hiện có này. Bạn nên tìm hiểu tổng quan sơ bộ về loại kiến ​​trúc nào tồn tại ngoài kia, ngay cả khi bạn không biết cách triển khai chúng.

Nếu bạn đã ổn định trên một loại kiến ​​trúc, sau đó gắn bó với nó. Đối với hầu hết các phần, quyết định kiến ​​trúc nên trực quan và chỉ mất vài giây sau khi thiết lập ban đầu. Rất nhiều điều này đi xuống để trải nghiệm.

Cuối cùng, đừng lật đổ công cụ. Bạn đưa ra ví dụ về thời tiết nên công khai hoặc riêng tư, và sự thật là, điều đó có thể không quan trọng nếu bạn công khai mọi thứ. Có, bạn không nên làm theo cách này và nhiều lỗi nhỏ sẽ xuất hiện sau một thời gian, nhưng vào cuối ngày, nó có thể sẽ không giết chết dự án của bạn. Đầu tiên và quan trọng nhất là tạo ra phần mềm làm việc!

(PS: Câu cuối cùng đó không phải là lý do cho việc lười biếng. Ưu tiên phần mềm làm việc không có nghĩa là bạn sẽ không phải học mã hóa tốt vào một ngày nào đó.)

Trả lời rất đơn giản,

• Tạo một nguyên mẫu (Thời gian đóng hộp)
• Refactor (dành nhiều thời gian như bạn muốn hoặc dựa trên nhiều yếu tố)

Khi bạn đang tạo nguyên mẫu, trọng tâm phải là Sản phẩm khả thi tối thiểu và khi bạn tái cấu trúc, nên tập trung vào việc làm cho dự án hoặc giải pháp của bạn có thể mở rộng.

Làm thế nào tôi có thể nhanh chóng vượt qua giai đoạn kiến ​​trúc và vào giai đoạn mã hóa và gỡ lỗi mà tôi thích?

Bằng cách giao nhiệm vụ này cho (hoặc yêu cầu trợ giúp từ) đồng nghiệp giàu kinh nghiệm hơn của bạn.

Bạn chỉ đơn giản là thiếu kinh nghiệm cần thiết để nhanh chóng đưa ra quyết định như vậy. Uni đã cho bạn một nền tảng lý thuyết tốt đẹp, nhưng nó chỉ đưa bạn đến vạch xuất phát. Không có cách nào khác để đánh giá một kiến ​​trúc nhất định trong một tình huống nhất định ngoài việc biết các kiến ​​trúc tương tự đã hành xử như thế nào trong các tình huống tương tự trong quá khứ.

Làm việc với những người giỏi công việc hơn bạn là cách nhanh nhất để học hỏi. Nếu bạn không có ai cao cấp để chuyển sang, bạn cần một công việc tốt hơn. "Tốt hơn" như trong "phù hợp với nhu cầu của bạn tốt hơn". Nhu cầu kiến ​​thức và kinh nghiệm là nhu cầu khủng khiếp nhất của bạn tại thời điểm này, như đã được chứng minh bằng tình huống khó xử của bạn. Bạn thích giai đoạn mã hóa và gỡ lỗi? Âm thanh như một đàn em hoàn hảo. Nhưng một thiếu niên cần sự hướng dẫn của cấp cao. Đó là điểm của những mô tả công việc. Người lạ trên internet chỉ có thể giúp bạn cho đến nay, bạn cần một người cố vấn.

Tôi thấy một số vấn đề nghiêm trọng với câu hỏi này. Hãy bắt đầu.

Làm thế nào để ngừng lãng phí thời gian thiết kế kiến ​​trúc

Câu hỏi này khá tải. Ngoài ra, bạn không thiết kế kiến trúc. Bạn kiến trúc sư . Kiến trúc và thiết kế là các hoạt động bổ sung và liên quan, nhưng không giống nhau, ngay cả khi chúng có thể trùng nhau.

Tương tự, theo cách tương tự, có thể lãng phí thời gian để thực hiện kiến ​​trúc (bằng cách kiến ​​trúc quá mức), bạn cũng có thể lãng phí thời gian để thiết kế quá mức và mã hóa quá mức (bằng cách mã hóa công cụ theo cách phức tạp hơn nhiều so với cần thiết hoặc do không thành công mã cho những thứ được yêu cầu.)

Kiến trúc phù hợp nhằm ngăn chặn sự lãng phí đó trong mã hóa. Nó làm như vậy bằng cách giới hạn, thu hẹp và ghi lại các cách có thể mà một hệ thống phức tạp sẽ được 1) thiết kế, 2) mã hóa và kiểm tra nó, 3) được giao, 4) duy trì, 5) phục hồi từ thất bại và 6) cuối cùng ngừng hoạt động.

Kinh nghiệm của tôi là những người chỉ thích mã hóa, họ chỉ viết mã mà không nghĩ đến việc hệ thống vận hành và duy trì lâu dài như thế nào, chuyển sang khoai tây nóng tiếp theo để lại một linh hồn tội nghiệp để duy trì một con golem xấu xí.

Nhưng tôi lạc đề...

Đây là điều: Đối với các hệ thống đủ đơn giản, kiến ​​trúc là hiển nhiên và xuất phát từ thực tiễn thiết kế và thực hiện âm thanh.

Nó chỉ dành cho các hệ thống lớn có số lượng người hoặc phần mềm cấp hệ thống khá lớn, những thứ rất phức tạp đòi hỏi kiến ​​trúc rõ ràng.

Gần đây tôi đã tốt nghiệp đại học và bắt đầu làm lập trình viên. Tôi không thấy khó giải quyết các vấn đề "kỹ thuật" hoặc gỡ lỗi, những điều mà tôi muốn nói có 1 giải pháp.

Đó là mức tối thiểu cần thiết cho nghề này và tôi rất vui vì bạn không gặp vấn đề gì khi làm chúng (tôi sẽ lo lắng nếu bạn làm vậy).

Nhưng dường như có một loại vấn đề không có một giải pháp

Đó là bánh mì và bơ trong nghề nghiệp của chúng tôi, loại vấn đề mà các nhà tuyển dụng sẵn sàng trả mức lương cao hơn (trung bình) của chúng tôi.

Như một vấn đề thực tế, các vấn đề đáng giải quyết là những vấn đề có thể có nhiều hơn một giải pháp. Vấn đề của thế giới thực, họ là như thế. Và thế giới đòi hỏi chuyên môn của chúng tôi, với tư cách là nhà phát triển phần mềm, phải đưa ra sự đánh đổi chấp nhận được.

- những thứ như kiến ​​trúc phần mềm.

Kiến trúc của sự vật là một đặc tính không thể tránh khỏi của hệ thống phức tạp, có thể là ảo / phần mềm hoặc trong thế giới cụ thể. Mỗi hệ thống hoạt động, có đầu vào và tạo đầu ra, nó sẽ phức tạp và sẽ có kiến ​​trúc.

Khi chúng tôi phát triển phần mềm cho các hệ thống như vậy (hệ thống ngân hàng, hệ thống giám sát quyền lực, hệ thống bán vé, v.v.), chúng tôi hướng đến việc sản xuất một phần mềm bắt chước các chức năng và yêu cầu của hệ thống đó.

Chúng tôi chỉ không thể đơn giản là cánh nó và mã nó theo phong cách cao bồi. Chúng tôi cần một số loại kiến ​​trúc. Điều này đặc biệt đúng nếu dự án cần hàng tá kỹ sư, nếu không muốn nói là nhiều hơn.

Những điều này làm tôi bối rối và khiến tôi đau khổ vô cùng.

Được thôi. Nó không phải là một chủ đề dễ dàng để học hoặc dạy, không phải không có nhiều thực hành.

Tôi dành hàng giờ để cố gắng quyết định làm thế nào để "kiến trúc sư" các chương trình và hệ thống của tôi. Ví dụ: tôi chia logic này thành 1 hoặc 2 lớp, làm cách nào để đặt tên cho các lớp, tôi nên đặt riêng tư hoặc công khai, v.v. Những loại câu hỏi này chiếm quá nhiều thời gian của tôi và nó làm tôi rất thất vọng. Tôi chỉ muốn tạo chương trình, kiến ​​trúc bị nguyền rủa.

Thật không may, đó không phải là kiến ​​trúc phần mềm.

Nó thậm chí không phải là thiết kế, mà chỉ là mã hóa. Tôi sẽ cung cấp một số gợi ý ở dưới cùng của bài viết này.

Làm thế nào tôi có thể nhanh chóng vượt qua giai đoạn kiến ​​trúc và vào giai đoạn mã hóa và gỡ lỗi mà tôi thích ?

Tôi đang gặp khó khăn trong việc tìm cách trả lời điều này, vì nó khá xúc động.

Chúng ta đang cố gắng để hoàn thành một công việc, hay chúng ta đang cố gắng chỉ để tận hưởng thực hành? Thật tuyệt vời khi cả hai là một và giống nhau, nhưng trong cuộc sống thực, nhiều lần họ không như vậy.

Thật tuyệt khi làm những việc chúng ta thích, nhưng trong một nghề phức tạp như của chúng ta, chỉ tập trung vào những gì chúng ta thích, điều đó không dẫn đến việc có một sự nghiệp hiệu quả.

Bạn sẽ không tiến bộ, bạn sẽ không trưởng thành hoặc tiếp thu kiến ​​thức mới.

Có câu nói này trong Quân đội, "hãy nắm lấy mút."

Những cụm từ khác có lời khuyên tương tự. "Nếu nó không hút, nó không đáng" và yêu thích của tôi, "Nếu nó hút (và nó rất quan trọng), hãy làm điều đó cho đến khi nó ngừng hút."

Khuyến nghị của tôi:

Dường như với tôi rằng bạn vẫn đang đấu tranh để hiểu sự khác biệt giữa

1. mã hóa (cách mã hóa các lớp, mô-đun của bạn hoặc những gì không, quy ước đặt tên, khả năng hiển thị truy cập, phạm vi, v.v.),

2. thiết kế (có bao nhiêu tầng, front-end / back-end / db, mỗi giao tiếp như thế nào, đi đâu) và các quyết định kiến ​​trúc ngầm xuất phát từ thiết kế các hệ thống đơn giản,

3. kiến trúc (như được tìm thấy trong các hệ thống phức tạp đòi hỏi hàng ngàn, nếu không nói là hàng trăm nghìn giờ.)

Vì vậy, tôi sẽ đề nghị bạn đi sâu vào chủ đề đầu tiên (mã hóa) để đưa nó lên cấp độ tiếp theo.

Mã sạch

" Mã sạch" của Robert "Chú Bob" Martin là một nơi tốt để bắt đầu.

Phần mềm kết dính

Ngoài ra, tôi khuyên bạn nên làm quen với một số liệu phần mềm hướng đối tượng cụ thể được gọi là LCOM hay đúng hơn là LCOM4.

Nó có thể trở nên toán học hơn và nó không phải là chống đạn, nhưng mục tiêu của bạn là hiểu và phát hiện theo kinh nghiệm (hoặc bóng mắt nếu bạn muốn) nếu một lớp được gắn kết hoặc nếu nó thiếu sự gắn kết.

http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4 https://www.computing.dcu.ie/~renaat/ca421/LCOM.html

Nguyên tắc phần mềm

Điều này liên quan chặt chẽ với "Nguyên tắc trách nhiệm duy nhất" hoặc SRY mà tất cả chúng ta nên làm quen. SRY là một trong 5 "RẮN" mà tất cả chúng ta cần phải làm quen nếu chúng ta trở nên thành thạo về mã hóa.

Khi chúng ta chuyển qua các nguyên tắc RẮN, chúng ta cũng cần làm quen với các nguyên tắc "GRASP" , điều chỉnh, hoặc hướng dẫn cách chúng ta viết mã các lớp.

Sách bổ sung

Cuối cùng, tôi cũng đề nghị như sau:

• "Tái cấu trúc" của Martin Fowler và Ken Beck sẽ là cuốn sách tiếp theo tôi đọc trong danh sách này.

• "Thiết kế theo hợp đồng, ví dụ" của Richard Mitchell, Jim McKim và Bertrand Meyer (sau này của danh tiếng của Eiffel.) Cuốn sách này không còn xuất bản, nhưng bạn có thể tìm thấy các bản sao được sử dụng giá rẻ ở Amazon.

Với điều này, bạn sẽ nắm bắt tốt cách bắt đầu mã hóa và thiết kế, và với thực tế, để di chuyển và làm chủ (hoặc ít nhất là nắm bắt) kiến ​​trúc phần mềm.

Tôi chắc chắn sẽ có những chuyên gia khác sẽ thêm, bớt hoặc phản đối những đề xuất này. Họ sẽ đưa ra các đề xuất khác, có thể được xác thực bằng kinh nghiệm của chính họ.

Tất cả những gì tôi có thể nói là thế này - không có phím tắt.

Tất cả tốt nhất.

Có rất nhiều thông tin ở đây và thẳng thắn TL; DR. Có một điều chính mà tôi nghĩ mọi người đã sai khi cố gắng học cách thiết kế một hệ thống: họ cố gắng nghĩ về nó theo thứ tự công việc sẽ được thực hiện. Thay vào đó, bạn cần phải làm việc ngược lại. Đó là, mục tiêu chính của thiết kế / kiến ​​trúc là xác định kết quả cuối cùng sẽ là gì.

Tương tự như vậy, hãy xem xét kiến ​​trúc của một ngôi nhà. Một kiến ​​trúc sư không bắt đầu tự hỏi mình những câu hỏi như: "ngôi nhà này nên có bao nhiêu cửa sổ?", "Gạch đầu tiên nên được đặt ở đâu?". Những chi tiết thực hiện không phải là thiết kế, chúng có nguồn gốc từ thiết kế. Các kiến ​​trúc bắt đầu với một tầm nhìn, có thể là một bản phác thảo về ngôi nhà đã hoàn thành có thể trông như thế nào. Đây có phải là nhà ở một gia đình, song lập? Đó là một ngôi nhà sang trọng hoặc dễ dàng phải chăng? Tương tự như vậy, cho dù các biến là riêng tư và việc bạn tách một lớp có rất ít liên quan đến kiến ​​trúc.

Bắt đầu trước tiên để tìm ra mục tiêu của thiết kế của bạn là gì. Ví dụ, đây có phải là giải pháp một lần không? Nó sẽ được mở rộng và sửa đổi và duy trì trong nhiều thập kỷ? Câu trả lời cho điều đó sẽ chỉ ra các thiết kế rất khác nhau và đó là điểm của kiến ​​trúc. Một khi bạn đã tìm ra những gì bạn cần làm, các chi tiết của thiết kế theo tự nhiên. Không phải những chi tiết này rõ ràng hay dễ dàng mà là kế hoạch cấp cao mà những lựa chọn này dựa trên.

Làm thế nào để đánh giá bạn nên dành bao nhiêu thời gian để kiến ​​trúc bất kỳ phần mềm nào trước khi có một vòng kiểm tra biên dịch viết của một loại nào đó khá đơn giản: đủ thông tin để phù hợp trong đầu bạn, và không hơn thế. Trừ khi dự án bạn đang làm việc bắt buộc một phương pháp chặt chẽ hơn. Trong trường hợp là người mới bắt đầu, rất có thể bạn nên đọc tài liệu kiến ​​trúc, không viết nó.

Đối với việc đặt tên, đối với tôi đó là một phần của "văn bản" nhưng chắc chắn đây là một phần rất quan trọng của lập trình: đừng ngần ngại suy nghĩ kỹ về cách bạn đặt tên cho mọi thứ và càng suy nghĩ phạm vi của tên càng lớn.

Tìm đúng tên, đúng kiến ​​trúc, mô đun đúng và trừu tượng đúng là một phần của kinh nghiệm mà bạn sẽ có được bằng cách mắc lỗi. Trong những năm qua, tôi đã viết một chương trình làm điều tương tự khoảng năm lần và mã mỗi lần rất khác nhau bởi vì mỗi lần lặp lại trước đây cho tôi gợi ý về một thiết kế tốt hơn.