Đối với những người có kinh nghiệm ít hơn năm năm trong việc phát triển web, có thể bạn vẫn đang tìm kiếm chỗ đứng của mình liên quan đến các tính năng ngôn ngữ, khuôn khổ, kiến trúc và các kiến thức thực hành tốt nhất. Và mặc dù bạn có thể bắt đầu mỗi trang với các ý định tốt nhất, cuối cùng, rất có thể là tất cả những gì bạn muốn là làm việc đủ để bạn được trả tiền.
Tôi đã dành vài năm để cứu một loạt các trang web của các thương hiệu nổi tiếng mà trên lý thuyết đáng nhẽ ra nên đơn giản, nhưng vì nhiều lý do khác nhau - sự thành công của các freelancers, thiếu giám sát từ trên xuống - đã biến thành "spaghetti" rối rắm- mối liên kết của sự thiếu kĩ thuật.
1. Thực hiện theo công thức
Điều tôi muốn tránh khỏi là đảm bảo với bạn rằng tất cả chúng tôi ở đó và không có gì sai khi không biết tất cả mọi thứ. Lập trình là một điều tuyệt vời và lý do bạn muốn làm điều đó mỗi ngày có lẽ là vì bạn phải vượt qua thách thức, đi đầu và đưa ra các giải pháp sáng tạo.
Nhưng đây là điều bắt buộc: điều gì làm cho việc lập trình vui vẻ (sáng tạo và suy nghĩ trên đôi chân của bạn) có thể vô tình đóng góp vào nợ kỹ thuật cho các dự án lớn hơn, do nhóm lãnh đạo.
Có những thực hành, nguyên tắc và mô hình tốt nhất đã được chứng minh trong những năm qua. Đó là công việc của bạn để nghiên cứu, học hỏi và thực hiện chúng - và, trong quá trình, hy sinh một chút cá tính của bạn để đáp lại sự duy trì và độ tin cậy. Có một bài đăng trên blog được gọi là 'Bạn không phải trả tiền để viết code' đã tổng kết nó khá tốt.
2. Chú ý tới những thứ nhỏ nhất
Lập trình là rất nhiều về sự rõ ràng, và khi bạn không thể nhìn thấy những chi tiết nhỏ trong một tổng thể, cơ hội của codebase của bạn sẽ sai một cách có chủ đích và có nghĩa là sẽ bị giảm giá trị nghiêm trọng. Như vậy, chiến lược chính của bạn để ở trên đầu trang của những thứ nên được một tập trung khó khăn về những điều cơ bản.
Hãy tổ chức chúng một cách thận trọng: lo lắng về các cấu trúc thư mục và các vị trí tập tin (frameworks có thể giúp ở đây), đảm bảo mô-đun có các yêu cầu API nhất quán, chức năng nhóm phổ biến và sử dụng các templates với các dấu phân cách.
Làm cho code của bạn có thể đọc được: sử dụng khoảng trắng một cách thận trọng và sử dụng chú thích để chú thích nhóm và làm rõ mục đích (nhưng không phải code xấu). Bạn đang làm việc như một nhóm và bạn được trả tiền để được rõ ràng.
Đừng cắt góc: tiết kiệm thời gian bây giờ có vẻ như là một ý tưởng tốt, nhưng bạn có thể chắc chắn rằng khi dự án phát triển, bất kỳ sự lười biếng sẽ bị tính vào chi phí dự án sau đó.
Trong quá trình này, hãy đảm bảo bạn sửa lỗi khi bạn làm song song. Sớm hay muộn các code khác sẽ kết thúc dựa vào những lỗi này. Ngừng các lỗi sai càng sớm càng tốt. Nếu bạn thực hiện thay đổi, hãy luôn cập nhật chúng. Các cột cơ sở dữ liệu, các chức năng phụ trợ, các cuộc gọi API, các hàm JavaScript, DocComments, các chú thích, các thuộc tính HTML, các tên lớp CSS, v.v ... - đảm bảo rằng tất cả chúng đang hoạt động hiệu quả.
3. Giữ vững cấu trúc
Có một sự cám dỗ khi xây dựng một trang web khép kín khi lặng lẽ bỏ qua một số khâu như vứt bỏ so sánh code với các tham chiếu toàn cầu đến ứng dụng hoặc để đạt được thông qua các thành phần với parent.parent.parent hoặc như vậy. Điều này nhanh chóng tạo ra sự cố kỹ thuật.
Nếu có thể, hãy nghĩ đến ứng dụng của bạn dưới dạng một loạt mô-đun độc lập và xây dựng dựa trên thực tiễn tốt nhất của khung công tác để loại bỏ sự liên kết chặt chẽ và phụ thuộc lẫn nhau. Nếu có thể, hãy thử tưởng tượng bạn sẽ sử dụng lại các phần của ứng dụng trong các dự án khác và nghĩ cách cấu trúc tệp, đánh dấu và code để tạo điều kiện thuận lợi cho việc này.
Bạn cần phải cảnh giác với việc chia sẻ trách nhiệm và tự hỏi mình: lỗi thuộc về điều gì ở đây? Nếu bạn cảm thấy code của mình kì lạ, có thể nó chính là nguyên nhân.
4. Cẩn thận với những yếu tố quá phức tạp
Vấn đề chính với sự phức tạp là nó che dấu và bóp méo sự cố ban đầu mà bạn đang cố gắng giải quyết và cuối cùng tạo ra nhiều code và phức tạp hơn, hoặc ở cùng một vị trí hoặc trong các phần khác của ứng dụng. Bạn kết thúc trong một chu kỳ luẩn quẩn.
Nếu code của bạn bắt đầu trông giống như bài học đại số hơn là API được duy trì tốt, bạn cần phải thực hiện một bước trở lại. Nó có thể là bạn cần refactor đoạn cụ thể của mã, refactor class của nó hoặc xem xét lại cách tiếp cận hiện tại của bạn cho vấn đề bạn đang cố gắng để giải quyết.
Trong những trường hợp cực đoan, bạn có thể cần phải nhìn lại bên ngoài. Gần đây tôi đã tái cấu trúc lại một thiết lập chế độ xem cực kỳ phức tạp mà tôi nhận ra là nạn nhân của một lược đồ định tuyến bị suy yếu. Bằng cách thiết kế lại các tuyến đường phức tạp thành một cái gì đó hợp lý, tôi đã có thể rãnh hàng trăm đường mã dày đặc trong các class khác nhau, và loại bỏ một số hacks / lỗi hacker trong quá trình này.
Một điều bạn không nên làm sau khi viết một số mã đặc biệt khó hiểu là ngồi lại và tự hào về cách khó đọc này! Các mã tốt nhất là dễ hiểu (khi mà việc đọc: không khó); nếu bạn không có điều này, bạn phải làm việc để thực hiện lại.
Tôi đã dành vài năm để cứu một loạt các trang web của các thương hiệu nổi tiếng mà trên lý thuyết đáng nhẽ ra nên đơn giản, nhưng vì nhiều lý do khác nhau - sự thành công của các freelancers, thiếu giám sát từ trên xuống - đã biến thành "spaghetti" rối rắm- mối liên kết của sự thiếu kĩ thuật.
1. Thực hiện theo công thức
Nhưng đây là điều bắt buộc: điều gì làm cho việc lập trình vui vẻ (sáng tạo và suy nghĩ trên đôi chân của bạn) có thể vô tình đóng góp vào nợ kỹ thuật cho các dự án lớn hơn, do nhóm lãnh đạo.
Có những thực hành, nguyên tắc và mô hình tốt nhất đã được chứng minh trong những năm qua. Đó là công việc của bạn để nghiên cứu, học hỏi và thực hiện chúng - và, trong quá trình, hy sinh một chút cá tính của bạn để đáp lại sự duy trì và độ tin cậy. Có một bài đăng trên blog được gọi là 'Bạn không phải trả tiền để viết code' đã tổng kết nó khá tốt.
2. Chú ý tới những thứ nhỏ nhất
Lập trình là rất nhiều về sự rõ ràng, và khi bạn không thể nhìn thấy những chi tiết nhỏ trong một tổng thể, cơ hội của codebase của bạn sẽ sai một cách có chủ đích và có nghĩa là sẽ bị giảm giá trị nghiêm trọng. Như vậy, chiến lược chính của bạn để ở trên đầu trang của những thứ nên được một tập trung khó khăn về những điều cơ bản.
Hãy tổ chức chúng một cách thận trọng: lo lắng về các cấu trúc thư mục và các vị trí tập tin (frameworks có thể giúp ở đây), đảm bảo mô-đun có các yêu cầu API nhất quán, chức năng nhóm phổ biến và sử dụng các templates với các dấu phân cách.
Làm cho code của bạn có thể đọc được: sử dụng khoảng trắng một cách thận trọng và sử dụng chú thích để chú thích nhóm và làm rõ mục đích (nhưng không phải code xấu). Bạn đang làm việc như một nhóm và bạn được trả tiền để được rõ ràng.
Đừng cắt góc: tiết kiệm thời gian bây giờ có vẻ như là một ý tưởng tốt, nhưng bạn có thể chắc chắn rằng khi dự án phát triển, bất kỳ sự lười biếng sẽ bị tính vào chi phí dự án sau đó.
Trong quá trình này, hãy đảm bảo bạn sửa lỗi khi bạn làm song song. Sớm hay muộn các code khác sẽ kết thúc dựa vào những lỗi này. Ngừng các lỗi sai càng sớm càng tốt. Nếu bạn thực hiện thay đổi, hãy luôn cập nhật chúng. Các cột cơ sở dữ liệu, các chức năng phụ trợ, các cuộc gọi API, các hàm JavaScript, DocComments, các chú thích, các thuộc tính HTML, các tên lớp CSS, v.v ... - đảm bảo rằng tất cả chúng đang hoạt động hiệu quả.
3. Giữ vững cấu trúc
Nếu có thể, hãy nghĩ đến ứng dụng của bạn dưới dạng một loạt mô-đun độc lập và xây dựng dựa trên thực tiễn tốt nhất của khung công tác để loại bỏ sự liên kết chặt chẽ và phụ thuộc lẫn nhau. Nếu có thể, hãy thử tưởng tượng bạn sẽ sử dụng lại các phần của ứng dụng trong các dự án khác và nghĩ cách cấu trúc tệp, đánh dấu và code để tạo điều kiện thuận lợi cho việc này.
Bạn cần phải cảnh giác với việc chia sẻ trách nhiệm và tự hỏi mình: lỗi thuộc về điều gì ở đây? Nếu bạn cảm thấy code của mình kì lạ, có thể nó chính là nguyên nhân.
4. Cẩn thận với những yếu tố quá phức tạp
Nếu code của bạn bắt đầu trông giống như bài học đại số hơn là API được duy trì tốt, bạn cần phải thực hiện một bước trở lại. Nó có thể là bạn cần refactor đoạn cụ thể của mã, refactor class của nó hoặc xem xét lại cách tiếp cận hiện tại của bạn cho vấn đề bạn đang cố gắng để giải quyết.
Trong những trường hợp cực đoan, bạn có thể cần phải nhìn lại bên ngoài. Gần đây tôi đã tái cấu trúc lại một thiết lập chế độ xem cực kỳ phức tạp mà tôi nhận ra là nạn nhân của một lược đồ định tuyến bị suy yếu. Bằng cách thiết kế lại các tuyến đường phức tạp thành một cái gì đó hợp lý, tôi đã có thể rãnh hàng trăm đường mã dày đặc trong các class khác nhau, và loại bỏ một số hacks / lỗi hacker trong quá trình này.
Một điều bạn không nên làm sau khi viết một số mã đặc biệt khó hiểu là ngồi lại và tự hào về cách khó đọc này! Các mã tốt nhất là dễ hiểu (khi mà việc đọc: không khó); nếu bạn không có điều này, bạn phải làm việc để thực hiện lại.
