Tag Archives: clean code

Từ Thuyết Cửa Sổ Vỡ, đến những dòng Code tởm dần đều theo năm tháng

Thuyết “Cửa Sổ Vỡ” ra đời vào năm 1982, dựa theo 1 quan sát khá kỳ lạ:

  • Những căn nhà/ô tô có một cửa sổ bị vỡ, nếu không được sửa chữa kịp thời, dần dần sẽ bị dân phá hoại… đập hết các cửa sổ còn lại
  • Đường đi bộ, đất trống khi bị xả rác, nếu không được lau dọn kịp thời, dần dần sẽ thành nơi dân tình ra tổng hết rác thải vào

Nguyên nhân là vì sao:

  • Khi thấy cửa sổ không được sửa, dân phá hoại sẽ nghĩ “nhà này chắc bỏ hoang, đập chắc cũng không ai quan tâm”.
  • Khi thấy rác chất chồng, dân xả rác sẽ nghĩ “chỗ này ai cũng xả rác, mình xả thêm có sao đâu?

Điều này được mấy bác cảnh sát và các nhà tâm lý học đồng tình. Có những hư hỏng, phá hoại nhỏ (cửa sổ vỡ), nhưng nếu để lâu không quan tâm sẽ trở thành những hiểm hoạ to lớn.

 

Ủa mà cái thuyết lạ lol này thì có liên quan gì đến code, đến lập trình đâu nhỉ? Ấy vậy mà có đấy, bạn đọc tiếp sẽ rõ.

Continue reading Từ Thuyết Cửa Sổ Vỡ, đến những dòng Code tởm dần đều theo năm tháng

Code bạn viết ra sẽ méo bao giờ hoàn hảo hoặc hoàn toàn clean – But that’s okay!

Nếu chăm chỉ đọc blog của mấy developer giỏi và nổi tiếng (như Uncle Bob, Martin Fowler, John Skeet), các bạn sẽ thấy họ có rất nhiều guideline để viết code cho tốt:

  • Sử dụng nguyên lý SOLID để code tách bạch, rõ ràng, dễ sửa chữa
  • Sử dụng Seperation of Concern và các mô hình phổ biến như MVC, MVVM để phân tách code thành nhiều thành phần nhỏ, dễ quản lý
  • Áp dụng design pattern để giải quyết các vấn đề trong code
  • Viết code phải viết thêm test để đảm bảo code chạy đúng

Làm và áp dụng theo những guideline này, chúng ta có thể có code… đúng chuẩn (có thể thôi nhé).

 

Tuy nhiên, trên thực tế, đa phần code trong các dự án đều khá … tởm. Code không có architecture rõ ràng, không có design pattern, viết cẩu thả. Nhiều khi đọc code xong, ta chỉ muốn đập đi xây lại, viết lại cho… đúng chuẩn.

Tuy nhiên, đã bao giờ bạn tự hỏi: Liệu viết code SOLID, chuẩn này chuẩn kia, DI/IoC đồ có thật sự làm code tốt lên hay không? Liệu ta có nên đảm bảo code viết ra phải cực kì hoàn hảo, phải có trật tự?

Continue reading Code bạn viết ra sẽ méo bao giờ hoàn hảo hoặc hoàn toàn clean – But that’s okay!

Học hỏi thông qua Best Practice – Đứng trên vai những người khổng lồ

Trong ngành phần mềm, có rất nhiều kiến thức cần học. Để trở thành một developer giỏi, chúng ta phải thường xuyên học hỏi, cập nhật những kiến thức này.

Tuy nhiên, sẽ có lúc bạn thắc mắc, những kiến thức dạng gì quan trọng nhất, mà chúng ta nên bỏ thời gian để học?

Theo mình, có 3 dạng kiến thức quan trọng:

  • Kiến thức nền tảng về khoa học máy tính, về kiến trúc phần mềm (software architecture), kiến thức hệ thống (system architecture)
  • Kiến thức về ngôn ngữ lập trình/công nghệ được dùng. Đây là những kiến thức thực tế, được áp dụng trong công việc hằng ngày.
  • Best practices, đây là những kiến thức rút được dựa theo kinh nghiệm của những người đi trước trong ngành, mà chúng ta nên biết và làm theo. Đây là những thứ trường học không hề dạy!

Trong bài này, mình sẽ chia sẻ về best pratices, cách học hỏi và những lợi ích của chúng nhé.

Continue reading Học hỏi thông qua Best Practice – Đứng trên vai những người khổng lồ

Developer phải làm sao khi làm việc với code … rởm?

Ở bài “Tại sao code của dự án hiện tại nó … tởm quá vậy” trong kì trước, mình đã nói lý do mà code của các dự án càng để lâu sẽ càng loằng ngoằng, rối rắm.

Đây là chuyện bất khả kháng, và chúng ta ít khi có quyền lựa chọn project mình tham gia!

Thay vì than trời, trách đất, chửi mấy lão developer trước kia, bạn hãy cùng mình tìm hiểu một số cách “sống chung với lũ” – tức sống và làm việc chung với code bựa.

Ở cuối bài, mình cũng sẽ chia sẻ một số phương pháp để nâng cao chất lượng code trong dự án, giúp code đỡ “tởm dần đều” qua thời gian nhé!

Continue reading Developer phải làm sao khi làm việc với code … rởm?

Tại sao code hiện tại của dự án lại … “tởm” quá vậy?

Khi đi học hoặc mới đi làm, chúng ta được dạy về việc viết code rõ ràng, mạch lạc, chất lượng:

  • Code phải được chia tách thành các class/module rõ ràng.
  • Mỗi module phải làm một nhiệm vụ duy nhất, ít lệ thuộc lẫn nhau (high cohension/low coupling)
  • Code được thiết kế theo architecture phù hợp (3-tier hoặc MVC) tùy vào dự án. Có sử dụng design pattern tùy vào vấn đề.

Khi tham gia dự án đầu tiên, hẳn ai cũng mong rằng mình sẽ được tiếp xúc với những dòng code mạch lạc, chất lượng như vậy.

Thế nhưng, đời sẽ cho bạn một gáo nước lạnh ngay lập tức! Khi tham gia một dự án, nhiều khả năng các bạn sẽ được đọc một đống code vừa khổng lồ, vừa tởm vừa rối như canh hẹ.

Có những đống code đọc vào chỉ muốn chửi WTF

Thật đấy, 96.69% code của các dự án lớn đều như vậy cả. Có thể dự án hiện tại bạn đang làm cũng vậy đấy!

Vì sao thế? Cùng đọc bài viết này để biết nhé!

Continue reading Tại sao code hiện tại của dự án lại … “tởm” quá vậy?

Review sách: The Clean Coder – Trở thành coder chuyên nghiệp và “có tâm”

Mấy tuần trước, khi đi lang thang trên dạy nhau học, mình có thấy anh Đạt, founder daynhauhoc dành khá nhiều lời khen ngợi cho cuốn sách này.

screen-shot-2016-11-08-at-9-19-31-pm

Tò mò nên mình tìm về đọc thử. Quả thật sách không làm mình thất vọng! Có nhiều đoạn tác giả nói đúng đến mức không thể đúng hơn, hoặc đưa ra những lời dạy bảo vô cùng chí lí.

Do vậy, mình viết bài này, vừa review sách, vừa tóm tắt những điều tâm đắc mà mình rút ra được từ cuốn sách.

Continue reading Review sách: The Clean Coder – Trở thành coder chuyên nghiệp và “có tâm”

Chuyện về các cây đa cây đề trong làng Software Engineering

Để thành một lập trình viên giỏi, có rất nhiều bạn phải học và phải biết: Cách viết code sạchrefactor code, design thế nào để code SOLID, Inversion of Control và  Dependency Injection, Agile methodology, …

Tuy nhiên, đã bao giờ bạn tự hỏi: “Ai là người đã nghĩ ra những thứ đấy” chưa?. Bài viết này sẽ kể bạn nghe về những người đó. Đây là những cái tên có nhiều đóng góp to lớn cho ngành phần mềm. Họ nổi tiếng không chỉ nhờ khả năng code, mà còn nhờ khả năng viết và diễn đạt, truyền cảm hứng.

img

Continue reading Chuyện về các cây đa cây đề trong làng Software Engineering

Luận về comment code (Phong cách kiếm hiệp)

Comment code luôn là vấn đề gây tranh cãi sứt đầu mẻ trán trong giới võ lâm. Xưa kia, thuở còn mài đít trên ghê nhà trường, ta thường được các thầy dặn rằng: Code nhớ phải comment. Thuở mới đi làm, sơ nhập gian hồ, mỗi khi đọc code không hiểu, ta cũng hay đập bàn mà chửi: “Thằng này code ngu quá đ*o comment gì cả”.

Thế nhưng, lưu lạc giang hồ bao năm, đọc code cũng nhiều; từ code không comment cho tới code comment đầy đủ và sạch sẽ; ta vẫn băn khoăn không biết thật sự phải comment thế nào mới đúng. Thế rồi, sau khi đọc Clean Code, ta như lượm được bí tịch võ công trong truyền thuyết. Ta ngộ ra được cái gọi là “đạo code”, “đạo comment”, đặt 1 bước chân vào con đường võ đạo đỉnh cao (Đạo ở đây là đạo lý, ko phải đạo tặc trộm cướp nhé).

Capture

Continue reading Luận về comment code (Phong cách kiếm hiệp)

Hãy biết nói KHÔNG

Mình từng post một comic khá đơn giản về chuyện “Thiết kế của một trang web có thể trở nên banh chành như thế nào“. Đó là một câu chuyện về ảnh hưởng của khách hàng đã làm “banh chành” một sản phẩm của designer. Tuy chỉ là chuyện hài, nhưng nó vốn là một chuyện buồn có thật mà những người trong nghề như chúng ta đều gặp phải. Tuy nhiên, thật ra ai có lỗi trong chuyện này …?

Continue reading Hãy biết nói KHÔNG