Vien Truong

Học một trong các Framework sau: Angular/ React/ Vue. Vì những Framework này giúp bạn xây dựng front-end cho ứng dụng nhanh hơn, dễ dàng mở rộng và thay đổi UI, đồng thời giữ cho code front-end có tổ chức hơn.

Nhìn chung thì để trở thành một Back-end developer đòi hỏi bạn phải có nhiều nổ lực và kiên trì hơn. Vì vậy trở thành một Front-end developer tương đối dễ và nhanh hơn Back-end developer.

Nhìn chung thì để trở thành một Back-end developer đòi hỏi bạn phải có nhiều nổ lực và kiên trì hơn. Vì vậy trở thành một Front-end developer tương đối dễ và nhanh hơn Back-end developer.

OK, con đường là do bạn lựa chọn. Hãy tìm hiểu và đi lựa chọn công việc mà bạn đam mê và chào mừng bạn đến với hội anh em “coder”.

Thế giới lập trình là rộng lớn với rất nhiều lĩnh vực và cơ hội mang lại cho bạn sự trải nghiệm, cũng như con đường đi mà bạn sẽ chọn lựa cho sự nghiệp, đam mê của mình.

Qua các thông tin ở trên, bạn dễ dàng nhận ra rằng để trở thành một Back-end developer bạn phải hiểu biết nhiều công nghệ hơn Front-end developer.

Trong lĩnh vực lập trình ứng dụng web, chúng ta có lập trình cho Front-end và lập trình cho Back-end. Bắt đầu từ hướng lập trình Front-end là dễ dàng hơn cho bạn. Vì sao ư?

Để trở thành một Front-end developer bạn chỉ cần học một số công nghệ chính bên dưới:

<ol>
	<li>HTML5</li>
	<li>CSS3</li>
	<li>JavaScript</li>
	<li>Học một trong các Framework sau: Angular/ React/ Vue. Vì những Framework này giúp bạn xây dựng front-end cho ứng dụng nhanh hơn, dễ dàng mở rộng và thay đổi UI, đồng thời giữ cho code front-end có tổ chức hơn.</li>
</ol>

Trong khi để trở thành một Back-end developer bạn cần phải nắm được những công nghệ sau:

<ol>
	<li>Ngôn ngữ lập trình cho Back-end. Bạn sẽ phải chọn dùng một trong các ngôn ngữ: C#, Java, PHP, Python, etc.</li>
	<li>Bạn phải học một Framework tương ứng cho ngôn ngữ mà bạn đã lựa chọn. Ví dụ: bạn chọn dùng C# thì bạn phải học thêm về .NET Framework, .NET Core, etc. Bạn chọn dùng Java thì phải biết Framework: Hiberate hoặc Spring, etc. Bạn chọn dùng PHP thì phải biết thêm: Laravel hoặc Zend hoặc CodeIgniter, etc. Bạn chọn Python thì phải biết về Django framework, ect.</li>
	<li>Database (cơ sở dữ liệu): một Back-end developer cần phải biết thêm các loại databases để lưu trữ dữ liệu cho ứng dụng của mình như: SQL Server, Mongo DB, Elastic Search, PostgreSQL, Redis, Couch DB, etc.</li>
	<li>Hosting: bạn cần biết một số dịch vụ để deploy ứng dụng của mình như: Google Cloud Platform, AWS (Amazon Web Services), Microsoft Azure, etc.</li>
	<li>Các công cụ quản lý server: bạn cần có kiến thức về các công nghệ và dịch vụ như: Docker, Kubernetes, New Relic, Nginx, Varnish, etc.</li>
</ol>

Qua các thông tin ở trên, bạn dễ dàng nhận ra rằng để trở thành một Back-end developer bạn phải hiểu biết nhiều công nghệ hơn Front-end developer. Hơn nữa, Back-end developer còn phải có kiến thức về <a href="https://thangphampt.wordpress.com/2019/01/04/architectural-styles-vs-architectural-patterns-vs-design-patterns/">Architectural Styles, Architectural Patterns, Design Patterns</a> để có thể đi tiếp con đường trở thành một Senior Developer hay xa hơn là trở thành một <a href="https://thangphampt.wordpress.com/2018/12/03/dau-la-diem-khac-biet-giua-solution-architect-va-software-architect/">Software Architect</a>.

Nhìn chung thì để trở thành một Back-end developer đòi hỏi bạn phải có nhiều nổ lực và kiên trì hơn. Vì vậy trở thành một Front-end developer tương đối dễ và nhanh hơn Back-end developer.

OK, con đường là do bạn lựa chọn. Hãy tìm hiểu và đi lựa chọn công việc mà bạn đam mê và chào mừng bạn đến với hội anh em “coder”.

Thế giới lập trình là rộng lớn với rất nhiều lĩnh vực và cơ hội mang lại cho bạn sự trải nghiệm, cũng như con đường đi mà bạn sẽ chọn lựa cho sự nghiệp, đam mê của mình. Bạn là một người mới và đang mong muốn trở thành một web developer. Và thời điểm này bạn vẫn chưa thể xác định sẽ bắt đầu từ đâu khi đi trên con đường này. Với kinh nghiệm của bản thân, mình sẽ chia sẽ để giúp bạn có định hướng và cái nhìn tổng quan hơn trước khi bước chân vào con đường trở thành web developer.

Muốn trở thành một web developer nên bắt đầu từ đâu?

<h2>SOLID</h2>

Chúng ta cùng tìm hiểu về nguyên lý SOLID. Nội dung chính của nguyên lý này được kết hợp từ 5 nguyên lý cơ bản sau:

1. Single Responsibility Priciple: 
Đây là nguyên lý đầu tiên (chính là chữ S đầu trong SOLID). Nguyên lý này nói rằng không nên có hơn 1 lý do để một lớp (class) thay đổi. Nghĩa là, bạn nên thiết kế class của bạn sao cho mỗi class chỉ phục vụ cho một mục đích.

Ví dụ: Một kịch bản như sau, chúng ta cần một tính năng lên lịch hẹn phỏng vấn ứng viên (schedule interview). Công việc chúng ta cần làm là: lưu thông tin buổi phỏng vấn, sau đó gửi mail cho ứng viên về buổi phỏng vấn. Thay vì thiết kế một class ScheduleInterview để làm tất cả các việc trên, bạn tạo một class Interview chỉ để thực hiện công việc lưu thông tin buổi phỏng vấn, và chúng ta có thêm class EmailSending dùng để thực hiện công việc gửi mail cho ứng viên.

2. Open/Closed Priciple: 
Đây là nguyên lý thứ hai (chính là chữ O trong SOLID). Nguyên lý này nói rằng các thực thể phần mềm như: classs, modules, functions,… thì có thể thoải mái viết code để mở rộng nhưng hạn chế cho việc sửa đổi. 
Từ “Closed” ở đây nghĩa là, một module đã được phát triển và tested thì code của nó chỉ được thay đổi để sửa lỗi. 
Từ “Open” nghĩa là module có thể dễ dàng và thoải mái được mở rộng từ code hiện tại để phục vụ cho tính năng mới. 
Ví dụ: một lớp cơ sở PaymentGatewayBase chứa tất cả các thuộc tính và phương thức thanh toán cơ bản. Lớp này có thể được mở rộng bởi các lớp PaymentGateway khác nhau cho các nhà cung cấp cổng thanh toán khác nhau để phục vụ các chức năng của họ. Do đó, nó được mở rộng dễ dàng và thoải mái nhưng hạn chế việc thay đổi.

3. Liscov Substitution Priciple: 
Nguyên ly này nói rằng các đối tượng của lớp con có thể thay thế được các đối tượng của lớp cha mà vẫn đảm bảo tính đúng đắn của chương trình. 
Nói cho dễ hiểu thì chỉ cho class A kế thừa class B khi class A thay thế được class B. 
Nguyên lý này là cách để đảm bảo rằng kế thừa được sử dụng đúng cách.

Ví dụ: 
– Một ví dụ cho trường hợp vi phạm nguyên lý này như sau. Giả sử chúng ta có một lớp Chim với một phương thức là Bay(). Như vậy, chúng ta có thể nói rằng 3 lớp ChimHảiÂu, ChimSáo, ChimCánhCụt đều là Chim nên chúng ta sẽ cho chúng kế thừa lớp Chim. Tuy nhiên, khi gọi Bay() thì ChimHaiAu và ChimSao chạy tốt, còn ChimCanhCut quăng lỗi vì chim cánh cụt thì không bay được. 
– Giả sử chúng ta có class Student kế thừa từ class Person. Vậy theo nguyên lý này thì bất cứ nơi nào có thể dùng Person thì cũng có thể dùng Student, bởi vì Student là class con của Person. 
– Trong C# chúng ta có thể dùng ForEach với List, ArrayList, LinkedList bởi vì chúng được kế thừa từ interface IEnumerable. Các class List, ArrayList,… được thiết kế đúng LSP nên chúng có thể thay thế cho IEnumerable.

4. Interface Segregation Priciple: 
Nguyên lý này nói rằng thay vì dùng 1 interface lớn, ta nên tách thành nhiều interface nhỏ với nhiều mục đích cụ thể. 
Ví dụ: nếu chúng ta có một interface với 20 phương thức (method), vậy thì những class implement sẽ phải implement toàn bộ 20 methods này, kể cả những methods mà nó không bao giờ sử dụng đến. Áp dụng nguyên lý này, chúng ta sẽ chia nhỏ interface lớn này ra thành những interfaces nhỏ hơn, các class chỉ cần implement những interface có chức năng mà chúng cần, không cần implement những methods mà chúng không sử dụng.

5. Dependency Inversion Priciple (DIP): 
Nguyên lý này nói rằng, các module cấp cao không nên phụ thuộc vào các module cấp thấp. Cả hai nên phụ thuộc vào abstractions (interface). 
Abstractions (Interface) không nên phục thuộc vào chi tiết, mà chi tiết nên phụ thuộc vào abstractions (interface). Nghĩa là, Các class nên giao tiếp với nhau thông qua interface, không phải thông qua implementation. 
Ví dụ: Dependency Injection pattern là một implementation của nguyên lý này.

<h2>DRY – Don’t Repeat Yourself</h2>

Nguyên lý này nói rằng mỗi mẩu kiến thức nhỏ (code) chỉ có thể xảy ra chính xác một lần trong toàn bộ hệ thống. Điều này giúp chúng ta viết mã mở rộng, bảo trì và có thể sử dụng lại được.

<h2>KISS – Keep it simple, Stupid!</h2>

Nguyên lý này nói rằng cố gắng giữ cho từng phần nhỏ của phần mềm đơn giản và nên tránh phức tạp chúng không cần thiết. Điều này giúp chúng ta viết code dễ bảo trì.

<h2>YAGNI – You ain’t gonna need it</h2>

Nguyên lý này nói rằng luôn luôn thực hiện những điều khi bạn thực sự cần chúng, không bao giờ thực hiện mọi thứ trước khi bạn cần chúng.

Các nguyên lý thiết kế phần mềm là những hướng dẫn giúp cho nhà phát triển phần mềm (developers) tạo ra được một thiết kế hệ thống tốt. Chúng ta có các nguyên lý trong thiết kế phần mềm như: SOLID, DRY, KISS, YAGNI.

Muốn trở thành một web developer nên bắt đầu từ đâu?

Related articles

OTHER ARTICLES FROM THIEN NGUYEN