12/08/2018, 17:27

Những lỗi mà tôi đã làm như một Beginner Programmer

Trước tiên tôi muốn làm rõ ràng một điều. Nếu bạn là một beginner programmer, bài viết này không phải làm cho bạn cảm thấy tồi tệ về những sai lầm mà bạn mắc phải, mà là để bạn, cũng như tôi nhận thức về nó, nhắc nhở chúng ta nên tránh. Tôi đã mắc phải những lỗi này và học được nhiều thứ từ mỗi ...

Trước tiên tôi muốn làm rõ ràng một điều. Nếu bạn là một beginner programmer, bài viết này không phải làm cho bạn cảm thấy tồi tệ về những sai lầm mà bạn mắc phải, mà là để bạn, cũng như tôi nhận thức về nó, nhắc nhở chúng ta nên tránh. Tôi đã mắc phải những lỗi này và học được nhiều thứ từ mỗi lỗi đó. Tôi rất vui khi có những thói quen coding giúp tôi tránh được những lỗi đã gặp, và tôi nghĩ bạn cũng nên tránh. Sau đây là những lỗi đó, tuy nhiên nó không được trình bày theo một thứ tự nào.

1. Viết code không có kế hoạch (without planning)

Nói chung, một nội dung có chất lượng cao không dễ dàng được tạo ra. Nó yêu cầu phải suy nghĩ và nghiên cứu thật cẩn thận. Một programs chất lượng cao cũng không ngoại lệ. Viết programs có chất lượng là một process theo quy trình: Suy nghĩ. Nghiên cứu. Kế hoạch. Viết. Validate. Modify. Thật không may, không có từ để viết tắt cho tiến trình này. Bạn cần phải có một thói quen để luôn đi qua đúng số lượng của những hoạt động này. Một trong những lỗi lớn nhất mà tôi đã gặp đó là bắt đầu viết code mà bỏ qua quá nhiều suy nghĩ và nghiên cứu. Trong khi điều này có thể hoạt động tốt với một phần nhỏ, độc lập, nhưng nó có thể lại ảnh hưởng xấu đến ứng dụng trong trường hợp lớn hơn. Điều đó giống như bạn cần suy nghĩ trước khi nói bất cứ điều gì mà bạn có thể hối hận, bạn cần suy nghĩ trước khi code bất cứ điều gì làm bạn có thể hối hận. Coding cũng là một cách để chúng ta truyền đạt suy nghĩ của bản thân.

When angry, count to 10 before you speak. If very angry, a hundred. — Thomas Jefferson.

Và cũng hãy làm tương tự như khi bạn review code nhé.

Programming chủ yếu là đọc về đoạn code trước đó, nghiên cứu xem những gì cần, và làm thế nào để nó phù hợp với hệ thống hiện tại, và lên kế hoạch viết các tính năng nhỏ, có thể test được. Thực sự thì việc viết dòng code chỉ chiểm khoảng 10% trong toàn bộ quá trình. Đừng nghĩ rằng programming nghĩa là chỉ viết và viết code. Programming là tạo nên những thứ hữu ích từ những logic cơ bản.

2. Lập kế hoạch quá nhiều trước khi bắt đầu viết code

Đúng vậy. Lập kế hoạch trước khi nhảy tới giai đoạn viết code là một điều tốt, tuy nhiên "tốt quá" thì nghĩa là nó đang trở nên tồi tệ, ý tôi ở đây là lên kế hoạch quá nhiều trước khi bắt đầu. Giống như uống nước nhiều là tốt, nhưng quá nhiều nước lại là gây hại cho bạn. Đừng trông chờ vào một kế hoạch perfect. Điều đó dường như không tồn tại trong thế giới của programming. Chỉ cần một kế hoạch đủ tốt, đó là những thứ bạn sử dụng khi bắt đầu. Thực sự thì kế hoạch của bạn sẽ thay đổi, nhưng điều đó là tốt để ép bạn vào một structure hướng bạn đến sự rõ ràng hơn trong code của mình. Quá nhiều kế hoạch dễ gây ra lãng phí thời gian của bạn.

Tôi chỉ đang nói về kế hoạch cho những features nhỏ. Kế hoạch cho tất cả các features cùng một lúc thì lại nên bị cấm. Đó là những gì chúng ta gọi là Phương pháp Waterfall, đó là hệ thống tuần tự kế hoạch với các bước riêng biệt và được hoàn thành bởi từng người một. Bạn có thể tưởng tượng có bao nhiêu kế hoạch mà cần tiếp cận. Điều đó không phải là loại kế hoạch mà tôi đang nói đến ở đây. Cách tiếp cận waterfall không được hoạt động. Bất cứ điều gì phức tạp chỉ được thực hiện với sự thích ứng với agile vào thực tế. Việc tạo programs phải là một hoạt động đáp ứng với nhu cầu thực tế. Bạn sẽ thêm các features mà bạn chưa bao giờ nghĩ tới trong waterfall plan. Bạn sẽ xóa bỏ các features bởi lý do là bạn không bao giờ có giai đoạn cân nhắc trong waterfall plan. Bạn cần phải fix bugs và làm cho phù hợp với sự thay đổi. Do đó, bạn cần trở nên agile.

Tuy nhiên, hãy luôn luôn lên kế hoạch các tính năng tiếp theo. Thực hiện chúng thật cẩn thận, bởi vì quá ít kế hoạch hoặc quá nhiều kế hoạch đều ảnh hưởng xấu đến code của bạn, và chất lượng code của bạn không phải là thứ mà bạn có thể mạo hiểm để gặp rủi ro.

3. Đánh giá thấp tầm quan trọng của chất lượng code

Nếu bạn chỉ tập trung vào một khía cạnh của đoạn code mà bạn viết, nó phải có tính dễ đọc. Code không rõ ràng là rác. Nó không có tính tái sử dụng. Đừng bao giờ đánh giá thấp tầm quan trọng của chất lượng code. Nhìn vào code như là một cách giao tiếp với việc thực hiện của code. Công việc chính của một coder là hiểu rõ công việc của code thực thi mà bạn đang tạo nên.

Một câu nói yêu thích của tôi về programming:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. — John Woods

(Tạm dịch: Luôn luôn code như thể có một gã thực hiện việc maintaining code của bạn sẽ là một kẻ bạo lực và hắn biết nơi bạn đang ở - xác định đi) Một lời khuyên tuyệt vời, John! ✌️ do đó hãy cẩn thận với từng dòng code của mình nhé. Một điều nhỏ nữa cũng rất quan trọng, đó là coding convention, một cái thụt lề không nhất quán, hay không viết hoa, bạn sẽ dễ dàng mất đi bản quyền dòng code của bạn.

tHIS is
  WAY MORE important
than
         you think

Thậm chí, với một số ngôn ngữ (như coffee script) cách thụt lề còn quy định scope của block code. Một thứ đơn giản khác là viết dòng code quá dài. Những dòng code vượt quá 80 kí tự trở nên khó đọc hơn. Vì vậy nên hạn chế viết những dòng code dài, và tốt nhất đừng để vượt quá 80.

Dưới đây là một số lỗi hay gặp nữa liên quan đến chất lượng của code:

  • Sử dụng quá nhiều dòng code trong một function. Bạn nên break code ra, mỗi function chỉ nên đảm nhiệm một vai trò riêng, đừng thực hiện quá nhiều chức năng trong một function.

Any function that has more than 10 lines is just too long

  • Đừng dùng phủ định của phủ định (double nagatives)

Using double negatives is just very not not wrong

  • Using short, generic, or type-based variable names. Give your variables descriptive and non-ambiguous names.
  • Sử dụng tên biến ngắn, tên chung, hoặc kiểu. Tên biến gợi nhớ và không mơ hồ..

There are only two hard things in Computer Science: cache invalidation and naming things. — Phil Karlton

Tốt nhất thì hãy đặt tên biến sao cho khi nhìn vào biến người khác có thể hiểu ngay được vai trò/ ý nghĩa của nó là gì. Việc đặt tên cho một biến đôi khi cũng khá mất thời gian và đau đầu đấy             </div>
            
            <div class=

0