12 nguyên tắc làm lập trình của Joel để tạo nên phần mềm tốt hơn
Người viết: Thâu Nguyễn Cách đây khoảng 10 năm, Joel đã dự đoán được những qui trình cần thiết để xây dựng nên một phần mềm chất lượng. Tạo ra một sản phẩm mang lại giá trị cho người dùng là chưa bao giờ dễ dàng. Và qua nhiều năm làm việc ở Microsoft, tạo ra Microsoft Excel, ...
Người viết: Thâu Nguyễn
Cách đây khoảng 10 năm, Joel đã dự đoán được những qui trình cần thiết để xây dựng nên một phần mềm chất lượng. Tạo ra một sản phẩm mang lại giá trị cho người dùng là chưa bao giờ dễ dàng. Và qua nhiều năm làm việc ở Microsoft, tạo ra Microsoft Excel, Trello, nhà sáng lập cộng đồng IT rộng khắp StackOverflow,… Joel đã đúc kết được 12 nguyên tắc làm lập trình như sau:
- Bạn có sử dụng source control?
- Bạn có tạo nên bản build trong một bước?
- Bạn có build mỗi ngày?
- Bạn có cơ sở dữ liệu để lưu thông tin bug?
- Bạn có fix bugs trước khi viết code mới?
- Bạn có cập nhật kế hoạch cho sản phẩm?
- Bạn có viết document cho sản phẩm, code, api,…?
- Những lập trình viên có môi trường yên tĩnh để làm việc?
- Công ty có sẵn sàng mua những thiết bị tốt nhất cho nhân viên?
- Bạn có một đội tester?
- Bạn có cho ứng viên viết code trong khi phỏng vấn?
- Bạn có kiểm tra tính dễ tái sử dụng?
Trong khi những câu hỏi này có vẻ dễ dàng trả lời YES hoặc NO, nhưng nếu bạn đạt được 12 câu thì quá chuẩn, hay 10-12 cũng tạm ổn, nhưng dưới 10 hay 5 thì có vẻ team bạn đang có vấn đề.
Và một điều cần lưu ý là những nguyên tắc này chưa phải là tất cả để đưa một sản phẩm thành công. Nếu như bạn có tất cả 12 điều kiện trên thì có lẽ team bạn đã có những thuận lợi ban đầu như một bước khởi đầu vững chắc.
Đây chỉ là điều kiện cần để tạo nên một sản phẩm ổn định, và điều kiện đủ là bạn áp dụng nó thể nào, sản phẩm bạn có thực sự mang lại giá trị cho người sử dụng, bạn có quảng bá sản phẩm tốt, bạn có đội ngũ nhân viên tâm quyết hay không, …
Bạn có sử dụng source control?
Ngày nay, người ta nói nhiều về Git-một source control phân tán cho phép các lập trình viên clone code, và tạo từng nhánh làm việc độc lập. Nó miễn phí, tốt và có nhiều ưu việt như là:
- Có thể commit code nhanh hơn SVN vì chúng ta có thể làm việc độc lập trên từng nhánh, sau khi hoàn thành thì merge lại nhánh chính.
- Có thể làm việc offline.
Thử tưởng tượng nếu bạn không có source control thì làm sao những lập trình viên có thể làm việc chung với nhau, có thể rollback khi có vần đề, hay theo dõi sự thay đổi của những developer khác,…
Bạn có tạo nên bản build trong một bước?
Bạn có thể kiểm tra xem team mình đã có bản build trong vòng một bước chưa? Ở đây chúng ta có thể viết một đoạn script duy nhất, mỗi khi chúng ta merge code vào nhánh master thì sẽ trigger script đó. Nó sẽ kiểm tra unit testing, eslint, build code, cấu hình, … và cuối cùng chúng ta được một sản phẩm có thể release.
Bản build trong một bước giúp chúng ta tiết kiệm thời gian hơn và tránh sai sót về thứ tự các bước khi chúng ta thực hiện chúng một cách riêng lẻ.
Bạn có build mỗi ngày?
Khi chúng ta sử dụng source control để làm việc với nhau, giả sử có một ai đó thêm mới hay xoá bớt một file nào đó. Và mỗi thứ ít nhất đã work trên máy của người đó. Nhưng vấn đề ở đây là chúng ta có nhiều người cùng sửa trên một source code.
Code thay đổi chạy đúng trên máy bạn, chưa chắc nó đã chạy đúng khi kết hợp code với những người khác. Và khi ấy, tưởng mọi việc đã hoàn thành anh ta commit code lên. Do có việc bận đột xuất nên anh ta cũng xin off vài ngày.
Chuyện gì sẽ xảy ra nếu vài ngày sau chúng ta build develop để QA test. Đó là không ai bảo đảm đươc rằng code build được. Vì có quá nhiều thay đổi trong những ngày qua và khi bị fail build, thì một số người cũng không có mặt trong team để fix chúng một cách nhanh nhất.
Và câu trả lời để giải quyết vấn đề này là, chúng ta nên phát hiện lỗi build nhanh nhất và fix nó sớm nhất có thể. Đó là hãy build code mỗi cuối ngày. Để nếu có lỗi build, các thành viên sẽ nhanh chóng nhận biết và fix chúng.
Và để các thành viên nghiêm túc về nó, chúng ta có thể tạo nên một checklist để theo dõi những lỗi build và có hình phạt nho nhỏ cho từng lỗi như là đóng phạt mỗi lần 10, 20 ngàn để làm team building.
Bạn có một database để lưu thông tin bugs?
Có lẽ mọi người đều thừa nhận rằng chúng ta không thể nhớ hết tất cả những bugs trong một hệ thống. Tôi cũng ko nhớ nổi thông tin 2-3 con bugs mà tôi vừa fix. Và ngày nay mọi người đều nhờ đến công cụ như Jira. Nó giúp chúng ta lưu thông tin những bugs như sau:
- Các bước để reproduce lại bug.
- Trạng thái mong muốn của bugs.
- Có những ai liên quan tới bug.
- Có những issue nào đang liên quan: design, requirement, api, …
- Bug có ưu tiên thê nào, …
Bạn có fix bug trước khi viết code mới?
Ở dự án trước đây tôi được tham gia, nó khá tệ vì codebase không được tổ chức tốt và có rất nhiều phần chỉ vì theo deadline mà code rất ẩu. Và nó cứ tiếp tục, tiếp tục đi xuống. Vì nếu một ngôi nhà có một cái nền không vững thì khó có thể xây lên được những tầng cao hơn. Và cứ thế dự án ngày càng nhiều bugs, fix bugs này sinh bugs kia.
Bởi vì các module được tổ chức ko tốt, nó gắn kết và phụ thuộc lẫn nhau cho nên khi sửa chỗ này nó bị ảnh hưởng chỗ khác. Cứ như thế một vòng luẩn quẩn và dự án ngày càng đi xuống.
Những dự án phần mềm thường vướng vào lỗi này bởi vì chúng ta không thoả thuận được deadline với manager hay khách hàng. Và ở giai đoạn đầu, chúng ta cứ cố làm hài lòng khách hàng bằng việc tung ra rất nhanh những feature mới. Nhưng chúng ta quên mất đưa “việc fix bug trước khi viết code mới”.
Nếu chúng ta để bugs càng lâu thì chi phí để fix nó sẽ càng đắt. Vì nó sẽ ảnh hưởng đến những phần code tiếp theo. Và để càng lâu, bạn sẽ chẳng còn nhớ code bạn làm gì, bạn phải mò mẫm và chẳng thể nhớ đoạn code đó làm gì cho dù đó là code bạn viết ra. Nếu code đó bạn vừa viết hôm qua thì có thể bạn chỉ mất 5 phút để fix được lỗi.
Nhưng nếu để nó qua vài ngày, vài tháng thì sao? Bạn phải đọc lại từ đầu module, feature đó và có khi ko còn kiên nhẫn để fix lỗi đó nữa. Thế là bugs lại nằm im đó, ngày càng sinh sôi ra nhiều bugs mới hơn. Và vòng luẩn quẩn lại đến.
Bạn có cập nhật kế hoạch cho sản phẩm?
Kế hoạch cho một sản phẩm là những thời gian cụ thể mà chúng ta sẽ release những gì. Ví dụ sau mỗi 2 tuần, chúng ta có một bản release chính thức cho sản phẩm. Hay khi có một feature mới, chúng ta nên có design, requirement rõ ràng, lên kế hoạch cụ thể khi nào release feature này. Điều này đặc biệt quan trọng để chúng ta có sự chuẩn bị tốt nhất của các bên để tạo nên một tính năng chất lượng nhất.
Đa số developer ghét cái cảm giác bị những người khác hỏi khi nào mày xong feature này. Tôi thường trả lời: “Nó sẽ xong khi nó xong”. Nếu bạn có một lịch trình cụ thể thì những developer như tôi phải tuân thủ và hoàn thành đúng hạn.
Quan trọng hơn nếu như bạn có một kế hoạch rõ ràng, bạn sẽ chọn được những việc ưu tiên cao nhất để hoàn thành release đúng hẹn. Bạn sẽ biết được những gì cần làm và cần cắt bỏ những phần không cần thiết như thế nào.
Bạn có viết document cho sản phẩm?
Viết document nghe có vẻ dễ dàng và đem lại nhiều lợi ích cho dự án. Nhưng có lẽ rất ít developer muốn viết document. Họ thích trình bày ý tưởng của mình bằng code hơn.
Trong qui trình phát triển phần mềm nếu chúng ta càng sớm phát hiện ra sai sót thì cái giá để sữa chữa nó sẽ càng rẻ. Bằng cách document những gì chúng ta đang làm, mọi người có thể dễ dàng hiểu hơn về sản phẩm và nhận ra điều bất ổn ngay từ đầu.
Hơn nữa, việc viết document sẽ giúp những người mới tham gian team nhanh chóng hiểu được business, hiểu được những gì đã có, hiểu được văn hóa của team, hiểu được structure code, API, …
Lập trình viên có môi trường yên tĩnh để làm việc?
Đa số lập trình viên thường phải làm việc độc lập rất nhiều và họ cần một môi trường yên tĩnh để họ tập trung làm việc. Điều này thực sự làm tôi tăng năng suất giải quyết vấn đề hơn.
Hiện nay, tôi thường thấy mọi người bị phân tán bởi nhiều thứ như là facebook, game, youtube, chat channel, …. Những thứ đó thực sự phá hủy sự tập trung của bạn và làm bạn trở nên stress hơn. Bởi vì bạn phải xử lý quá nhiều nguồn thông tin cùng một lúc.
Công ty có sẵn sàng mua những thiết bị tốt nhất cho nhân viên?
Với những máy tính cấu hình cao và màn hình lớn, những lập trình viên sẽ dễ dàng debug và tiết kiệm được thời gian để build code hơn.
Thực sự rất phiền phức và bực mình khi phải làm việc trên một máy tính chạy ì ạch, không thể mở nhiều tab chrome, điều đó gây cho những lập trình viên nhiều khó chịu và làm giảm năng suất của họ đáng kể.
Công ty bạn đang tiết kiệm những thứ nhỏ nhặt như cấu hình máy tính, màn hình thì có lé đã không nhìn xa hơn. Vì với những máy tính tốt nhất nhân viên có thể gấp đôi, gấp ba hiệu suất lao động của họ. Và công ty sẽ thu lại lợi ích nhiều hơn là đi tiết kiệm những chi phí nâng cấp phần cứng RAM, SSD vài triệu đồng.
Bạn có một đội tester?
Nếu team của bạn không có những QA chuyên nghiệp, ít nhất 2-3 người gì đó, thì có thể bạn sẽ tạo ra những sản phẩm thiếu chất lượng, và nhiều lỗi cơ bản.
Hoặc bạn sẽ lãng phí $100 cho 1 lập trình viên để test sản phẩm, hoặc bạn chỉ mất $30 thuê một QA. Bỏ qua việc kiểm thử phân mềm có thể sẽ gây ảnh hưởng lớn đến chất lượng của sản phẩm.
Và tôi chưa bao giờ thấy môt sản phẩm tốt và hữu ích mà ko được kiểm định chặt chẽ cả.
Bạn có cho ứng viên viết code trong khi phỏng vấn?
Bạn có khi nào tuyển một đầu bếp hay một ca sĩ cho công ty bạn mà bạn không kiểm tra khả năng thực của họ không?
Đơn giản nếu anh là đầu bếp thì anh xuống bếp nấu một ngón thật ngon đem lên cho tôi xem? Hay nếu anh là ca sĩ thì anh hát cho mọi người nghe xem sao? Đó là cách đơn giản để check khả năng của một người. Và có lý nào khi tuyển một lập trình viên chúng ta lại không bảo họ code cho chúng ta xem?
Bạn có thể hỏi ứng viên nhiều câu hỏi về kiến thức lập trình. Nhưng có thể đó chỉ là lý thuyết và chúng ta lại cần khả năng thực chiến hơn. Liệu họ có khả năng nhớ rất tốt lý thuyết nhưng lại không biết code.
Bạn có kiểm tra tính tái sử dụng của sản phẩm?
Một trong những đặc tính quan trong của công việc thiết kế là tính tái sử dụng dễ dàng. Với React, bạn phải tạo nên những component dùng chung trong app như: Button, Modal, Input, Dropdown, …
Xem thêm Component là gì
Bạn hãy thử viết một component để tái sử dụng nào đó, sau đó bạn hỏi 5 người trong team bạn xem họ có thể sử dụng component của bạn viết ra hay không? Bạn sẽ nhận được một số comment quý báu đấy.
Việc tái sử dụng code giúp chúng ta tiết kiệm thời gian, tránh duplicate quá nhiều code, code được quản lí tập trung hơn. Ví dụ ban đâu Button của bạn là màu xanh cho primary button, nhưng sao này liệu có thể chúng ta thay đổi style cho nó, thành màu cam gì đó ví dụ vậy. Thì công việc ở đây đơn giản chúng ta chỉ sửa một chỗ, và nó sẽ ảnh hưởng lên toàn bộ những chỗ chúng ta có sử dụng component đó.
Trong lập trình việc tái sử dụng code là hết sức quan trọng. Bạn sẽ thấy yêu cầu này ở mọi nơi trong app của bạn, từ những component, styles, function,…
Có thể bạn quan tâm:
- Các nguyên tắc lập trình mà lập trình viên nên biết
- 11 nguyên tắc code để cải thiện code của bạn
- 3 nguyên tắc tuyển dụng của Richard Branson
Xem thêm việc làm Software Developers trên TopDev
TopDev via thaunguyen.com
