Giới thiệu
Chào các bạn, mình là Huy - CEO của ProG Coder đây😁. Như tiêu đề bài viết thì hôm nay mình sẽ chia sẻ một chút về khóa luận đồ án của mình vừa qua xem đồ án của mình có những công nghệ gì và khủng bố như nào để đạt điểm số cao nhất nhì khóa nhé 😂
Lựa chọn đề tài
Team bọn mình có tên là Potoro gồm 4 thành viên là Hiếu, Hiền, Tín và mình. Giảng viên hướng dẫn bọn mình là thầy Nguyễn Xuân Long. Trước khi đưa ra đề tài chính thức cho đồ án thì bọn mình đã băng qua rất nhiều cuộc thi cùng nhau như Fshark, ResFes, Hackathon ... tất cả đều của FPT tổ chức và cũng nhận được khá nhiều giải lớn nhỏ (cả ăn hành nữa).
Bọn mình có rất nhiều ý tưởng bao gồm cả việc phát triển lại mốt số ứng dụng đã mang đi thi ở các sân chơi trên nhưng xong tất cả bọn mình quyết định làm mới hoàn toàn và chốt được chủ đề là: Nền tảng C2C trong lĩnh vực lưu trú.
Thực ra thì đây có thể coi là phiên bản reboot của nền tảng này do trước đó bọn mình đã build version đâu tiên cho trường ĐH FPT. Nôm na đây là một Website cho thuê trọ.
Công nghệ được áp dụng
Sau khi đã lựa chọn được chủ đề cho dự án thì bọn mình bắt đầu lựa chọn các công nghệ sẽ áp dụng cho đồ án.
Do tính chất là dự án cuối cùng cho khóa luận nên bọn mình quyết định sẽ áp dụng những công nghệ mới nhất hiện nay cho đồ án có thể kể đến như:
- Architecture
- - Microservices
- - Clean Architecture
- Design Parten
- - CQRS Pattern
- - Mediator pattern
- - Sage Pattern
- Back End
- - .NET Core 6
- - IdentityServer 4
- - Mediator
- - SignalR
- - RabbitMQ
- - Entity Framework
- - Elastic Search
- Front End
- - ReactJS
- - React Saga
- - Next JS
- Database
- - SQL Server
- - MongoDB
- Message Broker
- - Redis
- DevOps, Deployment & Server Architecture
- - Auto Scale, Load Balancer (Kubernetes)
- - CI/CD
- - Prometheus, Grafana Monitoring
- - Cloud VPS
- - Docker
- - Portainer
- - Cdvisor
- - InfuxDB
- - Telegraf
- Testing
- - Automation Test (XUnit)
- - Manual Test
- Model
- - Waterfall kết hợp Agile
- Source Control
- - Gitlab
- Other
- - Sử dụng PayPal, VnPay, Momo để thanh toán
Overview nó trông thế này:
Còn khá nhiều nhưng mình nêu nổi bật một vài thứ thôi.
Và các bạn biết không, tất cả các công nghệ này bọn không một ai biết về nó 😂 Khá liều mình khi mà thời gian làm đồ án chỉ có 4 tháng với một lượng kiến thức và công việc "ít" thế kia!!! Nhưng với khả năng ghi bàn ở phút 90+5 thì bọn mình cũng làm được trong vòng 2 tháng @@ (Do 2 tháng trước đó bọn mình chơi URF và chỉ khi thầy hỏi output mới vắt chân lên cổ chayk)
Mình ôm phần Deployment (DevOps & Server Architecture), Back End và Testing nhé mọi người 😁
Sơ lược về các Công Nghệ, Kiến Trúc đã dùng
Do các công nghệ và kiến trúc này khá là nhiều không thể nói hết trong bài viết này được nên mình sẽ tóm gọn lại các ý chính trong phạm vi dự án của bọn mình. Các bạn theo dõi các bài viết thường xuyên mình sẽ cập nhật và nói về các phần này sau. Hoặc các bạn có thể Google để đọc thêm tài liệu nhé.
Architecture
Microservices
Đây là một kiến trúc ra đời cũng khá là lâu rồi và nó cũng đã được áp dụng ở rất nhiều các công ty khác nhau, hầu hết là các công ty làm về thương mại điện tử. Ví dụ như Tiki, Shopee... cũng đang sử dụng kiến trúc này.
Mô hình kiến trúc này hiểu hơn giản là chia nhỏ các Module ra thành từng phần nhỏ khác nhau như cái tên gọi của nó 😀 VD: bạn có một Web MVC có các chức năng: Đăng Nhập, Tìm kiếm, Mua Hàng. Theo mô hình MVC bạn sẽ tạo ra một Web App có đầy đủ 3 chức năng kia trong cùng một project. Nhưng bây giờ bạn tách là làm theo mô hình Microservices thì 3 chức năng kia sẽ được chia ra làm 3 services khác nhau và có thể là 3 cái Database khác nhau nữa. Tất cả chúng sẽ được lưu xuống một Database chung gọi là Master Database.
Kiến trúc này thường được áp dụng cho các dự án siêu to khổng lồ.
Lý do bọn mình chọn kiến trúc Microserives do tụi mình muốn học hỏi kiến thức mới và đặc biệt là build ra một dự án siêu to không lồ đi bảo vệ. Các bạn theo dõi hình trên sẽ rõ.
Giải thích qua về các Service trên:
-
Communicate Service: Có chức quản lý các kênh kết nối tới việc thực hiện Real Time trên các Service khác.
-
Search Service: Đảm nhiệm chức năng tìm kiếm
-
Booking Service: Xử lý các nghiệp vụ về đặt/trả phòng
-
Envoice Service: Quản lý các hóa đơn
-
Facility Service: Quản lý các nghiệp vụ chung như xem danh sách phòng, danh sách dãy trọ, quản lý các comment...
-
Identity Service: Thực hiện quản lý về Security của toàn bộ các Service
-
Payment Service: Xử lý các giao dịch thanh toán qua ngân hàng, PayPal, Momo...
Clean Architecture
Clean Architecture là một kiến trúc ứng dụng rất nổi tiếng dựa trên nguyên lý loại bỏ sự lệ thuộc giữa các đối tượng cũng như các layer trong ứng dụng. Nguyên lý này kế thừa và phát triển dựa trên Dependency Inversion - nguyên lý nổi tiếng trong SOLID.
Kiến trúc này có 4 lớp chính theo thứ tự từ ngoài vào trong là: Từ trong ra ngoài Entities, Use Cases, Interface Adapters và Frameworks & Drivers. Mỗi lớp sẽ đảm nhiệm một nhiệm vụ khác nhau.
Sau đây là cấu trúc của một Module sau khi bọn mình đã áp dung Clean Architecture:
Lý do bọn mình chon Clean Architecture thay vì chọn Onion Architecture hay các Architecture khác do nó rất clean code, dễ bảo trì và nhìn sẽ không bị rối não :D
Design Parten
CQRS Pattern
CQRS là viết tắt của Command and Query Responsibility Segregation, là một parten tách biết hai luông đọc và ghi giữ liệu. CQRS giúp ứng dụng tăng performance, scalability, và security. Lý do bọn mình thì chọn thì như cái lợi ích của nó thôi 😆
Mediator pattern
Về Mediator các bạn có thể hiểu rằng do bọn dùng sử dụng Microservices nên việc quản lý các Dependency là hết sức cần thiết. Ví dụ như trong một dự án các bạn sử dụng các Interface để gọi qua các hàm xử lý của các class Implement nó. Khi muốn dùng Interface này để gọi vào trong Controller các bạn cần nhúng nó vào bên trong Constructor mà bạn muốn dùng (Dependecy Injection). Và bây giờ giả dụ các bạn có 100 cái Controller cũng dùng chung Interface này thì sao? Nó vẫn ổn nhưng không thật sự tốt do có thể nó sẽ bị gọi trồng chéo lên nhau và đôi khi là tốn bộ nhớ. Do bó sử dụng Meditor để quản lý là cần thiết cho một dự án bự. Trong dự án của bọn mình, bọn mình dùng Mediator của .NET Core để Implement Partern này.
Saga Pattern
Hệ thống Microservices được thiết kế cho phép các dịch vụ có thể chạy đồng thời để đạt được yêu cầu hiệu suất cao. Tuy nhiên, có rất nhiều vấn đề đòi hỏi các dịch vụ phải xử lý các yêu cầu một cách đồng bộ. Vấn đề này được gọi là Distributed transactions (giao dịch phân tán)
Ví dụ trong dự án của bọn mình khi chủ nhà trọ chấp nhận đăng ký lưu trú, tình trạng đặt phòng sẽ được cập nhật tại Facility Service và giá dịch vụ sẽ được cập nhật theo hợp đồng trong Invoice Service. Khi cả hai giao dịch Facility và Invoice được hoàn tất, giao dịch tại Booking cũng sẽ được hoàn tất.
Mỗi Distributed transaction là một Saga. Sau khi dịch vụ Booking xử lý logic nghiệp vụ, nó sẽ lưu trạng thái Saga dưới dạng ĐANG GỬI và gửi một thông báo tới message broker (RabbitMQ). Facility Service sẽ nhận và xử lý thông báo đó theo logic nghiệp vụ. Sau đó, nó sẽ gửi một tin nhắn đến kênh Saga Reply để trả lời trạng thái của dịch vụ Booking. Cuối cùng khi Booking Service nhận được tin nhắn sẽ thực hiện giao dịch, trạng thái của Saga lúc này là ĐÃ XONG.
Back End
.NET Core 6
Do tính chất là chỉ dùng những hàng mới nhất hiện nay nên bọn mình chọn .NET Core 6 để làm phần code chính cho Back End API. Chỉ đơn giản vậy thôi 😁
IdentityServer 4
IdentityServer4 là một framework hỗ trợ OpenID Connect và OAuth 2.0 trên ASP.NET Core. Nó cũng là một gói thư viện trên Nuget được dùng trong ASP.NET Core như một middleware cho phép đăng nhập/đăng xuất, cấp token, chứng thực và các giáo thức chuẩn khác. Tại sao bọn mình lại dùng IdentityServer 4 thay vì sử dụng cách đăng nhập thông thường là cấp một JWT Token, hoặc đơn giản là sử dụng Identity để đăng nhập. Có rất nhiều cách mà sao lại chọn cái khó nhất?🤔 Cái gì cũng có lý do của nó cả. Như các bạn thấy Microservices là tập hợp của nhiều Service nhỏ hơn (hiểu đơn giản là các App API nhỏ).
Ví dụ trong đồ án này bọn mình có các Service như: Communicate, Search, Booking, Envoice, Facility, Identity, Payment. Và đa số chúng đều cần được bảo mật. Chả nhẽ bây giờ phải tạo ra từng ấy Token để đăng nhập sao? Switch case token để xem nó thuộc Booking hay Envoice à? Như thế thì nông dân quá.
Do vậy giải pháp là sử dụng IdentityServer 4. Nó sẽ giúp mình quản lý các phiên đăng nhập, cấp token để thực hiện việc Authentication và Authorization ở các Service.
Mediator
Bọn mình sử dụng NuGet Mediator để áp dụng cho Mediator Patern.
SignalR
SignalR API được sử dụng để tạo ra ứng dụng Real Time như Chat, Push Notification. Bạn có thể biết thêm chi tiết về ở đây.
Trong đồ án bọn mình sử dụng trong Communicate Service.
Xem các tạo ứng dụng chat Real Time tại đây
RabbitMQ
Sử dụng RabbitMQ để bắn các Events trong App qua lại với nhau. Cụ thể trong kiến trúc của bọn mình áp dụng. Mỗi Service có một Database khác nhau do đó việc Sync Data với nhau là rất quan trọng.
Ví dụ: Khi bạn thực hiện thanh toán tiền phòng tại Payment Service. Yêu cầu được gọi lúc này sẽ gửi kèm một message tới RabbitMQ trạng thái của message trong RabbitMQ lúc này là Pending. Sau khi thực hiện thanh toán thành công hoặc thật bại RabbitMQ sẽ call tới Invoice Service và Communicate Service để thực hiện việc lưu thông tin hóa đơn vào Database của Invoice Service (Database của Invoice và Payment khác nhau) và Push Notification qua Communicate Service tới người dùng. Và Roll Back tất cả các đoạn xử lý trước nếu có lỗi.
Entity Framework
Nó giống như Spring JPA và Hibernate trong Java. Cá nhân mình thấy nó sịn hơn 2 thằng kia 😁 Có nhiệm vụ là thao tác dữ liệu với Database như Thêm/Sửa/Xóa/Lấy dữ liệu.
Elastic Search
Nhiều bạn sẽ có thắc mắc rằng. Đã có Entity Framework sử dụng Contains hoặc đơn giản là LIKE trong SQL để Searh cần gì tới một Search Engine khác. Không đâu các bạn? Cái này tuyệt vời hơn nhiều. Mình đã làm rồi nên mình biết.
Về câu hỏi trên trước hết các bạn cần biết về Full Text Search. Ai mà làm về chức năng Search đã thấy đây luôn là một vấn đề nhức nhối. Ví dụ bạn tìm kiếm từ khóa: Potoro. Nếu bạn tìm kiếm bằng LIKE trong SQL thì với tập 3 dữ liệu sau: Dãy trọ Potoro, Trọ Potoro, Đồ án Potoro. Có thể là bạn sẽ chỉ nhận được 2 trong số 3 dữ liệu trên. Mình đã gặp rất nhiều rồi. Bạn sẽ không nhận được dữ liệu tìm kiếm như mong muốn. Chưa kể là tốc độ tìm cũng châm chậm.
Elastic Search thì khác giải quyết được hầu hết các vấn đề tồn đọng. Không phải ngẫu nhiên mà các ông lớn như Netfix, Microsoft, Uber, Slack... chọn nó. Do nó là một Search Engine nghĩ là sinh ra chỉ để Tìm Kiếm thôi.
Nó chung nó rất bá đạo mà còn Open Source và mình cũng đang sử dụng nó cho Code Mega :D Mình sẽ hướng dẫn các bạn sử dụng và cái đặt nó ở bài viết sau.
Front End
ReactJS, React Saga, Next JS
Bọn mình sử dụng các thư viện và framework này để build giao diện cho Web. Vì nó nhanh, gọn, về mặt UI sẽ mang lại trải nghiệm sịn sò hơn HTML thuần cho người dùng. Facebook hắn cũng đang dùng React. À mà React là do Facebook tạo ra mà 😂
Database
SQL Server
Dataabase chính bọn mình sử dụng SQL Server. Do team mình làm việc với SQL Server rất nhiều trên công ty nên bọn mình tận dụng cac kỹ năng đã được áp dụng cho tiện. Một phần cũng vì nó khá ngon.
MongoDB
Tại sao lại dùng thêm MongoDB trong khi đã có SQL Server. Chắc các bạn cũng biết MongoDB là một dạng NoSql có nghĩ là không sử dụng các Relationship vì vậy hắn cho tốc độ truy cập nhanh hơn các dạng Database có sử dụng Relationship như SQL Server, MySQL, Oracle SQL.
Do đó bọn mình sử dụng MongoDB để lưu các dữ liệu không quá quan trọng và trường xuyên được người dùng truy cập. Còn về mặt bảo toàn sự toàn vẹn của dữ liệu thì không cái nào thay thế đc các dạng Database có Relationship.
Message Broker
Redis
Redis (REmote DIctionary Server) là một mã nguồn mở được dùng để lưu trữ dữ liệu có cấu trúc, có thể sử dụng như một database, bộ nhớ cache hay một message broker.
Bọn mình sử dụng nó để làm nơi trung gian cho RabbitMQ và đôi khi là lưu trữ dữ liệu do dữ liệu của Redis được lưu trên RAM nên không thằng nào có thể so về tốc độ truy cập được với nó. Các bạn cũng biết rồi chứ nhỉ cái gì lưu trên RAM thì chả nhanh vì tất cả các chương trình chạy bằng RAM là chính mà.
DevOps, Deployment và Server Architecture (Phần của mình đây rồi 😅)
Cloud VPS
Về Main Server bọn mình sử dụng Cloud VPS của Upload, Vultr, Azdigi. Lý do là dùng nhiều hãng khác nhau như vậy là do trước đó mình tìm kiếm xem thằng nào ngon nhất và lỡ cài các Tool trên đó rồi nên nhác đưa về chung một thằng.
Top nhà cung cấp VPS, Cloud VPS chât lượng tại đây
Auto Scale và Load Balancer
Tại sao lại cần đến Auto Scale và Load Balancer cho ứng dụng của bọn? Lấy ví dụ như thế này nhé:
Giả sử trong mùa nhập học mới và các tân sinh viên có nhu cầu tìm phòng trọ cao và họ bắt đầu truy cập với lưu lượng request là cực lớn vào hệ thống. Và nếu hệ thống không có giải pháp để cân bằng tải lưu lượng đó dẫn đến việc Server bị treo và chết. Và việc cấp 1 Server có sức chịu tải lớn thì điều đó là lãng phí tài nguyên của Server khi lượng Request ít.
Do đó ở đây mình đã đưa ra giải pháp cho team là sử dụng Kubernetes để giải quết vấn đề trên (Mình sẽ có bài hướng dẫn các bạn sử dụng nó sau). Lúc đầu mình sử dụng service của Azure do Microsoft cung cấp là: Azure Kubernetes Service (AKS) nhưng do hết kinh phí nên mình chuyển qua dùng của DegitalOcean.
Khi số lượng truy cấp quá lớn thì hệ thống sẽ tư động điều phối và tăng số lượng các Pod hoặc các Node để cân bằng tải cho server. Pod và Node ở đây hiểu đơn giản là các App và Server con. Và khi số lượng các request ít đi sẽ chúng sẽ tự hủy để tiết kiệm tài nguyên cho Server.
Do nó là một Horizontal Scale nên khả năng mở rộng gần như là vô hạn.
Docker
Khi mình làm về phần Deployment cho toàn bộ hệ thống của bọn mình thì mìn đã có 1 ý tưởng đó là sẽ cài trực tiếp tất cả các môi trường liên quan lên cùng con Server. VD như cài: Node JS, MongoDB, Redis, SQL Server…
Và điều đó là phải trả giá khi mình gặp nhiều khó khăn và thậm trí mình đã Destroy Server rất nhiều lần do hắn chết (kiểu như gây lỗi HĐH á). Mố số vấn đề mình gặp phải khi cài bằng cách này như:
-
Việc cài đặt mât thời gian rất nhiều thời gian và công sức.
-
Khả năng tương thích kém và sự phụ thuộc vào HĐH. VD nếu có 1 bản update mới của ứng dụng chúng ta sẽ phải kiểm tra tính tương thích của nó với HĐH hiện tại
-
Khác nhau về các môi trường. Về vấn đề này. Nếu như team có them 1 developer mới team sẽ phải chắc chắn rằng developer đó đang dung đúng các môi trường Dev/Test/Production của team. Đôi khi nó mỗi bản sẽ chạy trên các HĐH khác nhau.
Để giải quyết các vấn đề trên mình sử dụng Docker làm môi trường chính cho toàn bộ hệ thống.
Docker giúp việc build, deploy và run và stop các Service và các Tools, Database của bọn mình trở nên cực kìa dễ dàng và từ đó trong mình bừng nắng hạ.
Xem cách cài Docker trên Ubuntu tại đây
CI/CD
Nếu bạn đang muốn trở thành một DevOps với lương 5-6 ngàn Donald Trump thì chắc hẳn các bạn sẽ phải biết đến CI/CD. Nói đơn giản CI/CD là việc tự đông Build, Deploy, Test.
Thông thường khi các bạn Deploy một ứng dụng lên Server thì các bạn phải làm bằng tay. Nhưng với quy trình CI/CD thì không. Nó sẽ tự động làm cho bạn. Cụ thể trong dự án của bọn mình như sau:
Do thành viên các services khác nhau và do mình đảm nhiệm phần deploy nên nếu các thành viên trong team cùng code xong các service và muốn deploy bản mới nhất để cho tester test thì mình sẽ phải deploy bằng tay từng service 1 và báo lại sau khi deploy xong. Điều đó là rất mất thời gian.
Vì vậy đó bọn mình sử dụng CI/CD để tự động hóa việc build và deploy các service cụ thể ở đây mình sử dụng Jenkins (sẽ có bài viết riêng hướng dẫn nhé).
Quy trình làm việc CI/CD của bọn mình gồm các bước sau:
-
Khi Developer code xong module của mình và bản code đó được merge vào nhánh develop hoặc main trên GitLab
-
Jenkins sẽ lắng nghe các thay đổi từ repo thông qua webhook của gitlab.
-
Sau đó tự động Build và Test. Nếu quá trình Build + Test hoàn thành sẽ Push Image bản mới nhất lên Docker Hub và Server sẽ Pull Image mới nhát về Deploy lên các server được chỉ định.
-
Khi có bất cứ lỗi nào sảy ra thì việc Jenkins sẽ tự động dừng lại và không thực hiện Build bản code đó lên Production. Đông thời sẽ thông báo Email về cho các thành viên trong Team biết.
Ví dụ các bản build của bọn mình khi sử dụng JenkinsCI
Monitoring
Monitoring là gì? Tại sao lại cần đến Monitoring?
Monitoring là việc giám sát hệ thống của ứng dụng như xem số lượng Request, Log Bug, Kiểm soát RAM, CPU ... Nó cực kỳ quan trọng và cần thiết đối với một ứng dụng lớn đặc biệt là các ứng dụng sử dụng Microservices. Hầu hết các doanh nghiệp đề sử dụng Monitoring để giám sát hệ thống của mình.
Trong đồ án của mình, minh cũng đã sử dụng Monitoring để giám sát các Services, Database, Search Engine... Cụ thể ở đây bọn mình sử dung Promethues và Grafana là 2 công cụ chính. Ngoài ra còn một số các open-source khác như: cAdvisor, Telegraf, InfluxDB, và các Exporter của Grafana.
Đây là flow của hệ thống Monitoring của bọn mình nhé:
Trước tiên thì Promethues sẽ Pull các thông số từ Server, Database lưu dưới dạng metrics. Đối với các Back End thì mình sử dụng Telegraf + Influxdb để Pull các metric. Tiếp đó Grafana sẽ lấy các data từ Promethues và view lên Dashboard. Mọi dữ liệu được lấy gần như là realtime.
Một vài hình ảnh về hệ thống Monitoring:
Portainer
Do có nhiều Container nên việc quản lý chúng bằng Bash Script là rất khó và hay bị rối. Vì vậy mình sử dụng Portainer để quản lý các Container của Docker. Tool này cực kỳ hữu ích nha các bạn.
Phần Deployment này rất hay nên mình sẽ cố gắng chia sẻ hết các kiến thức này ở các bài viết sau. Đảm bảo các bạn cũng sẽ làm được. Vì vậy nhớ theo dõi mình nha 😋
Testing
Về phần testing bọn mình sử dụng Manual Test và Automation Test.
- Manual Test: Viết test case bằng tay. Phần này cực lắm 🙄
- Automation Test: Sử dụng XUnit kết hợp với Jenkins để thực hiện Test tự động.
Source Control
Bọn mình sử dụng GitLab để quản lý Source Code và các tài liệu liên quan.
Mô hình quản lý
Bọn mình sử dụng mô hình cổ điển là Waterfall để đạt được một sản phẩm mục tiêu cuối cùng một cách rõ ràng, hạn chế những thay đổi trong quá trình phát triển (CR), Vì đối với bản chất của đồ án này một thay nhỏ về Business dẫn đến tốn rát nhiều effort để hoàn thành tài liệu.
Tuy nhiên bọn mình áp dụng thêm một số best practice của mô hình quản lí Agile như: triển khai các buổi daily standup.
Nhiều bạn trong chúng ta, đa phần đã đi thực tập, chắc chắn đã ít nhất trải qua ác mộng khi làm việc với 1 dự án k có quản lí tốt. dẫn đến những lỗi lặp đi lặp lại. Chính vì áp dụng daily standup trong mỗi sprint vowis độ dài 1 đến 2 tuàn, bọn e dễ dàng đưa mọi người vào khuôn khổ. Trong buổi họp chúng e sẽ demo với mentor sản phẩn mình đã làm đc, Review quá trình vf rút kinh nghiệm để tranh những lỗi lặp đi lặp lại, sau đó có thể rút bài học cho sprint tiếp theo (Nguyên văn của bạn Tín 😆)
Quá trình làm đồ án
Thời gian bọn mình bắt đầu start là mùng 6 tết nguyên đán năm 2022. Với thời gian gấp gáp, đầu tháng 5 bọn mình nộp báo cáo và bảo vệ đồ án thì thật sự ai cũng lo lắng. Hình như chỗ này sai sai 😂. Đúng rồi! Sai thật rồi. Mình chẳng hề lo lắng chút nào và cả team mình cũng vậy.
Hồi bấy giờ có URF nên mình chơi game suôt cùng Tín và Hiếu. Thời gian mình bỏ ra để học công nghệ được giao chắc không bằng một trận game 😏 Do lúc bấy giờ đang dãn cách xã hội do Covid nên mỗi lần báo cáo tiến độ cho thầy mình toàn báo láo 😶(Nếu thầy đọc được thì đừng trách em nhá). Chắc chỉ có mỗi Hiền và Tín là làm phần việc của mình chứ mình với thằng cu Hiếu thì ....
Phải đến cuối tháng 1 mình mới bắt đầu học và làm các phần việc của mình. Do hồi đó mình vừa học vừa làm, sáng và chiều thì làm ở công ty nên thời gian mình học các công nghê kia là rất ít chắc chỉ được 1-2 tiếng mỗi tối. Và sau đó cả Team đã phải nghỉ làm để cày đồ án.
Bọn minh đã thức trắng đêm liên tục 3 tuần liên tiếp. Ngày nào cũng họp và làm cùng nhau tới 3-4h sáng. Có những hôm mình làm tới tận 10h sáng hôm sau 😂 Căng thật sự. Có những lúc thầy mình còn tuyệt vọng không tin tưởng bọn mình nữa và tính cho out. Vì Team mình cũng thuộc hạng TOP toàn trâu bò nên thầy kiểu thất vọng tràn trền và No Hope với Team.
Nhưng bằng tất cả lỗ lực thì tụi mình cũng hoàn thành xuất sắc. Đến bây giờ mình vẫn không tin là chỉ với 2 tháng bọn mình có thể làm xong, thầy mình cũng vậy. Nói là 2 tháng vì đúng thật là mấy tháng đầu bọn mình toàn chơi thôi.
Kinh Nghiêm
Sau tất cả những trải nghiệm quên ăn mất ngủ với đồ án mình có rút ra được một vài kinh nghiêm sương máu như sau:
Lựa chọn đề tài sớm nhất có thể
Việc lựa chọn đề tài càng sớm sẽ giúp cho bạn càng có nhiều thời gian hơn chuẩn bị. Thời gian xử lý đề tài thường là 6 tháng nhưng lại sát với kì nghỉ tết. Nhiều người nghĩ rằng qua tết mới bắt tay vào lựa chọn đề tài thì quả là sai lầm, nó sẽ ảnh hưởng tới kết quả vì thời gian quá gấp rút. Tốt nhất là bạn hãy lựa chọn ngay từ học kỳ 1 của năm cuối.
Đặt tên chi tiết đề tài
Khi đã xác định được hướng đi cho đề tài và bổ sung kiến thức cần thiết, hãy tiến hành lựa chọn tên chi tiết cho đề tài. Bạn hãy nhớ chọn một cách cẩn thận tuyệt đối không được đến gần lúc thực hiện đồ án đó lại đổi ý.
Khi đặt tên cho đề án hãy chọn cách viết ngắn gọn, súc tích, dễ hiểu, đồng thời phải bám sát với nội dung của đề tài. Bạn cần tránh một số lỗi như: Tên một đằng nhưng nội dung lại một nẻo, cẩn trọng với những khái niệm mới dễ gây tranh cãi, tốt nhất không nên đưa vào tên đề tài.
Chọn một Mentor có tâm
Thật sự nếu không có phần thúc đẩy và đưa ra một vài giải pháp cứu cánh cho bọn mình của thầy Long thì chắc bọn mình đã phải bảo vệ lại rồi.
Lựa chọn các Công Nghệ phù hợp
Với mình mà nói cái này khá quan trọng. Nếu các bạn vẽ ra một Scope quá lớn và công nghệ nào cũng muốn đưa vào thì khả năng cháy là rất cao. Phải biết lựa chọn công nghệ phù hợp và không quá sức với bản thân mình và các thành viên trong team. Mình đã gặp khá nhiều trường hợp nhờ mình Code và đưa ra Solution cho vấn đề này rồi nên các bạn cần cân nhắc kỹ.
Học thêm các kiến thức mới
Vâng. Cái này thì sẽ còn tùy vào độ chịu chơi và khả năng học hỏi của các bạn. Nhưng mình khuyên các bạn nên học thêm các kiến thức mới để áp dụng cho đồ án của mình đừng chỉ bó buộc trong các kiến thức đã học.
Việc áp dụng các kiến thức mới, công nghệ với vào đồ án sẽ làm cho đồ án của bạn trở lên Pro hơn, hội đồng chấm cũng đánh giá cao hơn. Và các nhà tuyển dụng sẽ để ý đến bạn hơn từ đó cơ hội việc làm của bạn tại các công ty lớn cũng cao hơn.
Nghiêm túc khi làm
Cái này bản thân mình đã rút ra được. Bạn thực sự phải nghiêm túc với nó vì nếu không thì đồ án chắc chắn bay màu. Mình cũng suýt bị vậy.
Kết Luận
Vậy là các bạn đã cùng mình đi qua sơ lược về đồ án cuối kỳ của mình rồi. Thật sự đó là một kỳ đồ án đáng nhớ.
Sau tất cả mình xin cám ơn các đồng đội và đặc biệt là thầy Nguyễn Xuân Long - Giảng viên ĐH FPT Đà Nẵng đã hướng dẫn tụi em trong quá trình làm đồ án. Cám ơn các bạn đã đọc bài viết này.
#P/S: Slide đồ án mình để ở cuối bài. Các bạn cần tham khảo thì Download về nhé! À các bạn cần Support Đồ Án hoặc làm Website cá nhân liên hệ mình nhá 😁 Liên hệ tại đây
#Note: Tất cả các kiến thức trên mình sẽ chia sẻ trên Website tại các bài viết sau các bạn nhớ theo dõi nhé!
