Lời tựa của người dịch
Chào các bạn, mình là Biên, một Flutter mobile dev. Như các bạn đã biết, Flutter là một framework cross-platform mobile, được release lần đầu năm 2017 - chỉ sau 2 năm sau React Native. Các framework cross-platform được ra đời với tốc độ rất đáng kinh ngạc. Điều mà anh trai mình và các lão làng lo lắng cho mình, đó chính là Flutter có thể phổ biến trong khoảng thời gian hiện tại nhưng cũng rất dễ bị thay thế trong tương lai... 😰
Một số framework đã từng xuất hiện và đang bị thay thế dần, có thể kể đến như Xamarin, Cordova, Ionic... Mình cũng nghe được thông tin là nhiều công ty đang chuyển dần từ React Native sang Flutter. Kotlin Multiplatform cũng mới ra mắt phiên bản đầu tiên vào 31/8/2020, biết đâu sau này nó cũng thay thế luôn cho Flutter thì sao? 🥶
Nếu các bạn có cùng mối lo lắng như mình, thì các bạn không cô đơn. Hi vọng với bài dịch này, các bạn sẽ có phần nào câu trả lời cho những băn khoăn của bản thân. Sau đây là bài viết "Be an Engineer, not a Frameworker" (2.8k like) của tác giả John Raines trên Medium Premium.
Note: Mặc dù mình đã cố gắng dịch sao cho giọng điệu được trôi chảy nhất, nhưng vì trình độ viết lách còn non nên nhiều chỗ dịch có lối hành văn hơi kỳ quặc, mong mọi người thông cảm.
Một số series mình đang thực hiện:
- Flutter architecture design series: https://medium.com/@nvbien
- Medium Premium translate series: https://viblo.asia/u/nvbien
Be an Engineer, not a Frameworker
Bài viết này là một lời kêu gọi tự hoàn thiện bản thân. You can do it. Hãy trở thành một Engineer.
Như thường lệ, đầu tiên cần lưu ý: Engineer chắc chắn nên và cần sử dụng framework. Chúng là những thứ đẹp đẽ giúp công việc được hoàn thành và dễ bảo trì. Framework không phải là kẻ thù của bài viết này.
Xin lỗi, anh có thể giải thích cho tôi về framework là gì không? Framework là các công cụ phần mềm giúp cung cấp một hệ thống để hoàn thành các dự án cụ thể. Ví dụ, nếu bạn muốn viết một web app bằng TypeScript, bạn không cần phải bắt đầu từ đầu vì có Angular. Bạn muốn thực hành Machine Learning bằng Python? Hãy để tôi giới thiệu cho bạn Scikit-Learn và Keras. Bạn muốn viết backend bằng C#? (Ngầu thật đấy) Tôi chắc chắn bạn đã nghe về ASP.NET. Tôi có thể kể tiếp cả ngày, bạn đã hiểu ý tôi rồi đó.
Nếu bạn biết một framework, bạn có thể nhận được một công việc có từ "engineer" trong job title. Nếu bạn biết 2 framework, bạn có thể nhận được một công việc có từ "full stack". Nhưng nếu bạn muốn thành công trong công việc tiếp theo của mình - công việc mà bạn được thuê vì bạn có 3-5 năm kinh nghiệm "engineering" trên hồ sơ của mình, thì bộ kỹ năng của bạn cần đi sâu hơn nhiều so với các framework. Nếu không, bạn sẽ phải ngồi trong một chiếc ghế rất khó chịu trong thời gian thử việc 2 tháng đó. (Người dịch: Bản gốc là 90 ngày. Chà, hoá ra bên Mỹ người ta thử việc 3 tháng lận)
Bạn sẽ cần phải đi một chặng đường dài. Từ Frameworker đến Programmer đến Engineer. Hãy cùng xem xét từng giai đoạn của hành trình này. Tôi sẽ mô tả và nói về những sự phát triển, tiến bộ của từng giai đoạn đó.
The Frameworker
Chỉ vì chủ yếu làm việc trong 1 framework (hoặc 2) không có nghĩa là bạn là một Frameworker. Nhưng cũng có thể...
Framework cho phép một Frameworker xây dựng các sản phẩm theo cách tương tự như cách IKEA cho phép tôi lắp mấy cái kệ để đồ. Tôi đã tạo ra một cái kệ? Đúng. Tôi có nên tự mô tả mình là một Kỹ sư thiết kế kệ để đồ không? Có lẽ không.
Điều thiếu sót của một Frameworker là gì?
Kiến thức về ngôn ngữ lập trình
Frameworker thường có kiến thức khá sơ cấp về ngôn ngữ lập trình mà framework được viết bằng. Hơn nữa, họ có thể không nhận thức được thiếu sót của họ vì các framework được thiết kế có chủ đích để cung cấp các abstraction giúp dev tránh phải lập trình quá nhiều. Vì vậy, Frameworker có được nhiều kinh nghiệm trong việc giải quyết một số vấn đề với bộ công cụ lập trình hạn chế.
Chiều sâu kiến thức
Frameworker cũng thiếu kiến thức chuyên sâu về vấn đề mà họ đang sử dụng framework để giải quyết. Framework là implementation của các concept về một sản phẩm phần mềm. Việc implement đó thường được trừu tượng hóa (abstracted) để người dùng framework dễ dàng code thông qua các base class, decorator và auto-generated template...
Frameworker có thể thành thạo các thao tác trên framework mà không hiểu các nguyên tắc cơ bản của nó: design pattern, thuật toán, lập trình bất đồng bộ và nhiều thứ khác. Việc hiểu các khái niệm cơ bản này sẽ ngăn chặn việc sử dụng framework không đúng cách. Mặt khác, nó có thể được chuyển giao không chỉ trong phạm vi của một sản phẩm cụ thể, mà còn trên nhiều loại lập trình. Hơn nữa, nếu không có những kiến thức chuyên sâu này, Frameworker sẽ không được trang bị cần thiết để quyết định liệu một framework có thể đáp ứng đầy đủ các yêu cầu của dự án hay không.
Kết quả của Frameworking
Frameworking có tác động tiêu cực đến sự nghiệp của Frameworker và các tổ chức mà họ tham gia. Frameworker làm việc trong trạng thái mơ màng khi code chỉ đủ để ứng dụng chạy được nhưng thiếu năng lực cần thiết để kiểm tra bảo trì và mở rộng lâu dài. Rất nhiều đoạn code tệ được thả vào một chỗ nào đó, các vấn đề bị xử lý bằng các anti-pattern và chất lượng code của công ty bị giảm sút.
Nhìn góc độ nghề nghiệp, Frameworker có triển vọng khá ảm đạm. Các coder với cùng một bộ kỹ năng về framework này đang được sản xuất hàng loạt bởi hàng chục "Khoá học lập trình online, kiếm lương ngàn đô chỉ sau 6 tháng" (nguyên văn: online academies) mỗi ngày. Và nếu một Frameworker cuối cùng cũng tìm được công việc mơ ước - nơi anh ấy có thể thực hiện các dự án thú vị hơn - thì anh ấy có thể trải qua một cú sốc khi những lỗ hổng kiến thức của bản thân trở nên rõ ràng.
Ghi chú bên lề: Có thể họ không thích lập trình nữa và lên làm quản lý thì sao, ai mà biết được 
Vậy nếu một Frameworker muốn trở thành Engineer thì sao? Tôi khuyên họ nên bắt đầu bằng cách trở thành một Programmer.
The Programmer
Programmer là những người sống trong code:
- Programmer đọc rất nhiều code.
- Programmer viết nhiều loại code khác nhau.
Programmer đọc rất nhiều code
Bạn chắc chắn sẽ từng nghe rằng việc đọc source code là một trong những cách tốt nhất để học cách viết code tốt. Đó là một cách tuyệt vời để học các cú pháp của một ngôn ngữ lập trình mới.
Khả năng đọc và hiểu source code mới một cách hiệu quả có lẽ là kỹ năng quan trọng nhất mà một Engineer sẽ có, bởi vì các công nghệ, ngôn ngữ và thư viện tạo nên một "core stack" luôn luôn thay đổi. Chắc chắn sẽ luôn có những document tốt, nhưng không có gì thay thế cho việc hiểu source code bằng cách đọc nó.
Programmer đang viết nhiều loại code khác nhau
Một trong những cách nhanh nhất để thoát khỏi tình trạng Frameworker là code những thứ không phải sở trường của bạn. Nếu bạn đang dùng thư viện machine learning của Python, hãy thử tự mình code hẳn thuật toán đó xem sao. Nếu bạn đang làm desktop app, hãy thử sức với front-end web xem như nào.
Điều cần lưu ý là bạn không chỉ muốn chuyển từ một framework này sang một framework khác. Bạn đang cố gắng học hỏi. Bạn muốn sử dụng ngôn ngữ lập trình của mình ở cấp độ thấp hơn, chi tiết hơn mức bạn đã quen và sau đó tạo ra các abstract class của riêng mình. Bạn nên tìm hiểu về các thứ như I/O, sockets, event loops, buffers, hash và đệ quy. Và khi bạn muốn tạo một abstract class, bạn nên tìm hiểu về các thứ như đa hình, kế thừa, interface, state machine và design pattern.
Vậy thì khi nào tôi mới trở thành Engineer?
Những hạn chế của Programmer
Là một Programmer, bạn sẽ thấy rằng bạn có thể làm được những điều tuyệt vời trong source code - những thứ mà trước đó bạn không thể khi chỉ là một Frameworker. Tuy nhiên, bạn vẫn có thể đang chỉ là một Engineer bậc thấp mà thôi.
Hãy tưởng tượng bạn đang tự mình lắp ráp một chiếc ô tô từ nhiều linh kiện. Mỗi khi bạn cần lắp hai bộ phận với nhau, thay vì sử dụng ốc vít và bu lông, bạn lại hàn chúng lại với nhau. Bạn có thể xây dựng một chiếc ô tô hoạt động rất tốt ban đầu. Nhưng nếu một thứ gì đó sâu bên trong bị hỏng - bạn cần phải tháo rời một vài bộ phận khác ra. Tất cả những mối nối hàn đó là một sự lựa chọn tồi. Nếu bạn muốn nâng cấp chỉ một bộ phận của ô tô - thật tuyệt nếu bộ phận đó chỉ cần tháo ra và thay thế bằng bộ phận mới.
Tôi không nói rằng trở thành một Programmer có nghĩa là bạn đã hoàn toàn bỏ qua các nguyên tắc kỹ thuật. Nhưng các mục tiêu của giai đoạn Programming này khác với các mục tiêu của giai đoạn Engineering. Nếu Programming ít nhiều là một hành trình tuyến tính để đạt được năng lực ở một số kỹ năng nhất định, thì việc trở thành Engineer sẽ là một thách thức khó khăn hơn nhiều. Nói ẩn dụ thế này, bạn có thể coi nó giống như việc phát triển ngôn ngữ: với tư cách là một Programmer, bạn đang đạt được sự thông thạo của người bản xứ với ngôn ngữ mà bạn làm việc. Là một Engineer, bạn sẽ bắt đầu viết bài báo học thuật. (Người dịch: ẩn dụ kiểu gì mà không ai hiểu được. Hay lắm tác giả, cho 1 like)
The Engineer
Vậy, điều bí ẩn nào đã định nghĩa một Engineer? Engineer lập kế hoạch và viết phần mềm cân bằng giữa ổn định và thay đổi. Ổn định là một khái niệm đơn giản, nhiều Programmer đã có sẵn nó trong code của họ. Suy tính cho sự thay đổi có thể xảy ra tương lai là nhiệm vụ khó nắm bắt hơn. Cân bằng cả hai là yếu tố này khiến bạn trở thành một Engineer.
Tính ổn định
Hầu hết ai cũng hiểu khái niệm về tính ổn định: Một là phần mềm phải làm được những gì nó được cho là phải làm. Nó không nên có lỗi. Nó phải đáng tin cậy. Hai là phần mềm không nên bị thay đổi nhanh chóng và thường xuyên. Điều đó đúng ở hai khía cạnh: interface tương đối ổn định theo thời gian và interface nên nhất quán trong toàn bộ phần mềm.
Tôi sẽ không dành thêm thời gian cho thứ này, nhưng tôi sẽ nhấn mạnh rằng khi tôi nói interface, tôi đang đề cập đến nó một cách rộng rãi - nó có thể là một thứ mà bạn đã khai báo rõ ràng (như các header trong C/C++ hoặc Interfaces trong Java/C#, v.v.), nó có thể là một tập hợp nhất quán các loại dữ liệu và tên của các đối tượng được tương tác, cả ở trạng thái và trong các hoạt động (như Python, Scala, v.v.), hoặc nó có thể là giao diện đồ họa người dùng. Xác định một interface ổn định là vô cùng quan trọng, không chỉ vì tính ổn định, mà còn vì tính thay đổi.
Tính thay đổi
Engineer viết phần mềm theo cách có thể thích ứng với sự thay đổi. Cụ thể hơn, Engineer có thể dự đoán cách phần mềm có thể cần thay đổi trong tương lai. Khả năng dự đoán tương lai chắc chắn là một khả năng phát triển theo thời gian, nhưng có một vài loại thay đổi đủ phổ biến để đề cập ở đây.
Bug. Engineer giả định rằng mọi phần mềm họ sản xuất đều có lỗi. Để dễ fix bug, source code phải được tổ chức, dễ đọc và sử dụng log. Tôi sẽ không đi sâu ở đây. Ở mức tối thiểu, Engineer biết cách sắp xếp source code thành các block có thể tái sử dụng, cho dù đó là hàm hay lớp và biết cách ghép nối lỏng lẻo (loose couple) các block đó để các lỗi được cách ly nhiều nhất có thể và yêu cầu một số lượng thay đổi hạn chế.
Use Cases as Data and Behavior. Tôi nhớ mình đã có một cuộc gọi tới trưởng nhóm - người đang hoàn thành MVP (người dịch: MVP là gì thế nhỉ?) nhắm tới đối tượng khách hàng cá nhân. Tôi hỏi, "Anh đã thiết kế [phần mềm] này để nó có thể sử dụng cho các khách hàng khác bằng cách tham chiếu tệp cấu hình (configuration file) hay nó sẽ yêu cầu viết code thêm nữa để sử dụng cho các khách hàng khác?" Có một khoảng lặng dài và nó cho tôi biết tất cả những gì tôi cần. Khi Engineer thu thập yêu cầu cho một dự án, họ liên tục đánh giá các hành vi cần thiết để xác định liệu đây có phải là các hành vi có khả năng thay đổi hay không.
Một ví dụ. Khách hàng A gửi dữ liệu dưới dạng Excel được lưu trữ trên ổ đĩa chung. Khách hàng B có API. Khách hàng C yêu cầu kết nối với FTP và tải xuống các tệp CSV. Có ba hành vi khác nhau ở đây. Phần mềm của bạn có thể hỗ trợ cả ba trong số chúng trong khi tùy thuộc vào các tệp cấu hình (một tệp cho mỗi máy khách) để xác định hành vi nào sẽ sử dụng. Sau đó, khi Khách hàng C cuối cùng cũng chịu thay đổi sang API, bạn không cần phải viết code lại mà chỉ cần thay đổi thông tin FTP trong tệp cấu hình bằng thông tin API của họ.
Extension. Trong một số trường hợp, use case thay đổi đáng kể vượt ngoài những gì bạn tính toán hoặc vượt quá những gì bạn sẵn sàng hỗ trợ. Tiếp tục ví dụ phía trên, có thể bạn không muốn hỗ trợ trình tải dữ liệu để lưu trữ blob từ mọi nhà cung cấp đám mây khác nhau. Nếu bạn đã xác định rõ ràng interface nào để tải dữ liệu, thì bạn không cần phải làm vậy. Các dev cấp thấp vẫn có thể sử dụng phần mềm của bạn để nhập dữ liệu từ Amazon S3 bằng cách viết imlementation interface, miễn là bạn để cho họ một cơ hội. Một số khái niệm có thể giúp ích: kế thừa, injection, generic... Nhìn chung, Engineer có khả năng code phần mềm dễ thể mở rộng vượt ngoài những gì họ có thể lập kế hoạch.
Tổng kết
Vậy bạn đang ở đâu trong hành trình của mình? Bạn đã sẵn sàng đi xa hơn và tạo thêm điểm nhấn cho từ “Engineer” mà bạn có thể đã có trong CV của mình chưa? Trở thành một Engineer không nhất thiết phải là mục tiêu cuối cùng, nhưng đó là một nơi tuyệt vời để đến nếu bạn đã sẵn sàng thoát ra khỏi khuôn khổ.
Mình cảm thấy rất vui nếu những bài viết này góp phần vào sự phát triển của cộng đồng developer Việt Nam. Nếu bạn cảm thấy chúng hữu ích và muốn ủng hộ mình, bạn có thể mua cho mình 1 cây bút bi tại thông tin phía dưới. Sự ủng hộ của mọi người là nguồn động lực để mình ra nhiều bài viết chất lượng hơn trong tương lai. Mình xin cảm ơn!
Ủng hộ mình 1 cây bút bi:
- Tên người nhận: Nguyễn Văn Biên
- Tài khoản VietinBank: 0835465951
- MoMo: 0835465951
Rất cảm ơn sự ủng hộ của bạn!