Sợ ứng dụng web không phải là ứng dụng trong tương lai

Tôi là nhà phát triển web của một ứng dụng web SaaS nhỏ, cục bộ. Nó hiện có khoảng một nửa tá khách hàng.

Khi tôi tiếp tục thiết kế ứng dụng, tôi càng ngày càng khó thuyết phục bản thân cam kết bất cứ lúc nào cho dự án, điều đã xảy ra trong giai đoạn đầu. Đã gắn bó với dự án và mã tôi đã viết, tôi sợ rằng tất cả các công việc bổ sung mà tôi cam kết sẽ bị đảo ngược trong tương lai gần, khi ứng dụng hóa ra không mở rộng tốt khi doanh nghiệp phát triển.

Là một sinh viên đại học nộp đơn xin thực tập, tôi đã có nhà tuyển dụng đặt câu hỏi về sự lựa chọn của tôi trong việc không sử dụng bất kỳ khuôn khổ web nào trong các cuộc phỏng vấn, điều này chỉ khiến tôi nghi ngờ thêm về công việc trước đây của mình. Tôi chỉ đơn giản là không biết bất kỳ khung web nào và không biết nên bắt đầu sử dụng cái nào.

Tôi đã có một kỳ thực tập với tư cách là một nhà phát triển toàn tập vào tháng 1, nơi tôi sẽ bắt đầu tìm hiểu các khung công tác mặt trước, nhưng áp lực để hoàn thành ứng dụng đang tăng lên và tôi đang xem xét loại bỏ hoàn toàn ứng dụng và bắt đầu lại, đó là điều tôi đã làm trước đây Ứng dụng hiện được xây dựng bằng PHP và jQuery (cho các cuộc gọi AJAX) và sử dụng MySQL cho cơ sở dữ liệu của nó. Bạn có suy nghĩ gì về cách tôi có thể vượt qua khối tinh thần này và để đảm bảo ứng dụng của tôi sẽ có thể mở rộng? Cảm ơn trước.

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

Hoặc đặt một cách khác, đừng lo lắng về nó ngày hôm nay. Nếu ứng dụng của bạn làm những gì nó cần làm, thì nó vẫn ổn. Nó không phải là một điều xấu để viết lại các phần của phần mềm xuống dòng; vào thời điểm đó, bạn 1) biết rõ hơn những gì bạn đang cố gắng xây dựng và 2) biết những bit nào thực sự là nút cổ chai. Bạn có thể dành một lượng thời gian khổng lồ để viết một ứng dụng có thể mở rộng tới một triệu người dùng, nhưng nó sẽ không tốt hơn cho sáu khách hàng hiện tại của bạn so với những gì bạn có ngày hôm nay .

Bạn có suy nghĩ gì về cách tôi có thể vượt qua khối tinh thần này và để đảm bảo ứng dụng của tôi sẽ có thể mở rộng?

Mấu chốt của vấn đề không phải là khả năng mở rộng. Mấu chốt của vấn đề là nghĩ rằng bạn sẽ hiểu đúng ngay từ lần đầu tiên .

Bạn nên tập trung vào viết mã sạch. Bởi vì mã sạch tối đa hóa sự thuận tiện khi bạn (chắc chắn) phải thay đổi một cái gì đó trong tương lai. Và đó là mục tiêu thực sự bạn nên có.

Những gì bạn đang cố gắng làm bây giờ là cố gắng nghĩ về mã hoàn hảo để viết. Nhưng ngay cả khi bạn quản lý để làm điều đó, ai nói rằng các yêu cầu sẽ không thay đổi, hoặc bạn có thể đưa ra quyết định của mình dựa trên thông tin sai hoặc thông tin sai lệch?

Bạn không thể tránh phạm sai lầm, ngay cả khi chúng không phải là lỗi của bạn. Tập trung vào viết mã để dễ dàng thay đổi mọi thứ sau này, thay vì hy vọng viết mã mà bạn sẽ không cần thay đổi trong tương lai.

Đã gắn bó với dự án và mã tôi đã viết,

Tôi hoàn toàn thông cảm với tình cảm này. Nhưng việc gắn liền với mã bạn đã viết là một vấn đề.

Điều duy nhất nên là một hằng số là mong muốn của bạn để giải quyết một vấn đề cụ thể . Làm thế nào bạn đi về giải quyết vấn đề đó chỉ là mối quan tâm thứ yếu.

Nếu ngày mai một công cụ mới được phát hành làm giảm 80% cơ sở mã của bạn, bạn sẽ khó chịu vì mã của bạn không còn được sử dụng nữa; hoặc bạn sẽ vui mừng vì cơ sở mã của bạn đã trở nên nhỏ hơn và sạch hơn / dễ quản lý hơn?

Nếu trước đây, bạn có một vấn đề: bạn không thấy giải pháp cho mã . Nói cách khác, bạn đang tập trung vào mã và không nhìn thấy bức tranh lớn hơn (giải pháp mà nó nhắm đến để cung cấp).

Tôi sợ rằng tất cả các công việc bổ sung mà tôi cam kết sẽ bị hủy bỏ trong tương lai gần, khi ứng dụng hóa ra không có quy mô tốt khi doanh nghiệp phát triển.

Đó là một vấn đề khác nhau cho một ngày khác nhau.

Đầu tiên, bạn xây dựng một cái gì đó hoạt động. Thứ hai , bạn cải thiện mã để sửa bất kỳ lỗi nào mà nó vẫn có thể hiển thị. Những gì bạn đang làm là giữ lại nhiệm vụ đầu tiên vì sợ phải thực hiện nhiệm vụ thứ hai.

Nhưng còn lựa chọn nào khác không? Bạn không thể nói cho tương lai . Nếu bạn dành thời gian để suy nghĩ về các khả năng trong tương lai, cuối cùng bạn cũng sẽ đoán được . Một dự đoán luôn luôn dễ bị sai.

Thay vào đó, xây dựng ứng dụng và chứng minh rằng thực sự có vấn đề. Và một khi vấn đề đã rõ ràng, thì bạn bắt đầu giải quyết nó.

Nói một cách khác: Henry Ford không bao giờ chế tạo một chiếc xe phù hợp với tiêu chuẩn / kỳ vọng 2018. Nhưng nếu anh ta không chế tạo Model T, một chiếc xe không hoàn hảo theo tiêu chuẩn hiện đại, sẽ không có ai bắt đầu sử dụng ô tô, sẽ không có ngành công nghiệp xe hơi và không ai có thể có một chiếc xe mà sau đó họ có thể cố gắng cải tiến.

Tôi đã có nhà tuyển dụng đặt câu hỏi về sự lựa chọn của tôi trong việc không sử dụng bất kỳ khung web nào trong các cuộc phỏng vấn, điều này chỉ khiến tôi nghi ngờ thêm về công việc trước đây của mình.

Phần quan trọng ở đây không phải là khung mà bạn đang sử dụng (bất kỳ nhà tuyển dụng nào đánh giá bạn về điều đó không làm việc của họ đúng cách). Phần quan trọng ở đây là biết bạn đang làm gì và tại sao bạn lại làm việc đó .

Ví dụ, bạn có thể tránh khuôn khổ hiện tại một cách cụ thể vì bạn muốn tìm hiểu lý do tại sao một khung công tác hữu ích bằng cách thực hiện nó một cách khó khăn trước tiên. Hoặc bạn có thể đang cố gắng tạo ra khuôn khổ của riêng bạn.

Câu trả lời tồi duy nhất ở đây là "Tôi không biết", vì nó cho thấy sự thiếu quyết định sáng suốt. Đó là một lá cờ đỏ cho một chủ nhân.

Tôi chỉ đơn giản là không biết bất kỳ khung web nào và không biết nên bắt đầu sử dụng cái nào.

Vấn đề tương tự phát sinh ở đây. Giải pháp không phải là suy nghĩ nhiều hơn mà là hành động:

• Ngừng suy ngẫm câu trả lời hoàn hảo .
• Chọn một khung. Trừ khi bạn có một sở thích, chọn một cái ngẫu nhiên. Sử dụng phi tiêu, lăn một con súc sắc, lật một đồng xu, chọn một thẻ.
• Sử dụng nó.
• Bạn có thích sử dụng nó? Có điều gì bạn thấy khó chịu không?
• Tra cứu làm thế nào để ngăn chặn những yếu tố xấu này. Bạn đã sử dụng sai khung công tác, hay đây chỉ là cách khung hoạt động?
• Một khi bạn cảm thấy bạn nắm được khung (bất kể bạn có thích hay không), hãy chọn một khung mới và lặp lại chu trình.

Để đọc thêm về điều này, hãy đọc Tư duy làm> tư duy suy nghĩ . Tác giả giải thích nó tốt hơn tôi có thể.

nhưng áp lực để hoàn thành ứng dụng đang tăng lên và tôi đang xem xét loại bỏ hoàn toàn ứng dụng và bắt đầu lại

Trừ khi codebase hiện tại là một mớ hỗn độn hoàn toàn không thể nhầm lẫn; bạn đang đưa ra quyết định ngược lại.
Các nhà phát triển thường nghĩ rằng vứt bỏ mọi thứ sẽ là lựa chọn tốt hơn. Đó là một cảm giác rất phổ biến. Nhưng nó hiếm khi là lựa chọn đúng đắn.

Ném mã ra và bắt đầu lại từ đầu giống như bị kẹt xe trên đường đi làm, lo lắng bạn sẽ đi làm muộn (lỡ thời hạn), và thay vào đó hãy lái xe về nhà và thử lái xe xuống cùng một con đường. Nó không có ý nghĩa. Bạn có thể bị kẹt xe, nhưng bạn vẫn làm việc gần hơn so với khi bạn ở nhà.

Mặc dù số tiền khổng lồ mà Facebook và Google đã đổ vào tiếp thị để thuyết phục bạn bằng cách khác, các khung giao diện người dùng tồn tại vì hai lý do chính:

• Đầu tiên, giảm tải phần cứng / mạng cho các hoạt động phía máy khách bằng cách đặt trạng thái và logic trong máy khách
• Thứ hai, phù hợp với logic máy khách bổ sung cần thiết để hỗ trợ điểm đầu tiên, chúng cung cấp các bối cảnh thực thi riêng biệt để bạn có thể nhồi nhét mã của người khác vào một trang mà không phá vỡ bất cứ điều gì.

Bạn có thể chỉ cần tiếp cận một khung để giải quyết các vấn đề này nếu ứng dụng của bạn vốn đã ở trạng thái, nếu số lượng trạng thái ứng dụng bạn đang lưu phía máy khách khá phức tạp, nếu bạn mong đợi rất nhiều máy khách có độ trễ mạng kém (di động, hoặc cách xa máy chủ) hoặc nếu có nhu cầu kinh doanh mạnh mẽ để hỗ trợ CSS hoặc tạo phần tử động đặc biệt tiên tiến.

Tiếp thị khung muốn bạn tin rằng phương pháp kiến ​​trúc đặc biệt của họ làm tăng tốc độ phát triển và giúp bảo trì dễ dàng hơn. Điều này là không đúng sự thật cho các nhóm nhỏ làm việc trên các dự án đơn giản. Mã cô lập và tổ chức nhập khẩu có thể giúp một nhóm lớn đưa sản phẩm ra thị trường nhanh hơn. Nó cung cấp ít hơn nhiều cho một nhóm phát triển một người làm việc trong một dự án đã có chức năng.

Bạn sẽ dành nhiều thời gian hơn để tìm hiểu làm thế nào để phù hợp với mã chức năng hiện có vào khung so với thực tế bạn sẽ triển khai các tính năng và rất có thể ai đó sẽ cập nhật một cái gì đó và mã được viết trong khung đó sẽ ngừng hoạt động trong vòng 18 tháng trừ khi có người ở đó để liên tục duy trì nó

Vanilla JS, và ở mức độ thấp hơn nhưng vẫn còn đáng kể JQuery, không gặp phải những vấn đề đó. Với một số trường hợp ngoại lệ đáng chú ý, các ứng dụng JQuery + AJAX không phụ thuộc vào các hành vi cụ thể của trình duyệt và từ bỏ các phụ thuộc bên ngoài nơi hợp lý, tiếp tục hoạt động 10 - 15 năm sau khi chúng được viết với những thay đổi rất nhỏ.

Các khung rất tốt cho các phần khởi động điển hình hỗ trợ các ứng dụng web liên tục, phức tạp, phải đối mặt công khai. Họ để các nhóm lớn phối hợp tốt với nhau, tích hợp độc đáo với các khung thêm của nhà cung cấp và hỗ trợ các vật dụng mới và mô hình thiết kế hào nhoáng để giúp bạn cạnh tranh.

Không có vấn đề nào đối với một công cụ phần mềm nhỏ với đối tượng cố định mà bạn sắp từ bỏ. Tham gia vào một khuôn khổ làm chậm tốc độ phát triển của bạn khi bạn thích nghi với mô hình mới và đưa ra các rủi ro tương thích không cần thiết. Giữ mã phía máy khách đơn giản, (và lý tưởng là tự lưu trữ) có nghĩa là diện tích bề mặt của rủi ro tương thích giảm đáng kể. Các trình duyệt sẽ thay đổi, các url CDN sẽ ngừng hoạt động, các phụ thuộc sẽ hết hạn - Nhưng không ai chạm vào máy chủ đó và nó sẽ tiếp tục hoạt động tốt.

Đừng áp dụng một khung trừ khi nó giải quyết được một vấn đề kiến ​​trúc cụ thể mà bạn có ngày hôm nay hoặc có thể thấy trước, và mạnh mẽ xem xét giải quyết mối quan tâm đó bằng một cách khác thay vào đó nếu điều đó hoàn toàn có thể thực hiện được.

Điều tốt nhất bạn có thể làm để "chứng minh trong tương lai" ứng dụng của mình là tuân theo các thực tiễn tốt nhất trong thiết kế hệ thống của bạn để tối đa hóa việc ghép lỏng lẻo và tách các mối quan tâm. Không có phần nào trong ứng dụng của bạn an toàn khỏi bị lỗi thời, nhưng bạn có thể làm rất nhiều việc để cách ly mã trở nên lỗi thời vì lý do X khỏi mã không nhất thiết phải bị ảnh hưởng bởi X.

Tuy nhiên, tôi cho rằng mối quan tâm của bạn sẽ ít hơn đối với sự tăng trưởng / khả năng mở rộng của ứng dụng so với tốc độ tăng trưởng của kinh nghiệm và khả năng của chính bạn. Khối tinh thần mà bạn mô tả âm thanh với tôi như học tập trì trệ hoặc nhận thức về nhiều điều chưa biết mà không có chiến lược hoặc công cụ để giải quyết chúng.

Các khung không đặc biệt phù hợp để giải quyết thách thức "chứng minh tương lai", mặc dù chúng có thể cung cấp hướng dẫn ban đầu có liên quan cho người thiếu kinh nghiệm, thường thông qua các mẫu thiết kế cấp cao như MVC. Thay vào đó, chúng có xu hướng hữu ích hơn như là cách để tăng tốc phát triển bằng cách cung cấp sự gắn kết mạnh mẽ và thường phải trả giá bằng việc ghép nối chặt chẽ hơn. Ví dụ: giả sử bạn sử dụng một số hệ thống ánh xạ quan hệ đối tượng do khung cung cấp trong toàn bộ ứng dụng để tương tác với cơ sở dữ liệu của bạn, hoàn thành với tích hợp hệ thống lưu trữ. Có thể sau này bạn cần chuyển sang kho dữ liệu không liên quan và bây giờ mọi thứ sử dụng nó đều bị ảnh hưởng.

Sự lộn xộn mà bạn bây giờ không đến từ những gì bạn đã sử dụng, mà là nơi bạn đã sử dụng nó (có thể là khá nhiều ở mọi nơi trên back-end). Sẽ tốt hơn bao nhiêu nếu mã hiển thị một trang không bao giờ lấy dữ liệu mà nó hiển thị.

Giả sử bạn muốn thêm một số tiện ích nhỏ vào một trang yêu cầu thêm các tập lệnh và tài nguyên để hoạt động đúng. Nếu bạn đang sử dụng một khung công tác, bạn có thể hỏi "Làm thế nào nó muốn tôi thêm các phụ thuộc vào một trang cho điều này?" Nếu bạn không phải, thì câu hỏi sẽ có kết thúc cởi mở hơn: "Tôi đang chạm vào mối quan tâm kỹ thuật nào để tách biệt?" Câu hỏi đó cần nhiều kinh nghiệm hơn để trả lời, nhưng đây là một số gợi ý:

• Điều gì sẽ xảy ra nếu ngày mai bạn chuyển tất cả tài nguyên tĩnh (tập lệnh, hình ảnh, v.v.) sang một máy chủ riêng, mạng phân phối nội dung, v.v. hoặc bắt đầu cố gắng đóng gói tất cả chúng lại với nhau để cải thiện hiệu suất?
• Điều gì sẽ xảy ra nếu bạn bắt đầu đặt tiện ích này trên các trang khác nhau hoặc nhiều phiên bản của tiện ích này trên cùng một trang?
• Làm thế nào bạn có thể bắt đầu thực hiện kiểm tra AB trên các phiên bản khác nhau của tiện ích?

Nếu bất kỳ điều nào trong số này nghe có vẻ quá sức, thì tôi khuyên bạn nên sử dụng một khung công tác ngay bây giờ, không phải vì lợi ích của ứng dụng mà là vì sự phát triển cá nhân của chính bạn. Đừng nhất thiết phải bắt đầu lại. Thay vào đó, hãy sử dụng các khung làm chương trình giảng dạy để giúp hướng dẫn sự phát triển của ứng dụng của bạn.

Chỉ có hai cách để học. Một là do thử và sai, và thứ hai là bằng cách học hỏi kinh nghiệm của người khác. Thử nghiệm và lỗi không thể được loại bỏ. Phát triển phần mềm về bản chất là một lĩnh vực học tập liên tục và bất kỳ mã nào không làm điều gì mới hoặc khác biệt là theo định nghĩa không cần thiết. (Thay vào đó hãy sử dụng mã đã được viết.)

Bí quyết là giảm thiểu nó bằng cách chủ động tìm kiếm kiến ​​thức đã có sẵn (chiến lược, thực tiễn tốt nhất và mã / thư viện / khung) trong mỗi bước của quy trình phát triển để bạn không thấy mình liên tục phát minh lại bánh xe.

Tuy nhiên, đối với ứng dụng bạn đang viết, mối quan tâm đầu tiên của bạn chỉ đơn giản là hoàn thành nó với nỗ lực trần tục tối thiểu (giống như mùi mã, nhưng đối với quá trình phát triển). Với bản chất học tập của con người, cách nhanh nhất để đạt được chất lượng cao là bắt đầu với một cái gì đó . Dễ hiểu hơn về mục tiêu khi bạn có thể định hình nó bằng cách phê bình một cái gì đó bạn đã có.

Nếu bạn có thể chấp nhận rằng phần lớn mã bạn viết là một quá trình học tập dùng một lần và cần thiết để tìm ra các thiết kế tốt, điều đó sẽ giúp thúc đẩy bạn tiếp tục duy trì nó. Xét cho cùng, đó là thách thức của việc giải quyết vấn đề khiến cho việc phát triển phần mềm trở nên hấp dẫn và thách thức đó luôn luôn hiện hữu nếu những gì bạn đang làm là đáng giá (xem tuyên bố "học hỏi liên tục" ở trên).

Trên hết, "tháo dỡ điều và bắt đầu lại" là không bao giờ là một lựa chọn ... sau khi tất cả, anh không nói rằng bạn có "một nửa tá khách hàng?" Bạn đã tạm dừng để xem xét những gì họ có thể nghĩ về tuyên bố của bạn, cho rằng họ đang ở ngay bây giờ (có lẽ) "hoàn toàn hài lòng với công việc của bạn?!"

Đây là một tương tự mà tôi muốn sử dụng:

• "Công việc của tôi là xây dựng nhà cho mọi người sống, cho mọi người xây dựng doanh nghiệp, v.v." Công việc của tôi là làm cho "những mảnh cát nhỏ xíu, quá vinh quang " đó thực hiện công việc hữu ích. (Cũng giống như những người xây dựng nhà làm thủ công nhà từ tấm thạch cao, gạch men, khối bê tông và 2x4.)

• Tuy nhiên, trong khi "cái đinh" mà những người làm nhà sử dụng thực sự không thay đổi nhiều trong hai trăm năm (ngoại trừ chuyển từ "hình vuông" sang "tròn", và sau đó trở nên hữu ích với máy đóng đinh bằng khí nén), công nghệ mà chúng ta sử dụng luôn thay đổi và đôi khi trải qua những thay đổi rất sâu sắc. ("Vậy là xong.")

• "Tuy nhiên, mỗi ngôi nhà, một khi được xây dựng, sẽ mãi mãi-sau khi được sống trong". Bạn không thể đuổi họ. Khi bạn xây dựng nó và bàn giao chìa khóa, "nó không còn là" ngôi nhà của bạn nữa ". Đó là những gì nó đúng - bây giờ là, và nó sẽ tồn tại trong một thời gian rất dài.

Một phần lớn công việc kinh doanh của tôi ngày nay là giúp khách hàng đối phó với phần mềm được xây dựng từ mười, hai mươi, ba mươi năm trở lên, sử dụng các công nghệ "hiện đại" tồn tại trong những ngày đó - (và, ahem, Tôi nhớ) - và hiện vẫn đang phục vụ (!).

Đảm bảo một cái gì đó là bằng chứng trong tương lai là gần như không thể. Kiểm tra ứng dụng đó có thể mở rộng không quá khó. Bạn chỉ cần viết một số bài kiểm tra hiệu suất cho ứng dụng và xem có bao nhiêu ứng dụng khách có thể xử lý. Kiểm tra viết chắc chắn sẽ làm cho ứng dụng của bạn có thêm bằng chứng trong tương lai vì bạn sẽ có thể đánh giá cách ứng dụng hoạt động sau khi bạn thực hiện nhiều thay đổi hơn trong ứng dụng.

wrt framework, tôi sẽ không quá lo lắng về hiệu suất / khả năng mở rộng. Đây là một cái gì đó bạn có thể dễ dàng kiểm tra và rất có thể sửa chữa. Vấn đề lớn hơn là bảo mật. Các khung web thường giúp bạn viết mã xác thực, cookie, bảo vệ CSRF, v.v. Đặc biệt là do bạn thiếu kinh nghiệm, tập trung tốt hơn trong lĩnh vực đó.

Tôi bắt đầu viết một bình luận về các khung học tập, nhưng cuối cùng nó đã biến thành một thứ gì đó trông giống như một câu trả lời hơn, vì vậy đây là.

Không biết bất kỳ khuôn khổ nào có vẻ như là một vấn đề. Về cơ bản bất kỳ công việc webdev nào bạn sẽ cần phải làm việc với một số khung công tác. Học một khuôn khổ khác sau khi bạn biết nó không phải là vấn đề lớn, nhưng học cái đầu tiên có thể mất một thời gian - đó là lý do tại sao các nhà tuyển dụng có thể quan tâm đến điều đó. Tránh các khuôn khổ có thể chỉ ra không được phát minh ở đây hội chứng , đó là cách tiếp cận không thực tế rộng rãi.

Vì điểm chính của việc biết các khuôn khổ đầu tiên của bạn là học một ngôn ngữ chung, có lẽ chỉ cần thử học một cái gì đó phổ biến giữa các đồng nghiệp của bạn. Bạn có thể thử sửa đổi một số dự án đơn giản được viết trong một khung. Bắt đầu một dự án từ đầu trong một khuôn khổ mà bạn không biết là một cách học rất không hiệu quả.

Bây giờ, câu hỏi thực tế của bạn là về một dự án cụ thể và chuyển nó vào một khung. Vì thế, câu trả lời dường như là: nó phụ thuộc và chúng tôi thực sự không thể nói với bạn. Tuy nhiên, chuyển nội dung vào một khung mà bạn không biết gần như chắc chắn là một ý tưởng tồi, vì bạn thậm chí không thể biết liệu nó có hợp lý hay không . Do đó, có vẻ như bạn nên để nguyên trạng đó và xem xét lại quyết định này vào một lúc nào đó, một khi bạn biết và thích một số khuôn khổ. Các câu trả lời khác chứa những điểm tốt về những gì bạn nên tìm kiếm khi đưa ra quyết định như vậy.

Bài viết này đã nhận được rất nhiều sự chú ý trên Hacker News 2,5 năm trước: Viết mã dễ xóa, không dễ gia hạn. Viễn cảnh này có thể hoặc không thể giúp bạn đối phó với cơ sở mã hiện tại của bạn, nhưng trong tương lai, nó có thể giúp ngăn chặn sự thất vọng xuất phát từ chủ nghĩa cầu toàn / kỹ thuật quá mức.

Nếu chúng ta thấy 'dòng mã' là 'dòng chi tiêu', thì khi chúng ta xóa các dòng mã, chúng ta sẽ giảm chi phí bảo trì. Thay vì xây dựng phần mềm có thể sử dụng lại, chúng ta nên cố gắng xây dựng phần mềm dùng một lần.

Tôi không cần nói với bạn rằng xóa mã sẽ vui hơn viết mã.

(nhấn mạnh của tôi)

Các chủ đề bài viết về Hacker Tin tức cũng có thể là đáng đọc.

Theo như nó là bằng chứng trong tương lai và áp dụng các nguyên tắc quy mô & khung, đó là một nhiệm vụ cao để tự mình đảm nhận, có lẽ tôi không lo lắng về điều đó, nhưng nếu bạn phải:

Giữ mã của bạn sạch sẽ, tuân theo các nguyên tắc RẮN, KHÔ> google.

Áp dụng một bộ cân bằng tải càng sớm càng tốt.

Đứng lên ít nhất hai máy chủ web, xử lý các tình huống cân bằng tải trong mã.

Và cuối cùng nhưng không kém phần quan trọng, có các ngăn xếp tốt hơn để xử lý một triệu người dùng so với LAMP, nhưng tôi chắc chắn rằng điều đó hoàn toàn có thể thực hiện được.

Trường hợp và điểm, xem: https://stackoverflow.com/questions/1276/how-big-can-a-mysql-database-get-b Before-performance-starts-to-degrade Điểm này hợp lệ, nhưng 10gb là tầm thường như một môn học thử nghiệm.