Lâu rồi không code, nhưng thử thách bản thân bằng việc chia sẻ với mọi người về những tâm đắc trong vai trò developer của mình. Trước khi làm công việc hiện tại, thì tôi cũng là 1 lập trình viên. Thật may mắn là tôi được học tập và phát triển trong những môi trường rất tốt, có tiêu chuẩn rất cao, nhờ đó cũng đúc rút ra được những tâm đắc và kinh nghiệm của mình.
Để đi nhanh thì học những cái mới, để đi xa thì học những cái căn bản
Ngành IT là 1 ngành cực kì đặc thù, khi mà hầu như ngày nào, tuần nào cũng sẽ có những công nghệ, nhưng tools mới được release. Nếu không học những thứ mới thì sẽ bị lạc hậu rất nhanh. Chỉ vài tháng thôi đi trà đá là đã không hiểu anh em đang nói cái gì rồi. Nên việc học của ngành IT cũng trở thành 1 điều hiển nhiên, 1 phần của công việc, và không phải bàn cãi.
Vì thế mà để đi kịp, và có thể vượt được người khác, chúng ta phải có khả năng học những thứ mới với tốc độ thật nhanh, kèm với đó là sự liên tục và bền bỉ.
Mặt trái của vấn đề này là “sớm nở tối tàn”, nhiều công nghệ được phát minh, nhưng số công nghệ có thể bền vững sống sót và phát triển từ 2 năm trở nên tương đối ít. Và kể cả là có thể vượt qua 2 năm đi nữa, thì việc nó duy trì được vị trí của mình cũng là rất khó.
Ví dụ của tôi là Ruby. Ngày tôi đi làm, cách đây khoảng 10 năm, thì Ruby là số 1 về độ phủ và độ yêu thích của cộng đồng ( theo github và stackoverflow ). Nhưng thứ gì cũng sẽ thoái trào. Hiện tại thì Ruby đã bị rơi xuống thứ 8 trong bảng xếp hạng ngôn ngữ. Những người từng là master về Ruby, có lẽ cũng cần nghĩ về những ngôn ngữ khác.
Một mặt trái của việc “sớm nở tối tàn” nữa là nếu chúng ta cố gắng bám theo mọi công nghệ thì sẽ không có đủ thời gian, và sự “sâu sắc” đối với công nghệ ấy cũng không được cao. Đấy là kiểu “kiến thức giả tạo” : cái gì cũng biết tên, cũng vọc vạch được, nhưng để tạo ra 1 sản phẩm chất lượng thì không làm được. ( Nó giống 1 câu chuyện cười thế này. 2 anh chàng đánh nhau, 1 anh trợn mắt lên nói : mày ngon thì lên đây, tao biết Aikido, Judo, vovinam và nhiều từ nguy hiểm khác đấy. )
Tuy nhiên, mọi công nghệ mới đều chỉ là “hình thức”. Cái tinh túy bên trong của nó thì đều giống nhau, đều dựa trên những nền tảng. Giống như bạn có thể xây hàng nghìn ngôi nhà không ngôi nhà nào giống nhau, nhưng tất cả đều dựa trên những nguyên vật liệu nhất định. Những nguyên vật liệu của ngành IT đó, nó là những kiến thức căn bản: Thuật toán, cơ sở dữ liệu, hướng đối tượng, … cho tới những kiến thức sâu sắc hơn : DDD, design pattern, micro service, serverless, clean code, …
Những kiến thức này thì khác gì những thứ tôi đã nói ở trên ?
Đầu tiên, nó là những thứ thay đổi chậm hơn. Tiếp nữa, để tiếp nhận nó 1 cách sâu sắc, bạn cần thời gian để học. Và cách học những kiến thức này – dù hơi lạc hậu – vẫn là qua sách vở.
Học những thứ này có lợi gì ? Nó giúp bạn hiểu sâu sắc hơn về hệ thống. Thường chúng ta chỉ là những người sử dụng thành thạo, chứ chúng ta không phải là những người xây dựng nên những công cụ ấy. Sự khác biệt về trình độ tri thức giữa 2 kiểu người này, chắc các bạn đều hiểu. Và khi ta hiểu rõ những thứ ta đang làm, từ đó tạo ra những sản phẩm với chất lượng cao nhất, thì giá trị và thu nhập của chúng ta cũng cao hơn nhiều lần.
Nhìn cái cây, và nhìn cả khu rừng
Khi xử lý 1 công việc ( cụ thể là 1 task ) thì tôi áp dụng “tâm đắc” này như sau.
Tôi thường dùng 1 màn hình lớn để code. Màn hình editor luôn chia theo layout 2×2. và từng ô, đều có vai trò chính xác của nó.
Ví dụ, ngày xưa tôi code Rails. Mô hình cơ bản của Rails là MVC. Tuy nhiên mô hình này không phù hợp với dự án lớn, nên tôi áp dụng mô hình MVC + services. Khi tôi làm 1 tasks nào đó, tôi sẽ luôn mở tất cả các file liên quan theo thứ tự :
- Ô trên bên trái là mở views
- Ô trên bên phải là mở controllers
- Ô dưới bên trái là models
- Ô dưới bên phải là services
Điều này giúp tôi có thể nhìn thấy tổng thể tất cả những file mà tasks của mình sẽ động vào, qua đó dễ làm việc và debugs hơn. Khi điều này thành 1 thói quen, tôi sẽ chuyển màn hình, chuyển file rất nhanh bằng phím tắt mà không bị gián đoạn.
Ý nghĩa thứ 2 của quy tắc này, là việc đánh giá 1 task.
Có một cái tính rất xấu của nhiều anh em dev, là khi nhận task, việc đầu tiên là cắm đầu vào code luôn.
Có những task đơn giản, có những tasks khó, nhưng chúng ta cần phải chậm lại, suy nghĩ về mục đích và sự ảnh hưởng của task đó với toàn hệ thống. Tasks là cái cây, toàn bộ hệ thống là khu rừng. Mình phải nhìn tổng thể, xem task này có ảnh hưởng đến các task khác không, có xung đột hay gây ra bugs không. Logic bị sai là vấn đề của khách hàng, nhưng code mà bị degrade thì chắc chắn là lỗi của dev.
Khi mình chỉ ra được những vấn đề về “khu rừng” như thế, thì chắc chắn PM, khách hàng sẽ phải nhìn chúng ta bằng con mắt khác.
Ý nghĩa thứ 3 của quy tắc này, là cách chúng ta teamwork với nhau.
Không 1 ai làm việc đơn lẻ, 1 mình 1 việc, không ảnh hưởng, không giao tiếp với người khác cả. Chúng ta sẽ luôn trong 1 team, mà 1 team thì sẽ có : các bạn dev khác, có leader, có PM, có comtor, có tester, …
Ngoài việc hoàn thành công việc của mình, chúng ta cũng cần nhìn rộng ra các members khác, để từ đó có thể giúp đỡ họ, từ đó có thể cải thiện cách thức làm việc trong team, để đạt được hiệu quả cao nhất cho team.
Rộng hơn nữa là nhìn nhận ra toàn tổ chức, để hiểu được công việc của bản thân sẽ ảnh hưởng tới những ai, và từ đó tìm cách nâng cao giá trị của bản thân mình.
Thế nào là code đẹp ?
Chắc hẳn chúng ta đều đã từng nói, hoặc nghe nói đến “code đẹp”. Nhưng thế nào gọi là đẹp thì chưa chắc chúng ta đã nghĩ đến, hoặc là có nghĩ đến rồi nhưng cũng không biết cách để định nghĩa nó.
Khi code cần lưu ý tới các tính chất sau của code :
- Tính khả đọc ( readability – code có dễ đọc hay không )
- Tính bảo trì ( maintainability – code có dễ bảo trì, phát triển thêm hay không )
- Hiệu quả phát triển ( development efficiency – code có dễ hay không )
Nếu thiếu những yếu tố này thì code không thể gọi là đẹp được. Với tôi thì tiêu chuẩn đẹp nằm trong sự đơn giản. Có thể tóm gọn như sau :
- Ít công : có thể code nhanh, hiệu quả.
- Ít code : ngắn gọn, súc tích.
- Đáp ứng đúng yêu cầu khách hàng, không thiếu, không thừa
- Có thể thiết kế thành các module để tái sử dụng
- Có quy tắc : tuân thủ các convention, best practice, hoặc các quy tắc do chính mình đặt ra.
Về các quy tắc, mỗi người – mỗi team nên output nó ra thành tài liệu. Ví dụ như quy tắc viết commit cho git; quy tắc đặt tên biến, tên hàm; quy tắc setup biến môi trường; … Gợi ý là có thể tạo 1 repo chung, rồi mỗi lần update chúng ta sẽ gửi PR lên.
Team tôi ngày xưa ngoài các quy tắc này ra, còn có 1 repo chứa các recipes book. Tài liệu này chứa các hướng dẫn và code những chức năng cơ bản : khai báo polymorphic relationship thế nào; thêm 1 column vào 1 table như thế nào; viết 1 cái api để up ảnh thế nào; … Về sau tra cứu rất tiện và code của team cũng theo 1 tiêu chuẩn và quy tắc rõ ràng.
Ngoài các cách trên, thì chúng ta nên đọc thêm các cuốn sách về “code đẹp” – tôi rất recommend cuốn “clean code”.
