Middleware là những đoạn mã trung gian nằm giữa các request và response. Nó nhận các request, thi hành các mệnh lệnh tương ứng trên request đó. Sau khi hoàn thành nó response (trả về) hoặc chuyển kết quả ủy thác cho một Middleware khác trong hàng đợi.
Ứng dụng Middleware là gì?
Hiện nay các Web Framework tân tiến đều sử dụng nó như là một phần của ứng dụng để kết nối các phần khác lại với nhau. Đối với các ứng dụng web, việc sử dụng Middleware một cách hiệu quả giúp chúng ta có thể tối giản được số lượng dòng code phải viết trong ứng dụng.
Một ví dụ phổ biến mà chúng ta thường phải dùng Middleware đó là các trang chỉ dành riêng cho admin và không cho phép người dùng bình thường có thể truy cập.
Với tư tưởng chung là cầu nối giữa tương tác của người dùng và hệ thống trong lập trình Web. Middleware sẽ đóng vai trò trung gian giữa request/response và các xử lý logic bên trong web server.
Do đó, Middleware trong các Framework cho ứng dụng Web (Laravel, Django, Rails, ExpressJS…), sẽ là các hàm được dùng để tiền xử lý, lọc các request trước khi đưa vào xử lý logic hoặc điều chỉnh các response trước khi gửi về cho người dùng.
Hiểu các khái niệm cơ bản của Laravel Middleware
Trong bài viết này, mình sẽ lấy ví dụ là dùng framework Laravel để hiểu khái niệm về middleware. Chúng ta sẽ xem xét cách tạo middleware tùy chỉnh trong một ứng dụng Laravel.
Sau khi tạo middleware tùy chỉnh của bạn, chúng ta sẽ khám phá các tùy chọn có sẵn để đăng ký nó với Laravel để nó có thể thực sự được gọi trong luồng xử lý yêu cầu.
Middleware trong Laravel là gì?
Middleware như là một cơ chế cho phép bạn tham gia vào luồng xử lý request của một ứng dụng Laravel. Trong một quá trình xử lý route điển hình của Laravel khi thực thi việc xử lý yêu cầu và middleware là một trong những class mà ứng dụng phải thông qua.
Vậy chính xác thì việc xử lý luồng yêu cầu Laravel là gì? Ví dụ: cần xác thực người dùng để quyết định xem họ có được phép truy cập đến route hiện tại hay không.
Yêu cầu đăng nhập
Chuyển hướng người dùng
Thay đổi/chuẩn hoá các tham số
Xử lý response được ứng dụng Laravel tạo ra
…
Thực tế, Laravel mặc định đã có sẵn một số middleware quan trọng. Việc xác thực người dùng cũng được chính middleware này thực thi.
Chúng ta sẽ tự tạo ra một middleware tùy biến trong phần này. Như đã nói ở trên, Laravel có sẵn các middleware quan trọng, tuy nhiên để đáp ứng thêm nhu cầu thì chúng ta cần phảo tạo thêm nhiều middleware khác. Nhưng chính xác thì middleware này sẽ làm gì?
Case study cụ thể nhất mà thực tiễn nhất là khi chúng ta truy cập trang web từ bất kỳ thiết bị di động nào, thì sẽ được chuyển hướng đến URL miền phụ tương ứng (vd: m.topdev.vn khi ta vào topdev.vn trên mobile) dành cho mobile với tất cả thông số chuỗi truy vấn còn nguyên vẹn. Tất nhiên bây giờ đã có responsive nhưng đôi khi một phiên bản mobile tinh gọn và tốc độ nhanh sẽ có những tác dụng hay ho khác
Trong middleware tùy chỉnh này, chúng ta sẽ kiểm tra user agent và user được chuyển hướng đến URL tương ứng trên di động nếu họ đang sử dụng thiết bị di động.
Chạy lệnh sau để tạo một template middleware MobileRedirect.
php artisan make:middleware MobileRedirect
Và bạn sẽ tạo ra một file app/Http/Middleware/MobileRedirect.php với code sau.
<?php
namespace App\Http\Middleware;
use Closure;
class MobileRedirect
{
/**
* Handle an incoming request.
*
* @param \Illuminate\Http\Request $request
* @param \Closure $next
* @return mixed
*/
public function handle($request, Closure $next)
{
return $next($request);
}
}
Việc triển khai của method handle dựa trên khung sườn của middleware, và logic chính của middleware mà bạn đang tìm cách triển khai nằm ở đây.
Có 2 loại middleware mà Laravel đang có — before middleware và after middleware.
Before middleware chạy trước khi yêu cầu thực sự được xử lý và phản hồi được tạo ra. Mặt khác, after middleware chạy sau khi yêu cầu được ứng dụng xử lý và phản hồi đã được xây dựng tại thời điểm này.
Trong trường hợp này, chúng ta cần chuyển hướng người dùng trước khi yêu cầu được xử lý và do đó nó sẽ được phát triển như một before middleware.
Tiếp tục chỉnh sửa file app/Http/Middleware/MobileRedirect.php với các nội dung sau.
<?php
namespace App\Http\Middleware;
use Closure;
class MobileRedirect
{
/**
* Handle an incoming request.
*
* @param \Illuminate\Http\Request $request
* @param \Closure $next
* @return mixed
*/
public function handle($request, Closure $next)
{
// check nếu request từ thiết bị di động
if ($request->mobile == "1") {
return redirect('mobile-site-url');
}
return $next($request);
}
}
Chúng ta sẽ kiểm tra sự tồn tại của tham số mobile và nếu có giá trị TRUE, người dùng sẽ được chuyển hướng đến URL trên thiết bị di động. Lúc này bạn cần sử dụng một thư viên phát hiện user agent để lấy thông tin user ở client.
Tiếp tục ta sẽ gọi $next($request) giúp yêu cầu được xử lý thêm. Điều quan trọng cần lưu ý trong trường hợp này là chúng ta đã thiết lập logic phát hiện thiết bị di động trước khi gọi $next($request), và nó trở thành before middleware.
Sau đó chúng ta tạo một after middleware để xử lý các yêu cầu trên.
<?php
namespace App\Http\Middleware;
use Closure;
class CustomMiddleWare
{
/**
* Handle an incoming request.
*
* @param \Illuminate\Http\Request $request
* @param \Closure $next
* @return mixed
*/
public function handle($request, Closure $next)
{
$response = $next($request);
/* Viết logic code ở đây nha */
return $response;
}
}
Lúc này, middleware tùy chỉnh của chúng ta gần như đã sẵn sàng để được test thử. Bạn cần phải đăng ký middleware của bạn trong Laravel. Ta mở file app/Http/Kernel.php
/**
* The application's global HTTP middleware stack.
*
* These middleware are run during every request to your application.
*
* @var array
*/
protected $middleware = [
\Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode::class,
\Illuminate\Foundation\Http\Middleware\ValidatePostSize::class,
\App\Http\Middleware\TrimStrings::class,
\Illuminate\Foundation\Http\Middleware\ConvertEmptyStringsToNull::class,
];
Chúng tha thêm middleware tùy chỉnh của mình vào mảng trên sau:
Sau khi thêm vào, chúng ta thử truy cập vào bất kỳ route nào của Laravel bằng chuỗi truy vấn mobile=1 và xem kết quả, lúc này coi như chúng ta đã đăng ký thành công middleware do mình tạo. Đôi khi bạn chỉ muốn chạy middleware cho các route xác định hãy sử dụng $routeMiddleware.
Trong thời đại công nghệ ngày nay, việc quản lý và triển khai các ứng dụng phức tạp trên môi trường đám mây đã trở thành một thách thức lớn đối với các doanh nghiệp và nhà phát triển. Để đáp ứng nhu cầu này, nhiều công cụ và nền tảng đã ra đời, nhưng không gì nổi bật và phổ biến hơn Kubernetes. Được phát triển bởi Google và hiện nay là một dự án mã nguồn mở được cộng đồng quốc tế đón nhận rộng rãi, Kubernetes đã trở thành tiêu chuẩn vàng cho việc quản lý container. Vậy Kubernetes là gì? Nó hoạt động như thế nào để giúp các tổ chức đơn giản hóa việc quản lý hạ tầng ứng dụng? Hãy cùng chúng tôi khám phá trong bài viết này.
Kubernetes là gì?
Kubernetes (k8s) là một nền tảng mã nguồn mở tự động hoá việc quản lý, scaling và triển khai ứng dụng dưới dạng container hay còn gọi là Container orchestration engine. Nó loại bỏ rất nhiều các quy trình thủ công liên quan đến việc triển khai và mở rộng các containerized applications.
Gần đây, nhiều ứng dụng đã thực hiện container hoá bằng cách sử dụng docker và sử dụng nó như là môi trường production ngày càng tăng. Trên môi trường production, Vì việc cấu trúc hệ thống chạy bằng container chỉ sử dụng docker là rất khó khăn. Cho nên việc sử dụng một nền tảng Container orchestration engine như là k8s thì khá phổ biến hiện nay.
Kubernetes orchestration cho phép bạn xây dựng các dịch vụ ứng dụng mở rộng nhiều containers. Nó lên lịch các containers đó trên một cụm, mở rộng các containers và quản lý tình trạng của các containers theo thời gian.
Các ứng dụng production thực tế mở rộng nhiều containers. Các containers đó phải được triển khai trên nhiều server hosts. Kubernetes cung cấp khả năng phối hợp và quản lý cần thiết để triển khai các containers theo quy mô cho các workloads đó.
Kubernetes ban đầu được phát triển và thiết kế bởi các kỹ sư tại Google. Đây cũng là công nghệ đằng sau các dịch vụ đám mây của Google. Google đã và đang tạo ra hơn 2 tỷ container deployments mỗi tuần và tất cả đều được hỗ trợ bởi nền tảng nội bộ: Borg.
Nên sử dụng Kubernetes khi nào?
Các doanh nghiệp lớn, có nhu cầu thực sự phải scaling hệ thống nhanh chóng, và đã sử dụng container (Docker).
Các dự án cần chạy >= 5 container cùng loại cho 1 dịch vụ. (Ví dụ dùng >=5 máy cùng để chạy code website TopDev).
Các startup tân tiến, chịu đầu tư vào công nghệ để dễ dàng auto scale về sau.
Kubernetes giải quyết vấn đề gì?
Bằng việc sử dụng docker, trên 1 host bạn có thể tạo ra nhiều container. Tuy nhiên nếu bạn có ý định sử dụng trên môi trường production thì phải bắt buộc phải nghĩ đến những vấn đề dưới đây:
Việc quản lý hàng loạt docker host
Container Scheduling
Rolling update
Scaling/Auto Scaling
Monitor vòng đời và tình trạng sống chết của container.
Self-hearing trong trường hợp có lỗi xãy ra. (Có khả năng phát hiện và tự correct lỗi)
Service discovery
Load balancing
Quản lý data, work node, log
Infrastructure as Code
Sự liên kết và mở rộng với các hệ thống khác
Bằng việc sử dụng một Container orchestration engine như K8s có thể giải quyết được nhưng vấn đề trên đây. Trong trường hợp không sử dụng k8s, Thì sẽ phải cần thiết tạo ra cơ chế tự động hoá cho những cái kể trên, như thế thì cực kỳ tốn thời gian và không khả thi.
K8s quản lý thực thi các container sử dụng YAML để viết các Manifest.
Kubernetes là gì?
Sau khái niệm kubernetes là gì chúng ta hãy đến với chức năng của nó. Kubernetes quản lý các docker host và cấu trúc container cluster. Ngoài ra, khi thực thi các container trên K8s, bằng cách thực hiện replicas (tạo ra nhiều container giống nhau) làm cho hệ thống có sức chịu lỗi cao và tự động thực hiện load balancing. Thông qua cơ chế load balancing, chúng ta có thể tăng giảm số lượng container replica (auto scaling).
Khi thực hiện phân chia container vào các Node (docker host), dựa trên các loại docker host kiểu như “Disk SSD” hay “số lượng clock của CPU cao”… Hoặc dựa trên loại Workload kiểu như “Disk I/O quá nhiều”, “Băng thông đến một container chỉ định quá nhiều” … K8s sẽ ý thức được việc affinity hay anti-affinity và thực hiện Scheduling một cách hợp lý cho chúng ta.
Trong trường hợp không được chỉ định host cụ thể, K8s sẽ thực hiện scheduling tuỳ thuộc vào tình trạng CPU, memmory của docker host có trống hay không. Vì vậy, chúng ta không cần quan tâm đến việc quản lý bố trí container vào các docker host như thế nào.
Hơn nữa, trường hợp resource không đủ, thì việc auto scheduling của K8s cluster cũng sẽ được thực hiện tự động.
Được xây dựng theo quan điểm tính chịu lỗi cao, K8s thực hiện monitor các container theo tiêu chuẩn. Trong trường hợp bất ngờ nào đó, khi một container process bị dừng, K8s sẽ thực hiện Self-hearing bằng cách scheduling một container nữa.
Self-hearing là một khái niệm cự kỳ quan trọng trong k8s, nếu trường hợp có một node nào đó trong cluster xảy ra vấn đề ví dụ có thể là bị die, hay node đó được di chuyển đi. Cơ chế self-hearing sẽ tự động phục hồi mà không ảnh hưởng đến service.
Thêm nữa, ngoài việc monitor hệ thống, k8s còn có khả năng thiết lập health check bằng HTTP/TCP script.
Trường hợp sau khi auto scaling, phát sinh một vấn đề của endpoint đến container. Trong trường hợp sử dụng máy ảo, bằng việc setting load balancing endpoint sẽ được sử dụng như một VIP.
K8s cũng có một chức năng tương tự như vậy đó là Service. Service của k8s cung cấp chức năng load balancing cho hàng loạt các container được chỉ định. Việc tự động thêm, xoá container thời điểm scale là điều hiển nhiên, khi một container xảy ra sự cố thì tự động cách ly.
Khi thực hiện rolling update container thì việc đầu tiên k8s sẽ làm là cách ly container cho chúng ta, vì vậy k8s có thể đảm nhận việc quản lý các endpoint ở mức SLA cao.
Trong trường hợp cấu trúc một hệ thống sử dụng docker, nên phân tách nhỏ các chức năng trong kiến trúc Microservice.
Trong kiến trúc Microservice, để sử dụng các image container được tạo ra tương ứng với từng chức năng và deploy chúng thì chức năng Service discovery thực sự cần thiết.
K8s là một Platform nhưng có khả năng liên kết tốt với các hệ sinh thái bên ngoài, có nhiều middleware chạy trên các service của k8s, trong tương lai chắc chắn sẽ còn nhiều hơn nữa.
Ansible: Deploy container tới Kubernetes
Apache Ignite: Sử dụng Service Discovery của Kubernetes, tự động tạo và scaling k8s clkuster
Fluentd: gửi log của container trong Kubernetes
Jenkins: Deploy container đến Kubernetes
OpenStack：Cấu trúc k8s liên kết với Cloud
Prometheus: Monitor Kubernetes
Spark: Thực thi native job trên Kubernetes(thay thế cho YARN)
Spinnaker：Deploy container đến Kubernetes
Thêm nữa, K8s chuẩn bị một vài cơ thế để có thể mở rộng, thực thi chức năng độc lập, nó có thể sử dụng platform như là một framework. Bằng cách sử dụng khả năng mở rộng, chúng ta có thể thực hiện release một ReplicaSet mà k8s cung cấp.
Là server điều khiển các máy Worker chạy ứng dụng. Master node bao gồm 4 thành phần chính:
Kubernetes API Server: là thành phần giúp các thành phần khác liên lạc nói chuyện với nhau. Lập trình viên khi triển khai ứng dụng sẽ gọi API Kubernetes API Server này.
Scheduler: Thành phần này lập lịch triển khai cho các ứng dụng, ưng dụng được đặt vào Worker nào để chạy
Controler Manager: Thành phần đảm nhiệm phần quản lý các Worker, kiểm tra các Worker sống hay chết, đảm nhận việc nhân bản ứng dụng…
Etcd: Đây là cơ sở dữ liệu của Kubernetes, tất cả các thông tin của Kubernetes được lưu trữ cố định vào đây.
Worker node
Là server chạy ứng dụng trên đó. Bao gồm 3 thành phần chính:
Container runtime: Là thành phần giúp chạy các ứng dụng dưới dạng Container. Thông thường người ta sử dụng Docker.
Kubelet: đây là thành phần giao tiếp với Kubernetes API Server, và cũng quản lý các container
Kubernetes Service Proxy: Thành phần này đảm nhận việc phân tải giữa các ứng dụng
kubectl
Tool quản trị Kubernetes, được cài đặt trên các máy trạm, cho phép các lập trình viên đẩy các ứng dụng mô tả triển khai vào cụm Kubernetes, cũng như là cho phép các quản trị viên có thể quản trị được cụm Kubernetes.
Pod
Pod là khái niệm cơ bản và quan trọng nhất trên Kubernetes. Bản thân Pod có thể chứa 1 hoặc nhiều hơn 1 container. Pod chính là nơi ứng dụng được chạy trong đó. Pod là các tiến trình nằm trên các Worker Node. Bản thân Pod có tài nguyên riêng về file system, cpu, ram, volumes, địa chỉ network…
Image
Là phần mềm chạy ứng dụng đã được gói lại thành một chương trình để có thể chạy dưới dạng container. Các Pod sẽ sử dụng các Image để chạy.
Các Image này thông thường quản lý ở một nơi lưu trữ tập trung, ví dụ chúng ta có Docker Hub là nơi chứa Images của nhiều ứng dụng phổ biến như nginx, mysql, wordpress…
Deployment
Là cách thức để giúp triển khai, cập nhật, quản trị Pod.
Replicas Controller
Là thành phần quản trị bản sao của Pod, giúp nhân bản hoặc giảm số lượng Pod.
Service
Là phần mạng (network) của Kubernetes giúp cho các Pod gọi nhau ổn định hơn, hoặc để Load Balancing giữa nhiều bản sao của Pod, và có thể dùng để dẫn traffic từ người dùng vào ứng dụng (Pod), giúp người dùng có thể sử dụng được ứng dụng.
Label
Label ra đời để phân loại và quản lý Pod,. Ví dụ chúng ta có thể đánh nhãn các Pod chạy ở theo chức năng frontend, backend, chạy ở môi trường dev, qc, uat, production…
Thực hành Kubernetes
Phần thực hành sẽ giúp luyện tập với những khái niệm cơ bản ở phía trên của Kubernetes. Nội dùng phần này bao gồm việc cài đặt cụm Kubernetes gồm Master và Node thông qua Minikube.
Việc triển khai ứng dụng vào Kubernetes thông qua Deployment, sử dụng Service để giúp người dùng truy cập ứng dụng từ bên ngoài vào trong Kubernetes, và các thao tác quản trị như tăng giảm số bản sao của ứng dụng cũng như cập nhật phiên bản của ứng dụng.
Cài đặt Kubernetes bằng Minikube
Trong bài viết này, chúng tôi sử dụng chương trình Minikube, là chương trình thiết kế để giúp cho người mới tiếp cận được những khái niệm cơ bản nhất của Kubernetes. Minikube không được sử dụng cho môi trường chạy sản phẩm thật.
Ở trên đây là những khái niệm cơ bản nhất chúng tôi muốn đưa vào để giới thiệu cho bạn đọc. Kubernetes còn nhiều những khái niệm khác, dần dần chúng ta sẽ làm quen với các khái niệm này sau. Đây là link để các bạn follow cài đặt và chạy thử: https://kubernetes.io/docs/tutorials/hello-minikube/
Hiện nay các AWS, Azure hay Google Cloud cũng đang sử dụng rộng rãi Kubernetes vì tính ưu việt của nó, còn bạn đã thử chưa?
Setup và triển khai ứng dụng lên một hoặc nhiều server thực sự rất vất vả. Bạn phải cài đặt các công cụ và môi trường cần thiết cho ứng dụng, rồi đảm bảo ứng dụng chạy được. Chưa kể đến việc các môi trường trên nhiều server khác nhau thường không đồng nhất, dẫn đến nhiều rắc rối hơn. Docker là một công cụ mạnh mẽ ra đời giúp đơn giản hóa quá trình phát triển và triển khai phần mềm. Dưới đây là bài viết giới thiệu Docker là gì và các kiến thức cơ bản về Docker.
Docker là gì?
Docker là một nền tảng phần mềm giúp bạn building, deploying và running ứng dụng dễ dàng hơn bằng cách sử dụng các containers (trên nền tảng ảo hóa).
Ban đầu Docker được viết bằng Python, hiện tại đã chuyển sang Golang.
Docker đóng gói phần mềm thành các container tiêu chuẩn hóa, chứa đựng tất cả những thứ cần thiết để phần mềm hoạt động như thư viện, công cụ hệ thống, mã nguồn và thời gian chạy. Khi cần deploy app lên bất kỳ server nào, bạn chỉ cần run container của Docker thì app của bạn sẽ được khởi chạy ngay lập tức.
Khi sử dụng Docker, bạn có thể dễ dàng triển khai và mở rộng quy mô ứng dụng trong bất kỳ môi trường nào, đồng thời đảm bảo rằng mã nguồn của bạn sẽ luôn chạy được một cách ổn định.
Container là các gói phần mềm nhỏ gọn chứa tất cả các thành phần cần thiết của một ứng dụng như mã nguồn, thư viện, và các công cụ, giúp đảm bảo ứng dụng có thể chạy đồng nhất trên mọi môi trường.
Bằng cách đó, nhờ vào container, ứng dụng sẽ chạy trên mọi máy Linux khác bất kể mọi cài đặt tùy chỉnh mà máy có thể khác với máy được sử dụng để viết code.
Tại sao nên dùng Docker?
Theo một cách nào đó, Docker khá giống virtual machine. Nhưng tại sao Docker lại phát triển, phổ biến nhanh chóng? Đây là những nguyên nhân:
Tính dễ ứng dụng: Docker rất dễ cho mọi người sử dụng từ lập trình viên, sys admin… nó tận dụng lợi thế của container để build, test nhanh chóng. Có thể đóng gói ứng dụng trên laptop của họ và chạy trên public cloud, private cloud… Câu thần chú là “Build once, run anywhere”.
Tốc độ: Docker container rất nhẹ và nhanh, bạn có thể tạo và chạy docker container trong vài giây.
Môi trường chạy và khả năng mở rộng: Bạn có thể chia nhỏ những chức năng của ứng dụng thành các container riêng lẻ. Ví dụng Database chạy trên một container và Redis cache có thể chạy trên một container khác trong khi ứng dụng Node.js lại chạy trên một cái khác nữa. Với Docker, rất dễ để liên kết các container với nhau để tạo thành một ứng dụng, làm cho nó dễ dàng scale, update các thành phần độc lập với nhau.
Hiệu suất cao: Docker containers chia sẻ cùng một hệ điều hành kernel, giúp giảm thiểu tài nguyên hệ thống so với các máy ảo (VMs), dẫn đến hiệu suất cao hơn và chi phí thấp hơn.
Quản lý phụ thuộc dễ dàng: Docker giúp quản lý tất cả các phụ thuộc của ứng dụng trong một container, đảm bảo rằng không có sự mâu thuẫn phiên bản giữa các thư viện và công cụ.
Với xu hướng dịch chuyển sang microservices của các hệ thống lớn, Docker đang làm một thành phần cực kỳ quan trọng, làm cho nó trở thành một phần của nhiều công cụ DevOps. Hiện tại thế giới bắt đầu sử dụng thêm một công cụ quản lý container tiên tiến khác là Kubernetes (Đọc thêm bài Kubernetes là gì?)
Chọn bản cài đặt tương ứng với hệ điều hành của bạn và tiến hành cài đặt theo hướng dẫn đối với Linux còn Windows và MacOS thì bạn chỉ cần tải bản cài về và cài đặt như mọi application khác.
Xem video hướng dẫn cài đặt Docker:
Sau khi cài đặt xong để kiểm tra xem cài đặt thành công hay không?
Mở command line:
$ docker version$ docker info$ docker run hello-world
Các khái niệm liên quan
Docker là gì
Docker Engine : là thành phần chính của Docker, như một công cụ để đóng gói ứng dụng
Docker Hub : là một “github for docker images”. Trên DockerHub có hàng ngàn public images được tạo bởi cộng đồng cho phép bạn dễ dàng tìm thấy những image mà bạn cần. Và chỉ cần pull về và sử dụng với một số config mà bạn mong muốn.
Container: là một instance của một image. Bạn có thể create, start, stop, move or delete container dựa trên Docker API hoặc Docker CLI.
Docker Client: là một công cụ giúp người dùng giao tiếp với Docker host.
Docker Daemon: lắng nghe các yêu cầu từ Docker Client để quản lý các đối tượng như Container, Image, Network và Volumes thông qua REST API. Các Docker Daemon cũng giao tiếp với nhau để quản lý các Docker Service.
Dockerfile: là một tập tin bao gồm các chỉ dẫn để build một image .
Docker Volumes: là phần dữ liệu được tạo ra khi container được khởi tạo.
Docker Repository: là tập hợp các Docker Images cùng tên nhưng khác tags. VD: golang:1.11-alpine.
Docker Networking: cho phép kết nối các container lại với nhau. Kết nối này có thể trên 1 host hoặc nhiều host.
Docker Compose: là công cụ cho phép run app với nhiều Docker containers 1 cách dễ dàng hơn. Docker Compose cho phép bạn config các command trong file docker-compose.yml để sử dụng lại. Có sẵn khi cài Docker.
Docker Swarm: để phối hợp triển khai container.
Docker Services: là các containers trong production. 1 service chỉ run 1 image nhưng nó mã hoá cách thức để run image — sử dụng port nào, bao nhiêu bản sao container run để service có hiệu năng cần thiết và ngay lập tức.
Trên đây là những khái niệm cơ bản nhất về Docker. Ngoài ra còn nhiều khái niệm nữa như swarm, compose…
Có một vài khái niệm cần đào sâu hơn đó là Docker Images và Dockerfile
Docker Images
Docker image là một thành phần quan trọng trong hệ thống Docker, đóng vai trò như một mẫu chuẩn chứa tất cả các thành phần cần thiết để chạy ứng dụng. Cụ thể, một Docker image bao gồm mã nguồn, các thư viện, phụ thuộc và các cấu hình cần thiết cho ứng dụng. Nói cách khác, image là một tập hợp các file hệ thống và file thực thi được gói gọn lại để có thể chạy trong môi trường cô lập của Docker. Các đặc điểm chính của Docker Image:
Đọc Chỉ (Read-Only): Docker image là không thể thay đổi. Khi bạn khởi tạo một container từ một image, Docker sẽ tạo một lớp ghi đè (write layer) lên lớp image chỉ đọc đó.
Tầng (Layers): Một Docker image được xây dựng từ nhiều tầng khác nhau. Mỗi thay đổi trong Dockerfile (cấu hình cho image) tạo ra một tầng mới. Tầng này giúp tiết kiệm dung lượng và tối ưu hóa, bởi nếu nhiều container cùng sử dụng một image, các tầng giống nhau chỉ cần lưu trữ một lần.
Môi trường nhất quán: Docker image đảm bảo rằng ứng dụng sẽ chạy chính xác trong mọi môi trường, từ phát triển đến sản xuất, bởi tất cả phụ thuộc của ứng dụng đều được gói gọn trong image.
Một image sẽ được build dựa trên những chỉ dẫn của Dockerfile.
Dockerfile
Dockerfile là file config cho Docker để build ra image. Nó dùng một image cơ bản để xây dựng lớp image ban đầu. Một số image cơ bản: python, unbutu and alpine. Sau đó nếu có các lớp bổ sung thì nó được xếp chồng lên lớp cơ bản. Cuối cùng một lớp mỏng có thể được xếp chồng lên nhau trên các lớp khác trước đó.
Các config:
FROM — chỉ định image gốc: python, unbutu, alpine…
LABEL — cung cấp metadata cho image. Có thể sử dụng để add thông tin maintainer. Để xem các label của images, dùng lệnh docker inspect.
ENV — thiết lập một biến môi trường.
RUN — Có thể tạo một lệnh khi build image. Được sử dụng để cài đặt các package vào container.
COPY — Sao chép các file và thư mục vào container.
ADD — Sao chép các file và thư mục vào container.
CMD — Cung cấp một lệnh và đối số cho container thực thi. Các tham số có thể được ghi đè và chỉ có một CMD.
WORKDIR — Thiết lập thư mục đang làm việc cho các chỉ thị khác như: RUN, CMD, ENTRYPOINT, COPY, ADD,…
ARG — Định nghĩa giá trị biến được dùng trong lúc build image.
ENTRYPOINT — cung cấp lệnh và đối số cho một container thực thi.
EXPOSE — khai báo port lắng nghe của image.
VOLUME — tạo một điểm gắn thư mục để truy cập và lưu trữ data.
Tạo Demo
Tạo file Dockerfile
FROM golang:1.11 AS builderWORKDIR /go/src/docker-demo/COPY . .RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o docker-demo .FROM alpine:latestWORKDIR /root/COPY — from=builder /go/src/docker-demo .CMD [“./docker-demo”]
Kết quả in ra dòng chữ Learning Docker đã được code trong file main.go
Quy trình thực thi của một hệ thống sử dụng Docker
Như trong hình vẽ, một hệ thống Docker được thực thi với 3 bước chính :
Build -> Push -> Pull,Run
Build
Đầu tiên tạo một dockerfile, trong dockerfile này chính là code của chúng ta. Dockerfile này sẽ được Build tại một máy tính đã cài đặt Docker Engine. Sau khi build ta sẽ có được Container, trong Container này chứa ứng dụng kèm bộ thư viện của chúng ta.
Push
Sau khi có được Container, chúng ta thực hiện push Container này lên cloud và lưu tại đó.
Pull, Run
Nếu một máy tính khác muốn sử dụng Container chúng ta thì bắt buộc máy phải thực hiện việc Pull container này về máy, tất nhiên máy này cũng phải cài Docker Engine. Sau đó thực hiện Run Container này.
Khi xây dựng ứng dụng và cần scale một cách linh hoạt.
Khi bạn muốn không tốn khá nhiều thời gian để config máy local và server cùng một môi trường để chạy được ứng dụng. Bạn chỉ cần build 1 lần chạy ở nhiều nơi mà thôi.
Sản phẩm của công ty bạn cần một cách tiếp cận mới về xây dựng, đẩy lên server, thực thi ứng dụng một cách nhanh chóng dễ dàng.
Lần lượt hé lộ hàng trăm diễn giả mỗi năm, VMD2019 có gì đặc biệt với nhóm speaker về tech đầu tiên của chương trình? Cùng điểm qua 5 chuyên gia đứng sau những công nghệ đang dẫn đầu thị trường nhé:
Anh Vương Hoàng Kim | Head of Products – YOOSE
Topics: “How small mobile applications with the use of AI / Data projects can help big problems. A Vietnam Case Study”
Góc nhìn trực quan về công nghệ được chia sẻ bởi một chuyên gia kinh tế là việc mà anh Vương Hoàng Kim sẽ thực hiện tại VMD2019. Với kinh nghiệm trong các lĩnh vực Inventory Procurement, Scrum Product Owner, anh Kim sẽ chia sẻ những nội dung xoay quanh việc sử dụng mobile app và AI / Data projects để giải quyết các vấn đề công nghệ. Quả là một topic thú vị và mới lạ phải không các bạn?
Anh Đặng Ngọc Quảng | Tech Lead – Arrow Technologies & Technical Special tại GDG Hà Nội
Topic “Firebase and Android Architecture Components: fit like a glove”
Anh Đặng Ngọc Quảng – chuyên gia công nghệ đến từ Arrow Technologies và GDG sẽ đem đến VND2019 những nội dung hấp dẫn xoay quanh chủ đề đang được nhiều tín đồ công nghệ quan tâm nhất hiện nay: Làm sao kết hợp Firebase và Android Architecture Components một cách tối ưu nhất?
Mr. Kelvin Teo | Co-founder – Funding Societies | Modalku
“Future of Fintech & Mobile Payment: Disruptive Technologies and the Evolvement of the Banking Industry”
Tốt nghiệp Trường Kinh Doanh Harvard và Đại học Quốc Gia Singapore, anh Kelvin Teo thường được mời diễn thuyết tại các hội thảo lớn như ASEAN Capital Markets Conference, LendIt Shanghai, and Money2020 Singapore. Cùng chờ xem nội dung chia sẻ đến từ một trong Top 200 Fintech influencers của Châu Á có những gì thú vị các bạn nhé!!
Anh Nguyễn Quang Nhật | Android Team Lead – ALAX VN
Topics: Future of mobile technology
Với gần 10 năm kinh nghiệm trong lĩnh vực Native Mobile Development với cả 2 nền tảng iOS và Android cũng như thành thạo trong nhiều lĩnh vực khác nhau như full-stack technology, Software Architecture & Development Life, anh Nhật sẽ giúp các bạn đón đầu những xu thế về mobile technology đang làm mưa làm gió trên thế giới hiện nay qua những nội dung chuyên sâu cùng ví dụ thực tiễn.
Anh Bùi Xuân Yên | Lead Software Engineer and Head of Technology Research – Adbrix
Topics: What you have believed to be Analytics was merely a report : Introducing True Marketing Analytics
Góp mặt trong lĩnh vực marketing không thể thiếu chuyên gia Bùi Xuân Yên đến từ adbrix. Những số liệu cụ thể và chính xác sẽ được chia sẻ tại VMD2019 bởi chuyên gia hàng đầu trong lĩnh vực mạng cảm biến (sensor networks), giao thức Internet (Internet Protocols) và mạng di động (mobile networks). Nếu bạn là những nhà phân tích đang tìm kiếm sự đổi mới cho doanh nghiệp, bạn chắc chắn sẽ không muốn bỏ lỡ phần chia sẻ của anh Yên!!
5 chuyên gia trên đây đã đủ khiến bạn có hứng thú tham gia sự kiện vào tháng 6 sắp tới chưa? Nhanh tay đăng ký để giữ ngay cho mình 1 slot tham gia Vietnam Mobile Day cùng hơn 100 diễn giả “chất lừ” của chúng tôi nhé!
CODE giảm 30% vé tham dự cho độc giả: TOPDEVBLOG@VMD19
1 hệ thống cũng giống như thời tiết xấu vậy. Nó không thể đoán trước và cũng không thể tránh khỏi. Và điều quan trọng nhất đối với 1 software engineer là lập kế hoạch và giải quyết các vấn đề lỗi đó.
Trong bài viết này, mình sẽ giới thiệu cho các bạn 1 kĩ thuật có độ tin tưởng khá cao, hạn chế gây ra lỗi hệ thống mà các kĩ sư Grab đang dùng. Đó là kĩ thuật Circuit Breaker (Dịch sang tiếng việt nghĩa là bộ ngắt mạch, mình thì hay gọi nó là cái cầu giao).
Hiện tại, Grab đang sử dụng cơ chế Circuit Breaker trong toàn bộ hệ thống của họ. Để đảm bảo rằng khi có sự cố xảy ra đi chăng nữa thì service vẫn không bị chết, và vẫn tiếp tục phục vụ request của người dùng.
Đây có lẽ là điều mà nhiều engineer đang muốn biết phải không nào? Vậy hãy cùng đi xem cơ chế Circuit Breaker là gì? Và nó được áp dụng trong hệ thống của Grab như thế nào nhé.
Nguyên nhân gây ra lỗi hệ thống
Trước tiên chúng ta hãy thử xem xét đâu là nguyên nhân thường xuyên gây ra lỗi nhé.
Do service hay phải truyền thông với các tài nguyên bên ngoài, nên về cơ bản, thì lỗi có thể là do:
Vấn đề về mạng
Quá tải hệ thống
Cạn kiệt tài nguyên (ví dụ như out of memory …)
Cấu hình, deploy lỗi
Bad request (ví dụ như missing request data …)
Vậy khi có lỗi xảy ra, làm thế nào để tiếp tục xử lý được request thì chúng ta xem tiếp phần tiếp theo nhé.
Điện nhà bạn đã bao giờ tự nhiên đang dùng thì bị ngắt cầu giao chưa? Ví dụ như vừa bật nồi lẩu, vừa cắm nồi cơm, vừa bật máy giặt thì quá tải, cầu giao bị ngắt. Và cả nhà tối om như mực.
Thế nhưng điều đó ít nhiều vẫn còn an toàn hơn việc nhà không có cầu giao. Nếu không có cầu giao thì điều gì sẽ xảy ra?
Dùng quá tải, không có bộ phận ngắt điện kịp thời sẽ đẫn đến cháy nổ ở bộ phận nào đó trong nhà, gây chập điện… Khá là nguy hiểm.
Cơ chế Circuit Breaker mà Grab áp dụng trong hệ thống cũng hoạt động theo cách tương tự.
Circuit Breaker sẽ nằm giữa 2 đoạn code, và theo dõi luồng dữ liệu chảy qua nó. Tuy nhiên thay vì ngắt điện khi có sự cố, thì nó sẽ block request lại.
Để dễ hiểu hơn, các bạn có thể xem hình bên dưới:
Đầu tiên, “Main” (để dễ hiểu có thể coi nó như người dùng) sẽ call đến Circuit Breaker (cái này cũng nằm trong code của service). Sau đó từ Circuit Breaker sẽ gửi 1 request đến Upstream Service (Có thể hiểu nó như là 1 api server).
Khi đó Upstream Service sẽ xử lí request và trả về response đến Circuit Breaker. Nếu response đó không có lỗi gì thì sẽ được trả lại ngay “Main”.
Điều gì xảy ra nếu như Upstream Service bị lỗi?
Nếu có lỗi xảy ra phía Upstream Service thì nó sẽ trả về lỗi cho Circuit Breaker,và Circuit Breakersẽ trả lại lỗi cho Main.
Nhìn vào đây chắc hẳn các bạn cũng đang nghĩ: cho thằng Circuit Breaker vào giữa này chưa thấy có ưu điểm gì?
Vậy để mình giải thích nhé.
Giả sử như có 1000 request gửi đến Circuit Breaker và nó đang nhận được cả 1000 response lỗi từ Upstream Service.
Circuit Breaker sẽ ở giữa monitor những request đó và tracking xem có bao nhiêu request thành công và bao nhiêu request thất bại.
Nếu như số lượng request thất bại vượt qúa số lượng cho phép, khi đó nó sẽ phán đoán Upstream Service đang có vấn đề. Và nó sẽ ngắt mạch lại. Không cho request chảy sang bên Upstream Service nữa.
Ở trong trạng thái đó mà có gửi request sang đi chăng nữa thì response bạn nhận được cũng bị timeout hoặc lại càng làm cho Upstream Service “gánh tạ” nhiều hơn mà thôi.
Và flow bây giờ sẽ thành thế này:
Đến đây chắc các bạn cũng hình dung được phần nào ý nghĩa của thằng Circuit Breaker đúng không ạ?
Nhưng mà cũng có người đang thắc mắc, nếu cứ trả về lỗi như thế thì nó không có ý nghĩa gì cho người dùng lắm.
Ví dụ như mình muốn tìm kiếm xem từ điểm A đến điểm B sẽ đi mất bao lâu. Nhưng mà server của Grab lại toàn trả về lỗi. Khi đó bạn có suy nghĩ gì về trải nghiệm người dùng? Chắc chắn là không tốt rồi.
Chúng ta cùng đi xem tiếp xem Grab đã xử lý trường hợp này như thế nào nhé?
Fallback processing (xử lý dự phòng)
Để giải quyết bài toán này, Circuit Breaker đã định nghĩa ra 1 tính năng gọi là Fallback processing. Chúng ta cùng đi xem flow bên dưới xem nó hoạt động thế nào nhé.
Giả sử như các bạn đang xây dựng 1 chương trình tính khoảng cách giữa 2 điểm. Chúng ta gọi service đó là “distance calculator service”.
Nếu như service hoạt động bình thường, khi đó nó sẽ trả về cho chúng ta khoảng cách giữa 2 điểm.
Tuy nhiên, nếu “distance calculator service” đang quá tải, không thể xử lý thêm request.
Khi đó, Circuit Breakersẽ thực hiện fallback processing request của người dùng và thực hiện tính toán thay cho “distance calculator service” bằng việc sử dụng hàm lượng giác tính toán đơn giản.
Đương nhiên là tính toán khoảng cách sử dụng cách này sẽ không cho kết quả chính xác. Nhưng bằng cách này đã giúp Grab xử lý yêu cẩu của khách hàng tốt hơn rất nhiều so với việc không trả về kết quả gì.
Trong hình thức fallback processing, thì ví dụ mình đưa ra bên trên chỉ là 1 cách thôi. Ngoài ra còn 1 số cách khác nữa. Ví dụ như:
Retries request đến 1 con upstream service khác
Lưu request đó vào queue và sẽ xử lý lại vào thời gian khác.
Tuy nhiên, có 1 số trường hợp thì sử dụng fallback processing vẫn không hợp lý. Nhưng ít nhiều trong những hoàn cảnh như này, thì việc sử dụng 1 Circuit Breaker vẫn là có lợi.
Circuit Breaker có nên tracking mọi error?
Câu trả lời ngắn gọn là không.
Grab chỉ tracking những lỗi không phải do người dùng, mà do phía infrastructure hoặc network (Ví dụ với HTTP error code là 503 hoặc 500).
(Lỗi người dùng là lỗi thế nào? Chủ yếu là lỗi có HTTP error code là 400 hoặc 401.)
Lí do mà Grab không tracking lỗi do người dùng là do nếu như có phần tử hacker nào đó. Họ cố tình gửi thật nhiều request lỗi (ví dụ request thiếu parameter) đến Circuit Breaker. Khi đó Circuit Breakersẽ tự động ngắt mạch kết nối đến Upstream Service, và dẫn đến service bị down và không xử lý request của người khác được nữa.
Phục hồi Circuit Breaker như thế nào?
Sau khi Circuit Breakerđã ngắt mạch kết nối để không gửi request đến Upstream Service nữa. Vậy khi nào Circuit Breakersẽ thực hiện đóng mạch lại và tiếp tục gửi request đến Upstream Service?
Câu trả lời rất đơn giản. Nó sẽ đợi sau 1 thời gian nào đó (ví dụ như 1 phút), Grab gọi nó là Sleep Window.
Rồi sẽ test lại mạch bằng cách gửi 1 vài request nào đó đến Upstream Service. Nếu như nhận được response OK, khi đó nó sẽ tiến hành đóng mạch và cho hệ thống hoạt động như bình thường.
Nếu như vẫn bị lỗi, thì nó lại tiếp tục lặp lại quá trình trên cho đến khi ok thì thôi.
Bulwark (tường thành)
Grab đang sử dụng 1 thư viện có tên là Hystrix-Go để implement Circuit Breaker.Và trong thư viện này có bao gồm 1 chức năng khá quan trọng đó là Bulwark (bức tường thành).
Bulwark có nhiệm vụ sẽ monitor toàn bộ các request đến đồng thời được gửi đến Circuit Breaker và nó sẽ block nếu như số lượng request đồng thời vượt quá số lượng cho phép.
Hình thức này người ta hay gọi là rate-limiting.
Tại sao nó quan trọng? Như mình đã nói ở trên, 1 trong những lý do khiến service của bạn bị down đó là do nhận quá nhiều request cùng 1 lúc.
Chẳng hạn như service của bạn chỉ xử lý được 1000 request đồng thời. Nếu như có hacker nào đó thực hiện DDos service của bạn bằng cách gửi 1 triệu request cùng 1 lúc đến server của bạn. Mình khẳng định service của bạn sẽ bị down và ko thể làm việc tiếp được.
Đó là lí do tại sao mà Bulwark đã được tích hợp vào Hystrix-Go.
Implement Circuit Breaker
Hiện tại Grab đang sử dụng Hystrix-Go để implement thằng Circuit Breaker. Và thằng Hystrix-Go này có 1 vài setting chính mà mọi người nên để ý:
1. Timeout
Là khoảng thời gian tối đa thực hiện request.
2. Max Concurrent Requests (số request đồng thời lớn nhất)
Đây chính là phần Bulwark mà mình đã đề cập ở bên trên.
Giá trị mặc định của nó là 10. Nhưng chú ý là hằng số này không phải biểu thị “per second” đâu nhé. Vì có thể số request đồng thời nó gửi quá nhanh, chỉ tính bằng mili second chẳng hạn.
Nếu giá trị này quá lớn sẽ khiến service của bạn không đủ tài nguyên để xử lý.
3. Sleep Window
Đây là khoảng thời gian mà Circuit Breaker sẽ đợi trước khi nó gửi request đến Upstream Service để check xem đã hoạt động bình thường hay chưa.
Nếu cái này đặt quá thấp sẽ không có hiệu quả vì Circuit Breaker sẽ phải open/check thường xuyên. Còn nếu nó đặt quá cao thì sẽ hạn chế thời gian phục hồi.
4. Error Percent Threshold
Đây là giá trị biểu thị tỉ lệ phần trăm số request thất bại trước khi bị ngắt mạch.
Và còn rất nhiều các setting nữa, các bạn tự tìm hiểu ở trên trang chủ Hystricx-Go nhé.
Kết luận
Đến đây chắc các bạn cũng biết được cách xây dựng 1 Circuit Breaker là như nào, và nó có tác dụng gì cho hệ thống.
Xây dựng xong hệ thống là 1 chuyện, nhưng để hệ thống “không chết” là 1 chuyện hoàn toàn khác.
Hi vọng qua bài này sẽ cung cấp cho các bạn chút về kĩ thuật Circuit Breaker và solution trong việc thiết kế hệ thống có tính availability cao.
Design pattern là các giải pháp tổng thể đã được tối ưu hóa, được tái sử dụng cho các vấn đề phổ biến trong thiết kế phần mềm mà chúng ta thường gặp phải hàng ngày. Đây là tập các giải pháp đã được suy nghĩ, đã giải quyết trong tình huống cụ thể.
Design pattern có tác dụng gì?
Những lập trình viên có thể áp dụng giải pháp này để giải quyết các vấn đề tương tự. Các vấn đề mà bạn gặp phải có thể bạn sẽ tự nghĩ ra cách giải quyết nhưng có thể nó chưa phải là tối ưu.
Bạn cần phải hiểu rõ nó không phải là ngôn ngữ cụ thể nào cả. Design patterns có thể thực hiện được ở phần lớn các ngôn ngữ lập trình. Nó giúp bạn giải quyết vấn đề một cách tối ưu nhất, cung cấp cho bạn các giải pháp trong lập trình hướng đối tượng (OOP).
Giúp sản phẩm của chúng ta linh hoạt, dễ dàng thay đổi và bảo trì hơn.
Có một điều luôn xảy ra trong phát triển phần mềm, đó là sự thay đổi về yêu cầu. Lúc này hệ thống phình to, các tính năng mới được thêm vào trong khi performance cần được tối ưu hơn.
Design pattern cung cấp những giải pháp đã được tối ưu hóa, đã được kiểm chứng để giải quyết các vấn đề trong software engineering. Các giải pháp ở dạng tổng quát, giúp tăng tốc độ phát triển phần mềm bằng cách đưa ra các mô hình test, mô hình phát triển đã qua kiểm nghiệm.
Những lúc khi bạn gặp bất kỳ khó khăn đối với những vấn đề đã được giải quyết rồi, design patterns là hướng đi giúp bạn giải quyết vấn đề thay vì tự tìm kiếm giải pháp tốn kém thời gian.
Giúp cho các lập trình viên có thể hiểu code của người khác một cách nhanh chóng (có thể hiểu là các mối quan hệ giữa các module chẳng hạn). Mọi thành viên trong team có thể dễ dàng trao đổi với nhau để cùng xây dựng dự án mà không tốn nhiều thời gian.
Khi nào nên sử dụng Design pattern?
Việc sử dụng các design pattern sẽ giúp chúng ta giảm được thời gian và công sức suy nghĩ ra các cách giải quyết cho những vấn đề đã có lời giải. Lợi ích của việc sử dụng các mô hình Design Pattern vào phần mềm đó chính là giúp chương trình chạy uyển chuyển hơn, dễ dàng quản lý tiến trình hoạt động, dễ nâng cấp bảo trì, …
Tuy nhiên điểm bất cập của design pattern là nó luôn là một lĩnh vực khá khó nhằn và hơi trừu tượng. Khi bạn viết code mới từ đầu, khá dễ dàng để nhận ra sự cần thiết phải có mẫu thiết kế. Tuy nhiên, việc áp dụng mẫu thiết kế cho code cũ thì khó khăn hơn.
Khi sử dụng những mẫu design pattern có sẵn thì chúng ta sẽ đối mặt với một vấn đề nữa là perfomance của product (code sẽ chạy chậm chẳng hạn). Cần phải chắc chắn là bạn đã hiểu toàn bộ mã nguồn làm việc như thế nào trước khi đụng vào nó. Việc này có thể là dễ dàng hoặc là đau thương, phụ thuộc vào độ phức tạp của code.
Hiện nay chúng ta đang áp dụng rất nhiều design pattern vào công việc lập trình của mình. Nếu bạn thường tải và cài đặt các thư viện, packages hoặc module nào đó thì đó là lúc bạn thực thi một design pattern vào hệ thống.
Tất cả các framework cho ứng dụng web như Laravel, Codeigniter… đều có sử dụng những kiến trúc design pattern có sẵn và mỗi framework sẽ có những kiểu design pattern riêng.
Web server là máy chủ cài đặt các chương trình phục vụ các ứng dụng web. Webserver có khả năng tiếp nhận request từ các trình duyệt web và gửi phản hồi đến client thông qua giao thức HTTP hoặc các giao thức khác. Có nhiều web server khác nhau như: Apache, Nginx, IIS, … Web server thông dụng nhất hiện nay:
Web server hoạt động như thế nào?
Mô hình hoạt động cơ bản của 1 web server
Bất cứ khi nào bạn xem một trang web trên internet, có nghĩa là bạn đang yêu cầu trang đó từ một web server. Khi bạn nhập URL trên trình duyệt của mình (ví dụ: https://topdev.vn) nó sẽ tiến hành các bước sau để gửi lại phản hồi cho bạn.
1. Trình duyệt phân giải tên miền thành địa chỉ IP
Trình duyệt web của bạn trước tiên cần phải xác định địa chỉ IP nào mà tên miền topdev.vn trỏ về. Trình duyệt sẽ yêu cầu thông tin từ một hoặc nhiều máy chủ DNS (thông qua internet). Máy chủ DNS sẽ cho trình duyệt biết địa chỉ IP nào tên miền sẽ trỏ đến cũng là nơi đặt trang web.
Lúc này trình duyệt web đã biết địa chỉ IP của trang web, nó có thể yêu cầu URL đầy đủ từ webserver.
2. Webserver gửi lại client Trang được yêu cầu
Web server phản hồi bằng cách gửi lại những thông tin client yêu cầu… Nếu trang không tồn tại hoặc có lỗi khác xảy ra, nó sẽ gửi lại thông báo lỗi thích hợp.
3. Trình duyệt hiển thị trang web
Trình duyệt web của bạn nhận lại được các tập tin html css (nhiều file khác)… và render hiển thị trang theo yêu cầu.
Giới thiệu một số Web Server phổ biến
Apache HTTP server
Apache là web server được sử dụng rộng rãi nhất thế giới. Apache được phát triển và duy trì bởi một cộng đồng mã nguồn mở dưới sự bảo trợ của Apache Software Foundation. Apache được phát hành với giấy phép Apache License là được sử dụng tự do, miễn phí.
Tính đến tháng 8 năm 2018, apache ước tính phục vụ cho 54.2% các trang web đang hoạt động và 53.3% số máy chủ hàng đầu. Apache chạy trên các hệ điều hành như windows, linux, unix, MacOS ….
Nginx
Nginx là một web server nhẹ (Đọc thêm Nginx là gì), không chiếm nhiều tài nguyên của hệ thống. Nginx còn là một reserse proxy mã nguồn mở. Nginx khá là ổn định, cấu hình đơn giản và hiệu suất cao.
Nginx được phát triển bởi Igor Sesoev vào năm 2002 chủ yếu là để phục vụ cho website rambler.ru (trang web được truy cập nhiều thứ hai của nước Nga). Theo thống kê của Netcaft, trong một triệu website lớn nhất thế giới có 6.52% sử dụng Nginx.
Nginx là phần mềm mã nguồn mở và miễn phí, được phát hành rộng rãi theo giấy phép BSD. Nginx được phát triển bằng ngôn ngữ và chạy được trên các hệ điều hành như Linux, FreeBSD, Windows, MacOS…
Nginx có các tính năng như chứng thực người dùng, virtual hosting, hỗ trợ CGI, FCGI, SCGI, WCGI, SSI, ISAPI, HTTPS, Ipv6, …
Internet Information Services (IIS)
IIS do Microsoft phát triển, sản phẩm này được tích hợp cùng với hệ điều hành Windows Server. Trong IIS bao gồm nhiều dịch vụ như: dịch vụ Web Server, dịch vụ FTP Server. Tính đến thời điểm tháng 5 năm 2015 thì thì số lượng trang Web sử dụng máy chủ IIS gần 248 triệu trang web.
Tất cả các tính năng của web server được quản lí độc lập do đó chúng ta có thể dễ dàng thêm, loại bỏ hoặc thay thế các tính năng của web server.
Nhờ được tích hợp ASP.NET IIS có thể sử dụng toàn bộ sức mạnh của ASP.NET. Module ASP.NET làm cho máy chủ phát triển nhanh chóng nhờ vào giao diện quen thuộc và các dịch vụ ứng dụng của ASP.NET.
Apache Tomcat
Apache Tomcat là một Java Servlet được phát triển bởi Apache Software Foundation. Tomcat thực thi các ứng dụng Java Servlet và JavaServer Pages (JSP). Tomcat cung cấp một máy chủ HTTP cho ngôn ngữ Java thuần túy.
Apache Tomcat rất ổn định và có tất cả các tính năng của một ứng dụng web thương mại nhưng đi kèm theo giấy phép mã nguồn mở của Apache. Tomcat cũng cung cấp một số chức năng bổ sung như tomcat manager application, speciallized realm imlementation và tomcat valves.
Các phiên bản của apache tomcat trùng với phiên bản và đặc điểm kỹ thuật của servlet java hoặc java servlet API. Tomcat 5.5X hỗ trợ Servlet API 2.3, tomcat 6.0X hỗ trợ servlet API 2.4 và tomcat 7.0 hỗ trợ servlet API 3.0. Ngoài Servlet versions API, phiên bản tomcat hỗ trợ phiên bản JSP API tương ứng.
Apache Tomcat hỗ trợ các hệ điều hành như windows, linux, MacOS, BSD,…
Lighttpd
Lighttpd là một phần mềm mã nguồn mở, an toàn và linh hoạt, đặc biệt miễn phí và được phân phối theo giấy phép BSD. Lighttpd được viết bởi Jan Kneschke. Lighttpd chiếm ít tài nguyên, memory thấp, CPU nhỏ. Lighttpd được phát triển bằng ngôn ngữ C. chạy trên hệ điều hành Linux, Windows, Mac OS,…
SQL Injection là một kỹ thuật lợi dụng những lỗ hổng về câu truy vấn của các ứng dụng. Được thực hiện bằng cách chèn thêm một đoạn SQL để làm sai lệnh đi câu truy vấn ban đầu, từ đó có thể khai thác dữ liệu từ database. SQL injection có thể cho phép những kẻ tấn công thực hiện các thao tác như một người quản trị web, trên cơ sở dữ liệu của ứng dụng.
Ví dụ thực tiễn SQL Injection
Ví dụ, trong form đăng nhập, người dùng nhập dữ liệu, trong trường tìm kiếm người dùng nhập văn bản tìm kiếm, trong biểu mẫu lưu dữ liệu, người dùng nhập dữ liệu cần lưu. Tất cả các dữ liệu được chỉ định này đều đi vào cơ sở dữ liệu.
Thay vì nhập dữ liệu đúng, kẻ tấn công lợi dụng lỗ hổng để insert và thực thi các câu lệnh SQL bất hợp pháp để lấy dữ liệu của người dùng… SQL Injection được thực hiện với ngôn ngữ lập trình SQL. SQL (Structured Query Language) được sử dụng để quản lý dữ liệu được lưu trữ trong toàn bộ cơ sở dữ liệu.
Tuy nhiên ngày nay chứng ta thường làm việc trên những framework hiện đại. Các framework đều đã được test cẩn thận để phòng tránh các lỗi, trong đó có SQL Injection.
Sự nguy hiểm của SQL Injection
Hack tài khoản cá nhân.
Ăn cắp hoặc sao chép dữ liệu của trang web hoặc hệ thống.
Thay đổi dữ liệu nhạy cảm của hệ thống.
Xóa dữ liệu nhạy cảm và quan trọng của hệ thống.
Người dùng có thể đăng nhập vào ứng dụng với tư cách người dùng khác, ngay cả với tư cách quản trị viên.
Người dùng có thể xem thông tin cá nhân thuộc về những người dùng khác, ví dụ chi tiết hồ sơ của người dùng khác, chi tiết giao dịch của họ,…
Người dùng có thể sửa đổi cấu trúc của cơ sở dữ liệu, thậm chí xóa các bảng trong cơ sở dữ liệu ứng dụng.
Người dùng có thể kiểm soát máy chủ cơ sở dữ liệu và thực thi lệnh theo ý muốn.
Việc kiểm tra lỗ hổng này có thể được thực hiện rất dễ dàng. Đôi khi ta chỉ cần nhập ký hiệu ' hoặc " vào các trường được kiểm tra. Nếu nó trả về bất kỳ thông báo bất ngờ hoặc bất thường, thì ta có thể chắc chắn rằng SQL Injection khả thi cho trường đó.
Ví dụ: một Form đăng nhập như sau
Và đoạn code server xử lý của bạn:
if(isset($_POST['username']) && isset($_POST['password'])){
$sql = "SELECT * FROM tbl_user WHERE username='". $_POST['username'] . "' AND password = '" .$_POST['password'] ."'";
}
Nếu như người dùng không nhập bình thường nữa mà chẳng hạn như họ có thêm một dấu nháy ' hoặc " vào thì dòng code của bạn sẽ bị lỗi ngay. Hoặc họ có thể sửa thành một câu truy vấn luôn luôn đúng như sau.
SELECT * FROM tbl_user WHERE username = '' OR '1' = '1' and password = '' OR '1' = '1'
Hoặc chèn thêm một câu lệnh truy vấn phía sau:
VD:
SELECT * FROM tbl_user WHERE username = 'admin' and password = 'admin'; Drop table users;
Các phần dễ bị tấn công
Các phần dễ bị tấn công bao gồm:
Form đăng nhập
Form tìm kiếm
Form nhận xét
Bất kì trường lưu hoặc trường đầu vào của dữ liệu
Liên kết của website
Cần lưu ý là trong khi thử nghiệm chống lại tấn công này là không thể chỉ kiểm tra một hoặc một vài trường bởi vì một trường có thể được bảo vệ chống lại SQL Injection, nhưng một trường khác thì không. Do đó, điều quan trọng là đừng quên kiểm tra tất cả các trường của trang web.
Cách giảm thiểu và phòng ngừa SQL Injection
Luôn kiểm tra kỹ các trường nhập dữ liệu và các bạn cần ràng buộc thật kỹ dữ liệu người dùng nhập vào.
Ví dụ:
//Thông thường
$id = $_GET['id'];
//Ràng buộc
$id = isset($_GET['id'])?(string)(int)$_GET['id']:false;
Dùng Regular Expression để loại bỏ đi các ký tự lạ hoặc các ký tự không phải là số.
Hoặc dùng các hàm có sẵn để giảm thiểu lỗi. Mỗi khi truy vấn thì mọi người nên sử dụng thêm hàm mysqli_real_escape_string để chuyển đổi một chuỗi thành một query an toàn.
$id = isset($_GET['id'])?(string)(int)$_GET['id']:false;
$sql= 'SELECT * FROM tbl_user WHERE id= ' . mysqli_real_escape_string($id);
Và lời khuyên cuối cùng là chúng ta nên dùng các Framework và hạn chế dùng code thuần tối đa nếu có thể. Framework luôn có cộng đồng hoặc các chuyên gia bảo mật giúp tìm lỗi và update liên tục, từ đó chúng ta có thể giảm bớt thời gian xử lý lỗi để tăng thời gian làm sản phẩm cũng là một điều hay.
Các nhà marketer luôn thu thập và tìm kiếm dữ liệu hàng thập kỷ. Thế nhưng một vấn đề khác bên lề xuất hiện: khối lượng và sự đa dạng của dữ liệu nở rộ. Giờ đây dữ liệu không còn quá hiếm hay quá khó khăn để tìm kiếm. Dữ liệu xuất hiện ở bất kỳ đâu, thậm chí nhiều doanh nghiệp còn không thể theo kịp.
Cùng lúc đó, sự mong đợi của khách hàng lại càng tăng cao. Người tiêu dùng mong chờ sự liên quan mật thiết và các trải nghiệm hữu ích từ các nhãn hàng ở từng thời điểm nhỏ nhặt nhất trong quá trình mua hàng của mình.
Điều này thúc đẩy sự đổi mới trong chiến lược từ các doanh nghiệp. Giờ đây các nhãn hàng không thể ngồi im với hàng tá dữ liệu nữa, nếu không muốn đánh mất những vị khách thiếu kiên nhẫn (Theo khảo sát số người có trải nghiệm thương hiệu không tích cực sẽ giảm 62% khả năng mua hàng trong tương lai.) Hoặc tệ hơn, họ sẽ đuối sức trên trận chiến sinh tồn trong một thị trường luôn thay đổi.
Để sử dụng dữ liệu hiệu quả, bạn đã làm chủ được dữ liệu của mình chưa? Dữ liệu chính là nguồn tài nguyên mới. Nếu sở hữu hàng trăm triệu terabyte dữ liệu không được khai thác thì cũng không có công dụng gì.
Lúc này mới thấy được tầm quan trọng của việc xây dựng chiến lược dữ liệu. các nhà lãnh đạo phải áp dụng một bản kế hoạch mới để thu thập và quản lý dữ liệu cho phù hợp, từ đó bất kỳ ai cũng có thể truy cập và phân tích thông tin, tích hợp các các công nghệ để thực hiện các mong đợi của khán giả .
Tôn trọng dữ liệu
Đây là yêu cầu hàng đầu của một nhà marketer thực thụ. 56% các leader đạt mục tiêu trong năm ngoái sẽ đồng ý mạnh mẽ rằng các quyết định dựa trên data sẽ vượt trội hơn so với dựa trên bản năng hay kinh nghiệm.
Đối với các marketer đang “chiến đấu” với các thử thách mà dữ liệu mang lại, như thiếu sự tích hợp, trích xuất data từ kho thông tin khổng lồ, sẽ có những khó khăn và sai lầm trên hành trình này, nhưng từ đây sẽ xuất hiện những kinh nghiệm quý giá.
“Bạn không thể ngã dọc đường nếu sức đẩy không đủ mạnh”
Xây dựng chiến lược của riêng mình và chuẩn bị trước những trở ngại
Câu hỏi được đặt ra là làm thế nào để doanh nghiệp có thể phát triển chiến lược dữ liệu của riêng mình? Đây là cả một quá trình chứ không phải là cuộc chạy đua nước rút, một cuộc đua trải dài những rào cản về kỹ thuật và cả con người. song các doanh nghiệp cần có sự đầu tư về chiến lược mạnh mẽ và cơ sở độc quyền để có thể thấy được lợi ích về lâu dài.
Có “Ba cái thiếu” không nên bỏ qua.
Thiếu tự tin: câu chuyện về data rất khó kể và thực hiện, nhưng với sự trợ giúp của công nghệ, bạn đã thành công một nửa chặng đường.
Thiếu niềm tin. “Tại sao phải thử?” là câu hỏi muôn thuở. Thành công hay thất bại đề là bước đệm cho những vòng tiếp theo.
Thiếu thời gian: sử dụng data ngốn hết thời gian và công sức, và thời gian là vấn đề chung trong kinh doanh. Song những người không có thời gian thường bỏ lỡ những dữ liệu có giá trị nhất.
Lập kế hoạch hành động
Không chỉ riêng các leader mới có chiến lược phân tích dữ liệu, mà 33% các nhà marketer hàng đầu nhận định các chiến lược giúp xác định cách tích hợp dữ liệu và công nghệ liên quan.
Với nền tảng công nghệ cho phép nhìn thấy sự tham gia của người tiêu dùng từ đầu đến cuối, hiệu suất truyền thông có thể được đánh giá tốt hơn vì có thể truyền tải thông điệp phù hợp với người tiêu dùng dựa trên hành vi của họ. Khi các dữ liệu được sắp xếp logic, mong muốn thầm kín của người tiêu dùng có thể được khai thác từ đó điều chỉnh các kế hoạch để đáp ứng với nhu cầu của người tiêu dùng.
***
Tại nơi mà hành vi người tiêu dùng thay đổi xoành xoạch, cần những chiến lược dữ liệu tích hợp để tạo nên nền tảng vững chắc vượt qua những cuộc thay đổi địa chấn. IGAWorks, thành lập năm 2006, là công ty công nghệ – quảng cáo tích hợp (full stack ad-tech company) và nhóm các dịch vụ toàn cầu đi đầu trong các lĩnh vực digital marketing và mobile business. IGAWorks cung cấp các giải pháp bao gồm nền tảng marketing trên truyền thông toàn cầu dựa trên AI, dự đoán ROI cho các bước mobile marketing của khách hàng.
Là một phần của IGAWorks, adbrix là nền tảng dữ liệu di động thế hệ tiếp theo. Được đưa vào hoạt động từ 2014, adbrix là nền tảng marketing và đối tượng dữ liệu cho các marketing tăng trưởng của di động với 27.000 ứng dụng và hơn 1000 đối tác truyền thông toàn cầu. Là công cụ thân thiện với marketer, adbrix cung cấp phân tích dữ liệu người dùng thô không giới hạn và phân tích chúng. Thu thập và phân tích dữ liệu hiệu suất quảng cáo cùng với dữ liệu đối tượng để phân đoạn mức dữ liệu sâu hơn của riêng người dùng, từ đó có thể sử dụng ngay cho các kế hoạch marketing.
adbrix được sử dụng rộng rãi trên toàn cầu, hơn 50 tỷ lượt nhấp quảng cáo hàng tháng, 800 triệu thiết bị và doanh thu 8,2 tỷ đô la trong ứng dụng năm 2019. Cùng với giải pháp nhắm gửi tin nhắn đẩy đầu tiên trên thế giới – Growth Action sẽ cho phép các marketer:
Đo đường hiệu suất chiến dịch quảng cáo trên thiết bị theo các kênh truyền thông
Phân tích hành vi người dùng theo từng số liệu
Tối ưu hoá thực hiện ngân sách marketing bằng cách phân bố lại các phương tiện & nhắm mục tiêu người dùng trong bảng tuỳ chỉnh dashboard
Xác định và ngăn chặn lưu lượng truy cập lỗi
Hãy đưa ra quyết định khôn ngoan hơn dựa trên dữ liệu với adbrix và đưa sản phẩm của bạn lên tầm cao hơn!
Tháng 6 năm nay tại hai thành phố Hồ Chí Minh và Hà Nội, đội ngũ adbrix sẽ tham dự sự kiện Mobile lớn nhất Việt Nam: Vietnam Mobile Day 2019, hứa hẹn sẽ mang đến làn sóng Mobile Measurement hoàn toàn mới tới cộng đồng hội những người đam mê Kỹ thuật số ở Việt Nam. Đừng bỏ lỡ nhé!
Bài viết được sự cho phép của BBT Tạp chí Lập trình
Tóm tắt
Lập trình Cặp (Pair-Programming) là cách hai lập trình viên cùng làm việc trên chỉ một máy tính, một người lái (driver), một người làm hoa tiêu (navigator), thú vị hơn bạn tưởng tượng nhiều. Việc hoán đổi vai trò liên tục giúp cho giao tiếp thông suốt, họ cùng nhau hoàn thành công việc tốt hơn và nhanh hơn khi họ làm một mình.
Người lái tập trung vào sách lược – viết mã nguồn sạch có thể chạy được. Hoa tiêu tập trung và chiến lược – cách mã nguồn phù hợp với thiết kế chung, trường hợp kiểm thử nào sẽ “lái” mã nguồn đi đúng hướng và những tái cấu trúc nào sẽ cải thiện toàn bộ mã nguồn của chương trình.
Các cặp tự tổ chức thông qua việc chọn thành viên phù hợp nhất với tác vụ hiện thời. Trong mỗi cặp, việc hoán đổi vai trò được thực hiện sau vài tiếng để chia sẻ tầm nhìn và kiến thức.
Bài viết này được trích từ cuốn sách The Art of Agile Development (tạm dịch: Nghệ thuật Phát triển Phần mềm theo Phương pháp Linh hoạt) của tác giả James Shore và Shane Warden, được xuất bản bởi O’Reilly).
Lập trình cặp: Chúng ta giúp nhau thành công
Bạn có muốn ai đó ngồi nhìn bạn làm việc suốt ngày? Bạn có muốn phí một nửa thời gian chỉ ngồi im lìm ủ rũ xem người khác viết mã?
Tất nhiên là không. Chẳng có ai thích thế cả, đặc biệt là những người lập trình cặp.
Lập trình cặp là một trong những điều đáng chú ý đầu tiên của XP. Hai người làm việc trên chỉ một bàn phím? Thật kỳ lạ. Nhưng nó thực sự đem lại hiệu quả đáng kinh ngạc, và khi bạn đã quen thì sẽ có rất nhiều điều thú vị. Hầu như tất cả lập trình viên tôi biết, chỉ sau một tháng làm quen với lập trình cặp họ sẽ thấy thích lập trình cặp hơn làm một mình.
Tại sao cần lập trình cặp?
Chương này được đặt tên là Tư duy, và tôi giới thiệu lập trình cặp là phương pháp đầu tiên. Đó bởi vì lập trình cặp chính là để giúp bạn nghĩ tốt hơn, thông minh hơn.
Khi bạn lập trình cặp, một người viết mã (người lái). Người kia làm hoa tiêu có nhiệm vụ là ngẫm nghĩ. Khi làm hoa tiêu, đôi khi bạn nghĩ về điều người lái đang gõ (Nhưng đừng vội vàng chỉ trỏ những lỗi như kiểu thiếu dấu chấm phẩy, sẽ gây khó chịu). Đôi lúc bạn nghĩ về phần việc cần làm tiếp theo và đôi khi bạn nghĩ làm cách nào để phần đang được cài đặt đi đúng theo thiết kế tổng thể.
Việc chia ra hai vai trò như vậy giúp cho người lái tập trung vào từng dòng mã chuẩn cú pháp mà không phải lo về tổng thể chương trình, và giúp hoa tiêu có thời gian cân nhắc về hướng phát triển của chương trình mà không bị phân tâm về tiểu tiết mã nguồn cụ thể. Cùng nhau, người lái và hoa tiêu hoàn thành công việc với chất lượng cao hơn và nhanh hơn khi từng người làm việc riêng lẻ.
“Một nghiên cứu cho thấy rằng lập trình cặp tốn công sức hơn 15% so với lập trình một mình, nhưng nhanh tạo thành sản phẩm hơn
và ít lỗi hơn 15%
[Cockburn & Williams]. Tuy nhiên, mỗi đội mỗi khác nên kết quả thống kê trên chỉ nên dùng để tham khảo.“
Lập trình cặp còn củng cố những thói quen lập trình tốt. XP tin rằng việc kiểm thử liên tục và hoàn thiện thiết kế cần rất nhiều tính tự giác. Khi lập trình cặp, bạn sẽ có được sức ép tích cực từ bạn cặp để thực hiện những công việc khó khăn nhưng quan trọng trên. Bạn sẽ chia sẻ được kiến thức và thủ thuật lập trình cho toàn đội.
Bạn cũng sẽ có nhiều thời gian hơn ở trong luồng lập trình – trạng thái năng suất cao mà bạn hoàn toàn tập trung vào việc lập trình. Dù bạn làm việc cùng một người khác, nhưng luồng lập trình này vẫn bền vững và khó bị gián đoạn hơn khi lập trình một mình. Bởi đồng nghiệp sẽ ít làm phiền bạn hơn khi thấy bạn đang làm việc cùng người khác. Cho dù có bị làm gián đoạn, thì người cùng cặp sẽ giúp giải quyết vấn đề trong khi bạn vẫn tiếp tục dòng suy nghĩ của mình. Hơn nữa, khi bạn tập trung chú ý vào nói chuyện với người cùng cặp thì những tiếng ồn xung quanh sẽ tự động bị biến mất.
Nếu tất cả những điều trên chưa thuyết phục được bạn thử lập trình cặp, hãy tin tôi, lập trình cặp thực sự rất thú vị. Thêm một cái đầu sẽ giúp bạn vượt qua những vấn đề khó dễ dàng hơn nhiều. Nói chung, bạn sẽ luôn được làm việc với một đồng đội thông minh và cùng chí hướng. Thêm vào đó, nếu cổ tay bạn đau nhức do gõ quá nhiều, bạn có thể chuyển bàn phím cho đồng đội và tiếp tục làm việc không hề giảm năng suất.
Lập trình cặp như thế nào?
Tôi khuyến nghị lập trình cặp với tất cả mã nguồn sản xuất. Rất nhiều đội thực hiện lập trình cặp thường xuyên, nhưng không tuyệt đối, thấy rằng họ gặp nhiều lỗi hơn nếu lập trình đơn. Một nguyên tắc tốt là thực hiện lập trình cặp bất cứ phần nào mà bạn cần bảo trì kể cả kiểm thử và mã build ứng dụng.
Khi bạn bắt đầu làm một việc, hãy đề nghị một lập trình viên khác tham gia cùng. Nếu có ai đó đề nghị, hãy thoải mái đồng ý lập cặp cùng. Đừng bao giờ phân chia cố định các cặp, hãy lập cặp một cách tự nhiên, linh hoạt và luân chuyển các cặp trong ngày. Qua thời gian, một người sẽ lập trình cặp với tất cả mọi người trong đội. Điều này sẽ giúp cả đội gắn bó hơn và tất cả mọi người đều được chia sẻ kiến thức và các kĩ năng thiết kế.
“Có được bối cảnh tươi mới bằng cách luân chuyển cặp.”
Khi bạn cần một không khí tươi mới, hãy chuyển cặp. Tôi thường chuyển cặp khi cảm thấy chán nản hay bế tắc. Tuy nhiên luôn phải giữ lại một người đã theo phần việc từ đầu để có thể giúp người mới vào cặp nhanh chóng nắm bắt được vấn đề. Có nhiều lúc, chỉ cần giải thích vấn đề là gì cho người khác cũng giúp bạn giải quyết được vấn đề đó.
Trong lập trình cặp, dù bạn không thấy nản hay bế tắc, đổi cặp vài lần một ngày cũng tốt. Điều này sẽ giúp thông tin trong đội được thông suốt và mọi người sẽ làm việc hiệu quả hơn. Cá nhân tôi thì tôi chuyển cặp mỗi khi hoàn thành một phần việc. Nếu tôi làm một phần việc lớn, tôi chuyển cặp sau mỗi 4 tiếng.
Khi ngồi theo cặp, hãy chắc chắn rằng bạn cảm thấy thoải mái, không bị mỏi. Đặt ghế cạnh nhau, đảm bảo mỗi người có đủ khoảng trống, và có thể nhìn rõ màn hình. Khi làm người lái, hãy đặt bàn phím trước mặt bạn. Chú ý: mọi người khi lập trình theo cặp thường có xu hướng với tay đến bàn phím và chuột chứ không kéo chúng về gần (trước mặt) mình.
Những người lập trình cặp làm việc thông qua đối thoại. Dù bạn là người lái hay hoa tiêu , hãy nói tất cả những điều bạn nghĩ ra. Hãy làm từng bước thiết kế nhỏ, liên tục, tốt nhất là làm theo phát triển hướng kiểm thử và nói về những giả định của bạn, mục tiêu ngắn hạn, hướng phát triển chung, và bất kì vấn đề gì của tính năng đang cài đặt hoặc của toàn bộ dự án. Hãy hỏi khi bạn thấy mơ hồ về vấn đề gì đó. Việc thảo luận thường giúp cả bạn và người cùng cặp hiểu rõ vấn đề đó hơn.
“Khi bạn thấy một cặp có vẻ trầm (ít nói, nói nhỏ, hoặc không luân chuyển với các cặp khác) thì nó thường là dấu hiệu của khó khăn kỹ thuật.”
Bạn luôn cảm thấy mệt mỏi vào cuối ngày? Các cặp lập trình thường cảm thấy họ đã làm việc nhiều hơn và đạt hiệu quả cao hơn khi họ làm việc một mình. Hãy thực hành “Làm việc đầy năng lượng” (Energized work) để duy trì năng lượng làm việc mỗi ngày.
Lái và điều hướng
“Với thời gian làm việc theo cặp sẽ trở nên tự nhiên”
Khi mới bắt đầu, bạn sẽ cảm thấy vụng về khi làm người lái. Bạn cũng có thể cảm thấy người hoa tiêu nhìn nhận ra những ý tưởng và vấn đề nhanh hơn bạn rất nhiều. Quả thật như vậy, hoa tiêu có nhiều thời gian để nghĩ hơn người lái. Tình thế sẽ được đảo ngược khi bạn đổi vai trò, trở thành hoa tiêu. Dần dần việc làm cặp sẽ trở nên tự nhiên.
Khi điều hướng, bạn sẽ cảm thấy như muốn nhảy vào dành lấy bàn phím từ người cùng cặp. Hãy thư giãn, người lái của bạn sẽ thường đưa ra ý kiến bằng cả lời nói và mã nguồn. Người đó sẽ mắc những lỗi gõ sai hay những lỗi nhỏ, nhưng hãy cho anh ý chút thời gian để tự sửa lại. Hãy dùng trí lực của bạn để nghĩ về bức tranh lớn hơn. Những kiểm thử nào khác bạn cần phải viết? Làm thế nào để đoạn mã phù hợp với phần còn lại của hệ thống? Có sự trùng lặp nào cần loại bỏ không? Mã có thể rõ ràng hơn được không? Thiết kế tổng thể có thể được tốt hơn không?
Nhiệm vụ của hoa tiêu là giúp người lái làm việc hiệu quả hơn. Hãy nghĩ về những điều xảy ra tiếp theo và chuẩn bị những đề xuất. Khi tôi điều hướng, tôi thường giữ một thẻ chỉ mục trước mặt tôi. Thay vì làm gián đoạn người bạn cầm lái khi tôi nghĩ về một vấn đề, tôi viết những ý tưởng của tôi lên thẻ chỉ mục và chờ đến lúc nghỉ để thảo luận. Vào cuối phiên làm việc cặp, tôi xé tấm thẻ và bỏ nó đi.
Tương tự như vậy, khi một câu hỏi phát sinh, hãy dành một chút thời gian để tìm kiếm câu trả lời trong khi người lái đang làm việc. Một số nhóm dùng thêm máy tính sách tay cho mục đích này. Nếu bạn cần nhiều hơn một vài phút, hãy cùng người lái tìm kiếm giải pháp. Đôi khi cách tốt nhất để làm là tách riêng ra, tìm kiếm song song với nhau và thường xuyên chia sẻ với nhau những gì học được. Những khung giải pháp là một cách tiếp cận hiệu quả.
Khi ghép cặp, hãy thường xuyên chuyển đổi vai trò cho nhau ít nhất sau mỗi 30 phút, có thể là sau vài phút. Khi bạn điều hướng và thấy rằng cần bảo người lái phải bấm phím nào đó, hãy tự mình bấm luôn phím đó. Nếu khi lái bạn cần nghỉ ngơi một chút, hãy đưa bàn phím cho hoa tiêu.
Thủ thuật lập trình cặp
Làm việc theo cặp với bất cứ thứ gì bạn cần bảo trì
Hãy để các cặp hình thành tự nhiên hơn là bị gán cố định
Hãy chuyển đổi đối tác khi bạn cần một không khí tươi mới
Tránh cặp với cùng một người trong hơn một ngày
Ngồi thoải mái, cạnh nhau
Viết mã thông qua đối thoại. Hãy hợp tác chứ đừng chỉ trích
Người lái và hoa tiêu thường xuyên hoán đổi vai trò cho nhau
Không gian lập trình cặp
Để lập trình cặp thoải mái, không gian làm việc tốt là thiết yếu. Bạn cần nhiều không gian để hai người ngồi cạnh nhau được thoải mái. Những nơi làm việc ở góc phòng nhỏ điển hình sẽ không hiệu quả. Chúng không thoải mái và một người phải ngồi sau người kia, gây ra rào cản tâm lý cũng như vật lý ngăn cản sự cộng tác.
Bạn không cần đồ nội thất bóng bẩy để lập trình cặp tốt. Thứ tốt nhất tôi từng thấy chỉ là những chiếc bàn gấp đơn giản được tìm thấy tại bất kì cửa hàng đồ văn phòng tốt nào. Chúng nên dài khoảng 1,8 mét, để hai người có thể ngồi thoải mái cạnh nhau, và cao ít nhất 1,2 mét. Mỗi bàn cần một máy tính mạnh mẽ chuyên dùng cho lập trình. Mỗi máy tính nên có hai bộ bàn phím và chuột để tiện cho mỗi người trong cặp.
Nên có màn hình lớn để cả 2 người có thể nhìn thấy rõ ràng. Một số nhóm hiển thị lên hai màn hình giống nhau, giúp dễ nhìn hơn một chút, nhưng có thể làm bạn chỉ sai màn hình khi thảo luận với nhau. Một số nhóm khác lại thích hiển thị một màn hình desktop lên hai màn hình LCD.
Những thử thách khi lập trình cặp
Lập trình theo cặp ban đầu có thể không được thoải mái, bởi cách làm việc này yêu cầu bạn phải có tinh thần hợp tác nhiều hơn cách mà bạn quen làm. Điều này là tự nhiên và thường sẽ mất đi sau một hoặc hai tháng, nhưng bạn phải đối mặt với một vài thử thách.
Sự thoải mái
Hãy ghi nhớ rằng: lập trình cặp không vui chút nào nếu bạn không thoải mái. Khi bạn ngồi xuống làm việc, điều chỉnh vị trí và thiết bị sao cho bạn cảm thấy thoải mái. Dọn rác trên bàn làm việc và hãy chắc chắn có đủ không gian cho chân và đầu gối của bạn.
Một vài người (như tôi) cần rất nhiều không gian riêng. Những người khác lại thích ngồi gần hơn. Khi bạn bắt đầu ghép cặp, hãy thảo luận về nhu cầu không gian cá nhân của bạn và đối tác của bạn.
Tương tự như vậy, không thể không nhắc tới vấn đề vệ sinh cá nhân. Nhớ rằng những hương vị mạnh như cà phê, tỏi, hành, thức ăn cay có thể dẫn tới hơi thở hôi. Để tránh xảy ra rắc rối, hãy cùng nhau quyết định cách góp ý về những thói quen cá nhân một cách tôn trọng.
Chênh lệch về trình độ
Lập trình theo cặp thường là sự hợp tác giữa những người có trình độ tương đương nhau, nhưng thỉnh thoảng một lập trình viên cao cấp, nhiều kinh nghiệm sẽ cặp với một người ở trình độ thấp hơn. Thay vì xem mối quan hệ này như sinh viêngiáo viên, hãy lấy lại sự cân bằng ngang hàng bằng cách tạo ra cơ hội cho cả hai người để học tập. Ví dụ, nếu biết bạn được cặp với một lập trình viên còn non kém kinh nghiệm, bạn có thể đề nghị người đó nghiên cứu về một chủ đề mà không ai khác biết, chẳng hạn các công việc bên trong của một thư viện mà nhóm phụ thuộc vào. Hãy cho tất cả mọi người một cơ hội trở thành chuyên gia.
Phong cách giao tiếp
Những người lái mới thỉnh thoảng gặp khó khăn trong giao tiếp với người hoa tiêu, họ có thể chiếm bàn phím tự gõ mã theo ý họ và làm mất đi sự giao tiếp trong cặp. Để thực hành giao tiếp và chuyển đổi vai trò trong lập trình cặp, hãy thử lập trình cặp kiểu bóng bàn (ping-pong pairing). Khi lập trình cặp kiểu bóng bàn, một người A viết một kiểm thử. Người B sẽ viết mã để vượt qua kiểm thử rồi viết một kiểm thử mới cho người A . Người A viết mã để vượt kiểm thử rồi lại viết một kiểm thử mới. Quá trình như vậy được lặp đi lặp lại như khi chơi bóng bàn.
Ngược lại của giao tiếp quá ít là giao tiếp quá nhiều, những sự giao tiếp không cần thiết. Những lời phê bình thẳng thắn về mã nguồn và thiết kế là rất quí báu, nhưng ban đầu ta sẽ khó mà chấp nhận được chúng. Mỗi người có một độ nhạy cảm khác nhau, vì vậy hãy chú ý tới cách đối tác của bạn tiếp nhận những lời nhận xét của bạn như thế nào. Hãy cố chuyển những câu khẳng định (ví dụ: “Phương thức này quá dài”) thành câu hỏi hay lời gợi ý (“Chúng ta có thể làm phương thức này ngắn hơn không?” hoặc “Chúng ta có nên đẩy khối mã này ra thành một phương thức mới hay không?”). Hãy giữ một thái độ hợp tác để cùng giải quyết vấn đề.
Công cụ và phím tắt
Ngay cả khi bạn không là nạn nhân trong cuộc chiến bất tận giữa trình soạn thảo vi và emacs, bạn cũng có thể thấy khó chịu với các thiết lập trong công cụ của người cùng cặp. Hãy cố gắng chuẩn hóa một thiết lập nào đó. Một vài nhóm thậm chí còn tạo cả một bản chuẩn và đặt nó trong quản lý phiên bản. Khi bạn thảo luận về các quy chuẩn lập trình, hãy thảo luận cả vấn đề này nữa.
Hỏi và đáp về lập trình cặp
Liệu có lãng phí không khi cần tới hai người làm công việc của một người?
Trong lập trình theo cặp, hai người không thực sự chỉ làm công việc của một người. Mặc dù chỉ có một bàn phím được sử dụng nhưng lập trình có nhiều công việc khác ngoài gõ mã. Ward Cunningham đã nói: “Nếu bạn không nghĩ một cách cẩn thận, bạn có thể nghĩ rằng lập trình chỉ là gõ những câu lệnh của một ngôn ngữ lập trình.” Trong lập trình theo cặp, một người sẽ lập trình còn người kia nghĩ về những thứ xa hơn, về những vấn đề có thể phát hiện sớm, và chiến lược.
Nếu bạn cần tìm hiểu sâu hơn, [Williams] có một bộ nghiên cứu về lập trình theo cặp. Hãy nhớ rằng những biến thể trong phát triển phần mềm làm nó rất khó để thực hiện những nghiên cứu quy mô lớn. Đôi khi cách tốt nhất để biết thứ gì đó có hoạt động tốt cho nhóm của bạn hay không là hãy thử nó.
Làm sao để thuyết phục nhóm hay công ty tôi thử lập trình cặp?
Hãy xin được thử nghiệm lập trình cặp. Dành khoảng một tháng để tất cả mọi người làm việc theo cặp trên tất cả các mã nguồn sản phẩm. Hãy cố gắng thử nghiệm đủ một tháng, cho dù lập trình cặp thường khó làm và khiến bạn không thoải mái trong vài tuần đầu tiên.
Đừng nên chỉ xin phép quản lý, hãy chắc chắn tất cả các thành viên trong nhóm của bạn cũng cảm thấy thích thú khi thử lập trình cặp nữa. Những lập trình viên duy nhất tôi biết không thích lập trình cặp sau khi thử trong một tháng là những người bị ép buộc phải làm.
Chúng tôi có phải lập trình cặp mọi lúc không?
Đây là điều mà cả nhóm của bạn nên cùng quyết định. Trước khi quyết định, hãy thử làm việc theo cặp trong tất cả các mã nguồn sản phẩm (mọi thứ bạn cần phải bảo trì) trong một tháng. Ban có thể sẽ thấy thú vị hơn mong đợi.
Bất chấp những quy định, bạn vẫn sẽ làm ra những đoạn mã mà bạn không phải phải bảo trì (Khung giải pháp là một ví dụ). Những cái này có thể được hưởng lợi từ nghiên cứu cá nhân.
Nếu bạn thấy chán khi lập trình cặp, hãy xem bạn có thể làm cho thiết kế ít lặp lại hơn không.
Một vài tác vụ cứ lặp đi lặp lại đến nỗi mà không cần thiết phải động não thêm.Tuy nhiên, trước khi từ bỏ lập trình cặp, hãy xem tại sao thiết kế của bạn lại yêu cầu quá nhiều sự lặp lại. Nó có thể là dấu hiệu của một lỗ hổng thiết kế. Hoa tiêu nên sử dụng thêm thời gian để nghĩ về việc cải tiến thiết kế và thảo luận nó với cả nhóm.
Làm sao tôi có thể tập trung khi mà luôn có ai đó cứ nói chuyện với tôi?
Khi điều hướng, nếu bạn gặp khó khăn để hiểu các bước tiếp theo người lái định làm, hãy yêu cầu người lái nói ra suy nghĩ của họ.
Là người lái, đôi khi bạn có thể thấy rằng mình đang mất tập trung. Hãy để người điều hướng biết, họ có thể đưa ra gợi ý giúp bạn giải quyết vấn đề. Cũng có thể, bạn chỉ cần một vài khoảnh khắc yên tĩnh để tập trung lại.
“Nếu bạn khó tập trung, hãy thử thực hiện các bước nhỏ hơn.”
Nếu bị mất tập trung liên tục, bạn có thể đã làm theo các bước quá lớn. Hãy sử dụng TDD (Test-Driven Development) và làm theo các bước rất nhỏ (baby step). Dựa vào người điều hướng của bạn để theo dõi những gì bạn cần làm (nói với cô ấy nếu bạn có một ý tưởng, cô ấy sẽ viết nó ra) và chỉ tập trung vào vài dòng mã cần phải làm để vượt qua kiểm thử.
Nếu bạn đang làm việc với một kĩ thuật mà bạn không hoàn toàn hiểu, dành vài phút để làm việc với một khung giải pháp. Bạn và người cùng cặp của bạn có thể cùng làm hoặc làm riêng.
Làm gì nếu chúng tôi bị lẻ một người ?
Người lập trình viên bị lẻ ra đó có thể làm những công việc khác không liên quan đến mã nguồn sản phẩm. Anh ta có thể nghiên cứu kỹ thuật mới, hoặc nghiên cứu sâu hơn về công nghệ mà nhóm đang dùng. Hoặc anh ta có thể bắt cặp cùng với một khách hàng hoặc kiểm thử viên để xem xét chương trình, “đánh bóng” chương trình hoặc làm kiểm thử khám phá. Hoặc anh ta cũng có thể làm batman của nhóm (trong một nhóm XP, batman là người xử lý những yêu cầu trợ giúp hoặc yêu cầu đột xuất của khách hàng, thuyết phục họ dời yêu cầu đột xuất đó sang phân đoạn sau, xem thêm ở “Iteration Planning” ).
Thường thì lập trình viên bị lẻ ra dùng thời gian để xem lại thiết kế tổng thể để hiểu rõ hơn nó hoặc nghĩ cách cải thiện những phần chưa ổn. Nếu có nhiều việc tái cấu trúc cần làm, người lập trình viên lẻ có thể đảm nhận việc này.
Nếu nhóm chỉ có 2 hay 3 người, có nên lập trình cặp liên tục?
Thậm chí một ông thánh cũng có thể làm bạn phát cáu nếu bạn cứ phải cặp với ông ta ngày này qua ngày khác. Bạn phải tự mình quyết định khi nào thì lập trình cặp và khi nào bạn cần thời gian làm việc một mình. Nếu bạn thấy ổn nhưng cặp của bạn lộn xộn dần, đừng cố quá, hãy nghỉ ngơi một chút.
Tôi đã từng lập trình cặp với một người trong 3 tháng liền làm một dự án hai người. Tôi nghĩ việc chúng tôi có một văn phòng rộng và một cái bàn to rất hữu ích: nó giúp chúng tôi không gian để di chuyển vòng vòng xả căng thẳng. Chúng tôi còn có một cái tủ lạnh mini với đầy đồ ăn ở trong.
Thậm chí khi có những điều kiện thoải mái như vậy, tôi vẫn có những lần phải phát cáu lên.
Có lẽ điều quan trọng giúp tôi có thể lập trình cặp với cùng một người lâu như vậy là nhờ người cùng cặp với tôi là người rất dễ tính và không để tâm đến những lần tôi phát cáu đó.
Quá tập trung vào công việc và quên mất việc chuyển cặp, làm cách nào để chuyển cặp thường xuyên hơn?
Thực tế, thời điểm tốt nhất để đổi cặp và có được không khí làm việc tươi mới là khi bạn cảm thấy bế tắc hoặc “ngán”.
Một vài đội dùng đồng hồ báo giờ để chuyển cặp sau một khoảng thời gian định trước. Báo cáo của Belshee cho thấy rằng chuyển cặp sau mỗi 90 phút đem lại hiệu quả tốt. Mặc dù việc tạo thói quen chuyển cặp là rất tốt, nhưng hãy chắc chắn là tất cả mọi người đều muốn vậy (Có thể có ai đó không muốn chuyển cặp mà muốn tiếp tục làm việc cặp với người cũ để giải quyết nốt vấn đề sắp xong chẳng hạn).
Làm thế nào để lập trình cặp từ xa?
Bạn có thể dùng tai nghe và phần mềm chia sẻ màn hình desktop như VNC hay NetMeeting để lập trình cặp từ xa. Tôi có nghe nói đến những đội đã dùng hai máy tính nhưng chia sẻ cùng màn hình với nhau cùng với chương trình VoIP. Khi tôi thử theo cách này, tôi thấy rằng nó khá tệ. Các đội XP thường ngồi cùng nhau, vì vậy việc lập trình cặp từ xa thường không cần thiết.
Những lợi ích đáng kinh ngạc của lập trình cặp
Khi bạn đã lập trình cặp thuần thục, bạn sẽ thấy mình hết sức tập trung vào công việc và làm việc với bạn cùng cặp. Bạn sẽ ít bị gián đoạn và xao nhãng hơn. Khi bị ai đó gián đoạn thì sẽ có một người giải quyết vấn đề còn người kia tiếp tục công việc. Sau gián đoạn, bạn có thể trở lại với công việc ngay lập tức. Đến cuối ngày, bạn sẽ thấy thoả mãn dù mệt mỏi. Bạn thích thú được làm việc tập trung và thân thiện với bạn cùng cặp.
Toàn nhóm có được mã chất lượng cao hơn hẳn. Nợ kỹ thuật (technical debt) giảm. Kiến thức thông suốt trong nhóm, giúp nâng cao trình độ của mỗi người và giúp thành viên mới nhanh chóng hoà nhập vào nhóm.
Chống chỉ định
Lập trình cặp yêu cầu một môi trường làm việc thoải mái. (tham khảo các thiết kế “Sit Together” ở chương 6). Nếu không gian làm việc của bạn không cho phép các cặp ngồi cạnh nhau một cách thoải mái, hoặc là thay đổi không gian làm việc hoặc là đừng lập trình cặp nữa.
Tương tự như vậy, nếu đội của bạn không ngồi cùng nhau, lập trình cặp có thể mất tác dụng. Việc lập trình cặp từ xa thì không thể bằng được khi ngồi cùng nhau.
Một lý do khác để không lập trình cặp khi lập trình viên không thích ứng được. Lập trình cặp là một sự thay đổi lớn về phong cách lập trình và bạn có thể gặp phải vấn đề không tương thích. Tôi thường giải quyết vấn đề này bằng cách yêu cầu mọi người cố gắng thử lập trình cặp trong một hoặc hai tháng trước khi đưa ra quyết định cuối cùng. Nếu họ vẫn không thể thích ứng được, tốt nhất là không nên áp dụng lập trình cặp nữa thay vì cố gắng ép buộc.
Các giải pháp thay thế
Lập trình cặp là một phương pháp rất mạnh mẽ. Nó làm giảm các thiếu sót, cải thiện chất lượng thiết kế, chia sẻ kiến thức giữa các thành viên trong nhóm, tăng tính kỉ luật, giảm phiền nhiễu mà không bị giảm năng suất. Nếu bạn không thể lập trình cặp, bạn cần phương pháp thay thế.
Thanh tra mã nguồn một cách chính thống có thể giảm thiếu sót, cải thiện chất lượng, tăng tính kỉ luật. Tuy nhiên, theo kinh nghiệm của tôi, các lập trình viên có vấn đề bao gồm cả sự kiểm tra trong lịch làm việc của họ, ngay cả khi họ đang ủng hộ nó. Lập trình cặp dễ dàng hơn để làm một cách nhất quán, và nó cung cấp nhiều phản hồi nhanh hơn là sự kiểm duyệt theo lịch trình. Nếu bạn muốn sử dụng những kiểm duyệt ở nơi đang lập trình cặp, hãy thêm một số cơ chế hỗ trợ để giúp chúng được thực hiện.
Kiểm duyệt tự nó không có khả năng chia sẻ kiến thức kỹ càng như việc sở hữu mã tập thể đòi hỏi. Nếu bạn không thể lập trình theo cặp, hãy xem xét tránh việc sở hữu mã tập thể, ít nhất lúc đầu.
Nếu bạn vẫn muốn có việc sở hữu mã tập thể, bạn cần một cơ chế thay thế cho việc chia sẻ kiến thức về trạng thái của mã nguồn cơ sở. Tôi đã thành lập các nhóm nghiên cứu thường xuyên nơi mà các lập trình viên gặp nhau hàng ngày trong khoảng 30 phút để xem xét và thảo luận về thiết kế.
Tôi không biết bất kì phương pháp nào giúp giảm những thiết sót tốt như lập trình cặp. Tuy nhiên, tôi nhận thấy rằng mình không chịu đựng được nhiều phiền nhiễu khi đang mệt. Khi không lập trình cặp, hãy quan tâm nhiều hơn đến tầm quan trọng của nhiệt huyết trong công việc.
Đến năm 2020, sẽ có khoảng 5,5 tỷ thiết bị di động trên toàn thế giới, điện thoại thông minh dần trở thành vật không thể thiếu đối với đời sống hàng ngày của người Việt. Theo các báo cáo trong nước gần đây chỉ ra rằng, có khoảng 45% người Việt kiểm tra điện thoại ngay khi tỉnh dậy trong 5 phút và dành thời gian trung bình 2 tiếng một ngày cho smartphone.
Hơn thế nữa, “xóa 3 app tải về 5 app” là con số trung bình của 72% người Việt có smartphone trong mỗi tháng. Những con số trên chứng minh cho tính khả quan của sự phát triển không ngừng của điện thoại thông minh và những công nghệ di động kèm theo. Có thể nói chuyển dịch số (digital transformation) với sức phủ rất lớn đang đặt ra hai kịch bản cho các doanh nghiệp phải lựa chọn: hoặc chết, hoặc phát triển vượt bậc nếu biết tận dụng lợi thế công nghệ. Từ đó cho thấy tầm quan trọng của Mobile và digital hóa, các doanh nghiệp phải nghĩ về sự chuyển mình trong năm 2019.
Đâu là chìa khóa thành công cho doanh nghiệp 2019?
Với tầm quan trọng của công nghệ mobile, doanh nghiệp có thể tăng tính hiệu quả trong việc đồng nhất quản lý hệ sinh thái của mình, giảm chi phí bảo trì nâng cấp của bên thứ 3. Xu hướng mới này khiến các thương hiệu đều “đứng ngồi không yên” với những trăn trở làm sao để ứng dụng các phương thức digital transformation cho doanh nghiệp của mình. Vietnam Mobile Day 2019 sẽ bật mí những câu
Xu hướng Mobile Payment đã trở thành phương thức thanh toán phổ biến tại nhiều quốc gia phát triển, thúc đẩy các giao dịch thanh toán cho toàn thị trường. Với giá trị chi tiêu của người dân chiếm tới hơn 80% tổng số giao dịch hàng ngày với những tiện nghi tuyệt vời mà nó mang lại như: nhanh chóng, chính xác và hạn chế chi phí. Trong năm vừa qua, các thanh toán qua mobile tăng đến 161%. Một thực tế cho thấy, việc các ứng dụng đặt xe và đặt thức ăn đã góp phần không nhỏ cho sự tăng trưởng vượt bậc này.
Tự động hóa quy trình tự động (Robotics Process Automation – RPA) đã trở thành một giải pháp rất “thời thượng” trong suốt năm 2018. RPA thường được đặt trong nhóm với Trí tuệ nhân tạo (Artificial Intelligence – AI) và Học máy (Machine Learning – ML) và sự phát triển của tổ hợp này đã bùng nổ được một thời gian. Tuy nhiên, khi được tách riêng ra, RPA được dự đoán sẽ có một sự tăng trưởng đáng kinh ngạc như một thị trường độc lập.
Theo báo cáo của Forrester, thị trường RPA trị giá khoảng 250 triệu đô la vào năm 2016, nhưng ước tính sẽ tăng lên 2,1 tỷ đô la vào năm 2021. Chỉ riêng trên G2 Crowd, số lượng và tần suất truy cập vào trang danh mục RPA đã tăng đáng kể trong suốt năm 2018. Từ thời điểm danh mục được thêm vào tháng 2 năm 2018 đến cuối tháng 10 năm 2018, lưu lượng truy cập không phải trả tiền cho trang danh mục RPA đã tăng gần mười lần và hiện là hạng mục cao thứ mười về lưu lượng truy cập miễn phí trên tất cả G2 Crowd, điều đó có nghĩa là người mua đang rất tích cực tìm kiếm các giải pháp tự động hóa.
Sẽ có khoảng 20 tỷ thiết bị IOT được sinh ra vào năm 2020, có lẽ đây sẽ là một con số gây ấn tượng cho bất kỳ tín đồ công nghệ nào. IOT sẽ được gắn liền như hình với bóng với chiếc điện thoại thông minh của từng cá nhân. Cuộc đua sẽ trở nên nóng bỏng hơn giữa những nhà cung cấp, có đến 22% các doanh nghiệp khảo sát tin rằng, IOT sẽ là một trong những mũi nhọn đáng đầu tư nhất trong năm nay. Security, Edge computing, Automation và nhiều công nghệ hấp dẫn hơn nữa sẽ được giới thiệu một cách chi tiết nhất tại sự kiện năm nay.
Một trong những hội nghị công nghệ lớn nhất Việt Nam diễn ra hằng năm – Vietnam Mobile Day 2019 sắp trở lại
Một trong những xu thế về công nghệ được mong chờ sẽ làm mưa làm gió trong năm 2019 là công nghệ mạng dữ liệu không dây 5G. Không chỉ có tốc độ đường truyền nhanh gấp nhiều lần so với 4G LTE, 5G còn có thể cho phép số lượng thiết bị kết nối gấp 100 lần trong 1 đơn vị diện tích. Theo một cuộc khảo sát của Công ty Ericsson, 92% các chuyên viên trong số 100 nhà điều hành viễn thông toàn cầu đồng ý rằng 5G sẽ mở đường cho sự nổi lên của các ứng dụng công nghệ. Đặc biệt hơn, mạng dữ liệu 5G sẽ giúp thiết lập Internet vạn vật (IoT) trở thành một phần không thể thiếu trong cuộc sống, thông qua việc đặt nền móng để phát huy hết toàn bộ tiềm năng của nó. Gartner dự đoán sẽ có 20.4 tỷ thiết bị IoT được đưa vào sử dụng trước năm 2020 và con số này sẽ còn tiếp tục gia tăng.
Nắm bắt được xu thế công nghệ di động nổi bật, VIETNAM MOBILE DAY 2019 được tổ chức bởi TopDev sẽ có hơn 100 chủ đề nóng nhất hiện nay được triển khai xuyên suốt đảm bảo mang đến những chuyên đề không chỉ về khía cạnh công nghệ, kỹ thuật trên nền tảng di động mà còn là một lượng lớn kiến thức, kỹ năng thực tiễn liên quan đến 6 lĩnh vực Fintech, Blockchain, Mobile App & Game, Digital & Mobile Marketing và AI/Machine Learning do các chuyên gia đầu ngành tham gia chia sẻ với mong muốn đem ngành công nghệ Việt Nam đến gần hơn với tiêu chuẩn thế giới.
Trong năm vừa qua, với sự góp mặt của Microsoft, Google Play, Facebook, Lazada, etc tạo nên một thành công vang dội cho sự kiện hứa hẹn chuỗi sự kiện sắp tới sẽ tiếp tục có sự tham gia của các tập đoàn công nghệ lớn này. Sự kiện mang lại một sân chơi hấp dẫn, phong phú, thu hút hơn 9.000 người tham dự; với hơn 550 doanh nghiệp lớn nhỏ hoạt động trong ngành công nghệ thông tin và hơn 80 diễn giả tham gia chia sẻ, chắc chắn đây sẽ là một bữa tiệc thịnh soạn dành cho cộng đồng lập trình, doanh nghiệp và khởi nghiệp quan tâm đến lĩnh vực công nghệ.
THỜI GIAN & ĐỊA ĐIỂM DIỄN RA SỰ KIỆN
TP. Hồ Chí Minh: 06/06/2019 tại Grand Palace, 142/18 Cộng Hòa, P.4, Q. Tân Bình, Tp.HCM
TP. Hà Nội: 14/06/2019 tại CTM Palace 131 Nguyễn Phong Sắc, Dịch Vọng Hậu, Cầu Giấy, Hà Nội
Ý tưởng xây dựng Progressive Web App (viết tắt là PWA) không phải là mới, được Google giới thiệu lần đầu vào năm 2015 với mục đích mang lại thật nhiều lợi ích cho cả người dùng và các nhà phát triển.
Sau nhiều quá trình cố gắng, các engineers Pinterest đã xây dựng Progressive Web App thành công với thiết kế trải nghiệm người dùng tuyệt vời trong trình duyệt trên mobile.
Và đây là kết quả họ đã đạt được sau khi xây dựng thành công Progressive Web App:
Qua kết quả trên thấy được, thời gian sử dụng ứng dụng đã tăng lên 40%, doanh thu từ quảng cáo đã tăng đến 44%, số lượng click vào quảng cáo đã đạt đến 50%, và số lượng tương tác đã tăng đến 60%.
Trong khi đó ở native app và phiên bản web trên desktop thì tốc độ tăng trưởng thấp hơn rất nhiều.
Từ kết quả trên ta thấy được 1 điều, khi trải nghiệm người dùng tốt sẽ dẫn đến lượng tương tác của người dùng tăng lên, và kéo theo doanh thu cũng tăng theo.
Vậy chúng ta cùng tìm hiểu xem các kĩ sư Pinterest đã xây dựng Progressive Web App lớn nhất thế giới như thế nào nhé.
Trước khi bắt đầu, cùng điểm qua xem Progressive Web App nó là gì đã nhé.
Đầu tiên mình nhấn mạnh là Progressive Web App không phải là 1 web framework hay 1 công nghệ gì mới. Nó là 1 sự kết hợp giữa lập trình web và lập trình ứng dụng di động.
Nó sẽ giúp cho chức năng trên web tương tự như chức năng trên mobile. Tương tự đến mức mà người dùng khó phân biệt được mình đang dùng trên trình duyệt hay là đang dùng trên native app.
Progressive Web App sẽ làm được những gì?
Tải nhanh: tốc độ tải dữ liệu cực nhanh, áp dụng cơ chế cache sẽ giúp cho ta có thể xem được dữ liệu khi mà đang offline.
Trải nghiệm người dùng tốt: Vì giao diện dùng trên Progressive Web App khá giống với trên native app. Nên sẽ giúp trải nghiệm người dùng tốt hơn. Ví dụ có thể gửi được thông báo, rồi có thể sử dụng quyền truy cập đến thiết bị như native app.
Tại sao Pinterest quyết định sử dụng Progressive Web App?
Qua dữ liệu thống kê thấy được, 80% tổng số lượng người dùng Pinterest đang sử dụng trình duyệt browser trên mobile thay vì sử dụng ứng dụng native app.
Mặc dù số lượng người dùng download app cũng tăng lên theo ngày nhưng mà cũng có không ít số lượng review không tốt. Đây là 1 ví dụ:
Cách đây 2 năm (năm 2017), bên Pinterest đã tập trung build 1 đội viết lại trang web trên mobile sử dụng Progressive Web App.
Có 2 lí do khiến Pinterest đầu tư rất nhiều vào mobile web.
Đầu tiên là vì người dùng. Progressive Web App sẽ giúp những người có mạng internet tốc độ thấp hay gói dữ liệu hạn chế có khả năng trải nghiệm tốt hơn. Với hơn 1 nửa người dùng không ở US, việc xây dựng 1 mobile web tốt, tốc độ tải trang nhanh, tiết kiệm băng thông sẽ giúp Pinterest dễ truy cập hơn trên toàn cầu, và cuối cùng sẽ giúp trải nghiệm người dùng tốt hơn.
Lí do thứ 2 là dựa trên dữ liệu (data-driven). Do trải nghiệm người dùng trên native app không được tốt nên có 1 tỉ lệ rất nhỏ người dùng do không authen được nên đã chuyển sang dùng mobile web. Nhưng số lượng người dùng trên native app vẫn lớn hơn và có độ tương tác tốt hơn rất nhiều so với trên mobile web, và để chuyển đổi người dùng từ native app sang mobile web không phải là việc dễ dàng gì. Nhưng Pinterest nghĩ họ có thể làm tốt hơn.
Vậy kĩ sư Pinterest đã làm nó như thế nào? Vào tháng 7/2017, Pinterest đã thành lập ra 1 nhóm kết hợp từ các engineer từ nền tảng web và growth teams. Trong nội bộ Pinterest gọi nó là Project Duplo.
Vào thời điểm đó, mobile web chỉ chiếm khoảng 10% tổng số lượt signup (đăng kí tài khoản). Cùng thời điểm thì website trên nền tảng desktop đã tăng gấp 5 lần.
Mốc thời gian:
Tháng 7/2017: Bắt đầu dự án Duplo
Tháng 8/2017: Launch 1 trang web mới trên mobile cho 1 tỉ lệ phần trăm người dùng đã logged-in.
Tháng 9/2017: Ship trang web mới trên mobile cho toàn bộ người dùng đã logged-in vào
Tháng 1/2018: Launch 1 trang web mới trên mobile cho tỉ lệ phần trăm của người dùng đã logged-out
Tháng 2/2018: Ship trang web mới trên mobile cho toàn bộ người dùng đã logged-out.
Lí do mà các kĩ sư Pinterest có thể hoàn thành xong 1 phiên bản trên mobile web chỉ mất có 3 tháng là do họ có sử dụng 1 open source do chính họ tạo ra có tên là Gestalt.
Ở Pinterest họ đang sử dụng React cho tất cả web development. Các bộ phận trong Gestalt được xây dựng để bao gồm các design language, giúp dễ dàng tạo ra các trang khá đẹp mà không phải lo lắng về CSS.
Gestalt tạo ra 1 bộ các component dành riêng cho thiết bị di động để tạo ra các trang có khoảng cách nhất quán với toàn bộ trang. Điều đó giúp cho quá trình xây dựng website trở nên nhanh và đơn giản hơn.
Ngoài Gestalt thì Pinterest cũng sử dụng 1 số thư viện khác nữa như React, Reac-router v4, redux, redux-thunk, Reac -redux, normalizr, reselect, Flow và prettier .
Làm thế nào để làm tốc độ tải trang được nhanh hơn?
Cải thiện hiệu năng web luôn là vấn đề được quan tâm, bởi vì nó ảnh hưởng rất lớn đến mức độ tương tác của người dùng đến hệ thống. Đặc biệt với những người có tốc độ mạng kém hay bị giới hạn. Chẳng ai thích thú gì khi phải load những trang khá nặng mà mạng đang dùng thì khá chậm phải không nào.
Sau khi tối ưu, Pinterest đã giảm kích thước file Javascript từ 490kb xuống còn 190kb. Việc này đạt được nhờ code-splitting ở tầng route, đặc biệt dùng component <Loader> sẽ giúp các bạn làm được điều đó.
Ngoài ra nhờ việc sử dụng hệ thống preloading được đặt ở phía client side đã giúp cho tốc độ tải trang được nhanh hơn, làm trải nghiệm người dùng được tốt hơn.
Chỉ trong 1 năm, phía mobile web đã có trên 600 file javascript, và tất cả nó đã được build vào 1 file được gọi là file bundle. Điều này sẽ rất khó trong việc đo lường để tối ưu hiệu năng.
Do đó, Pinterest đã phân tán các file javascript đó trên các trang web con dạng *.pinimg.com và đảm bảo rằng các dependencies trong mobile web luôn luôn được clean.
Nhìn vào hình ảnh trên chúng ta thấy được là các file js đang được nằm phân tán trên các website khác của pinterest (s.pinimg.com) và những file này đều được trả về từ Service Worker.
Để file bundle không vượt quá giới hạn cho phép, phía Pinterest đã tạo ra những graph để report các file bundle đã được build và sẽ thông báo khi có file nào vượt quá kích thước cho phép.
Cái thứ 2 mà Pinterest đã làm là đã customize eslint rule để không cho phép import những files hay directories mà có thể là nguyên nhân gây “phình” to file bundle. Ví dụ như mobile web sẽ không cho phép import từ những file trên desktop web. Đương nhiên họ sẽ có 1 thư mục dùng chung cho cả 2 mobile web với desktop web.
Và đây là kết quả khi họ tối ưu tốc độ load trang web:
Sau khi đã tối ưu được tốc độ load trang, thì điều tiếp theo họ nghĩ là làm thế nào để hiển thị dữ liệu được nhanh hơn.
Như chúng ta đã biết, với React thì cái driver lớn nhất mà ảnh hưởng đến hiệu năng phía client side đó chính là redux store (1 trong những component có thể giúp cho quá trình thay đổi route 1 cách tức thì). Xem thêm về connect React-Redux.
Ví dụ như màn hình list pins đang hiển thị hình ảnh vs title của pin. Từ màn hình list pins, chúng ta click vào 1 pin để xem chi tiết.
Khi đó dữ liệu về ảnh với title của pin ở màn hình list sẽ được mang sang màn hình detail pin để hiển thị ngay lập tức.
Đồng thời, Pinterest sẽ gửi thêm 1 request để lấy thêm dữ liệu về pin (như thông tin về owner của pin, description của pin, số lượng follow …). Khi đó người dùng có cảm giác tốc độ hiển thị dữ liệu khá nhanh, điều đó làm cho trải nghiệm người dùng cũng được tốt hơn.
Ngoài ra “trái tim” của trang web mới này đó là nó support cả phần app shell, add đến homescreen, push notifications and asset caching.
Service Worker sẽ cache lại server-rendered đối với từng người dùng cụ thể, và phục vụ cho lần page load tiếp theo.
Đặc biệt Pinterest đã rất “biết ơn” Apple đã tích hợp Service Worker trên Safari, để giúp cho người dùng có trải nghiệm tốt hơn như trên native app.
Kết quả đạt được
Bây giờ đến phần mà các bạn mong chờ: đó là những con số.
Active users hoạt động trên mobile web đã tăng lên 103% so với năm trước, với 156% ở Brazil và 312% ở India.
Thời gian sử dụng mobile web đã tăng lên đến 296%
Số lượng pin đã tăng lên 401%
Số lượng người dùng muốn save Pin đến board tăng đến 295%
Và đặc biệt hơn, số lượng login đã tăng lên 370%, số lượng signup đã tăng 843% trên 1 năm.
Thời đại công nghệ ngày nay, quả thực trải nghiệm người dùng rất quan trọng, nó quyết định đến sự sống còn của dịch vụ.
Nếu bạn nào đang có ý định phát triển Progressive Web App thì hi vọng qua bài này sẽ giúp 1 phần nào đó.
Ruby On rails là một Framework cho phép phát triển ứng dụng Web được base dựa trên ngôn ngữ lập trình Ruby. Ruby là một ngôn lập trình mã nguồn mở, linh hoạt, với một sự nổi bật về sự đơn giản dễ dùng và hữu ích. Nó có cú pháp rõ ràng, tự nhiên dễ đọc và dễ dàng để viết.
Lịch sử ra đời
Lịch sử hình thành của ngôn ngữ Ruby:
Ruby được tạo ra bởi Yukihiro “Matz” Matsumoto từ 24 tháng 2, 1993 và đưa ra bản chính thức vào năm 1995. Ruby kế thừa và chịu nhiều ảnh hưởng từ ngôn ngữ lập trình Perl.
Nguồn gốc của Rails:
Rails ra mắt công chúng lần đầu tiên vào năm 2004, Rails thoạt đầu được dùng như là nền tảng cho một công cụ quản lý dự án được đặt tên là Basecamp và được tạo ra bởi nhà phát triển web David Heinemeier Hansson, một nhân viên của công ty phát triển web 37signals (Mỹ).
Ruby cung cấp một sự kết hợp giữa những các công cụ tốt nhất, thư viện chất lượng và cách tiếp cận tốt tới phần mềm. Bên cạnh đó cộng đồng Ruby cũng cực kỳ lớn.
Code: chất lượng của các phần mềm viết bởi Ruby code khá chất lượng và ổn định.
Công cụ: Rails cung cấp cho ta những công cụ tuyệt vời giúp chúng ta triển khai được nhiều tính năng hơn nhưng tốn ít thời gian hơn, nó còn cung cấp một cấu trúc chuẩn cho ứng dụng web.
Thư viện: Rails cung cấp cho ta gem, tất cả gem đều có thể sử dụng một cách hoàn toàn miền phí và có thể dễ dàng tra cứu.
Cộng đồng: Cộng đồng Ruby rất lớn. Điều này giúp cải thiện những sản phẩm của Ruby rất nhiều và đây cũng là một lý do mà thư viện của Ruby lại tuyệt vời như vậy. Ruby cũng là một trong số những ngôn ngữ lập trình phổ biến nhất trên Github.
Hiệu suất: Ruby là một ngôn ngữ gọn gàng, khi mà sử dụng kết hợp cùng các thư viện hỗ trợ, Ruby on Rails cho phép bạn phát triển chức năng cho ứng dụng web một cách khá là nhanh chóng.
Tương lai: Nếu so với nhưng ngôn ngữ lập trình đang phát triển mạnh tại Việt Nam như PHP, Java hay .Net thì tỉ lệ “đối thủ” sẽ cao để kiếm được việc làm nếu như bạn chọn những ngôn ngữ lập trình đó. Trong khi đó, với việc làm Ruby on Rails thì tỉ lệ này sẽ thấp. Khi số lượng cung thấp hơn cầu thì giá lương sẽ tăng cao.
Ruby on Rails thường được các công ty startup yêu thích sử dụng cho backend của họ, vd như có công ty Wefit là startup nổi bật về kết nối các phòng tập Gym, hay như startup triệu đô Logivan
Trong những năm gần đây, ngày càng nhiều người bắt đầu quan tâm đến việc học code.
Mọi người tự tìm cách vào con đường lập trình thông qua các khóa học online hoặc qua các buổi gặp mặt offline hoặc chỉ đơn giản là tự nỗ lực.
Các trang web như code.org, codecademy và freeCodeCamp đang ngày càng trở nên phổ biến hơn. Các trang web này có rất nhiều khóa học viết code và cũng sẵn có trên cả YouTube.
Nhưng việc viết code không hề dễ dàng. Dưới đây là một số thách thức mà tất cả chúng ta phải đối mặt khi học.
1. Tìm ra tổng thời gian “tối ưu” để code mỗi ngày.
Nếu bạn đang tự học code, thì khả năng là bạn còn gánh những trách nhiệm khác trong cuộc sống nữa.
Bạn có thể có một công việc bán thời gian, một công việc toàn thời gian, hoặc bạn có thể ở cùng cha mẹ. Vấn đề là mọi người đều bận rộn trong cuộc sống. Vì vậy, làm thế nào để bạn tìm thời gian code hàng ngày?.
Một số người có thể nói rằng: “À, nếu bạn đủ chuyên tâm, bạn luôn có thể tìm thấy thời gian.” Đúng vậy. Tôi đồng ý với điều đó.
Tiếp ngay sau, câu hỏi sẽ là: “Bạn dành bao nhiêu thời gian để code mỗi ngày? Nếu mỗi ngày tôi chỉ có thể chuyên tâm trong nửa giờ , thì vẫn được đúng không? ”
Đây là câu hỏi mà chỉ bản thân bạn mới có thể trả lời. Rất khó để ước tính số giờ mỗi ngày để bạn code sao cho đủ. Để vừa gọn và vừa dễ dàng, một số người đề nghị cho việc này là 15 phút . Đây là thời gian đủ tốt.
Ở khía cạnh khác, tôi cũng đã nghe những lập trình viên trong vòng một năm hoặc lâu hơn dành 9 hoặc 10 giờ để code mỗi ngày. Nếu bạn muốn có động lực, bạn có thể đưa ra một nhìn nhận từ việc này.
Điểm mấu chốt là đây: chỉ có bản thân bạn mới biết bạn có thể code hàng ngày bao lâu và làm thành thói quen mà không bị đốt cháy giai đoạn. Phần cuối cùng thực sự quan trọng. Nhà sáng lập freeCodeCamp, Quincy Larson đã từng nói trên twitter của mình:
“It is not about your daily progress, it is about progress daily.”
(Tạm dịch: Không phải biến nó thành công việc hàng ngày, mà biến nó thành sự tiến bộ hàng ngày)
Đây là một đoạn video về một senior developer, ông ấy đã ở trong lĩnh vực công nghệ trong nhiều thập niên , ông ấy nói về việc các lập trình viên phải làm nhiều đến mức nào mỗi ngày trong khi họ đang làm việc.
Nó sẽ không phải là tiêu chuẩn vàng, nhưng nó sẽ cung cấp cho bạn một ý tưởng về cách để thiết lập cho mình một cái nhìn thực tế, và quan trọng nhất là có kế hoạch chắc chắn khi bắt đầu học code hàng ngày.
2. Tìm sự cân bằng giữa “chưa đủ tiến bộ” và “đốt cháy giai đoạn”.
Đối với cá nhân tôi, tôi đã vật lộn với điều này rất nhiều.
Có những ngày tôi không thể hiểu được một khái niệm hoặc bất kỳ đoạn code nào từ cuốn sách mà tôi đã đọc. Tôi không thể nào hiểu nó. Tôi chắc là đã bị đốt cháy giai đoạn đến mất tệ hại , đến nỗi tôi phải bình tĩnh lại, đi đến ban công và hít một hơi thật sâu.
Từ thời điểm đó trở đi, tôi luôn nhắc nhở bản thân mình đừng làm việc quá sức tới mức không tìm lại được bản thân.
Lập trình không phải là dễ dàng. Nó đòi hỏi bạn phải tập trung, đặc biệt là khi bạn đang học những thứ mới. Đó là việc đánh thuế về tinh thần và có những lúc bạn không thể tính toán được – tại sao code của bạn không hoạt động hoặc thậm chí là ngược lại.
Tôi nhận ra mình làm việc hiệu quả nhất bất cứ khi nào bản thân thực sự tập trung vào vấn đề đang làm ngay lúc đó, nhưng chính lúc đó tôi đã thực sự thư giãn, tận hưởng toàn bộ quá trình.
Những lúc khi tôi :
Tìm thấy một vấn đề tôi cần phải giải quyết.
Tìm thấy giải pháp thông qua diễn đàn online.
Đã thử một loạt các cách khác nhau để giải quyết vấn đề chỉ để để tìm ra một cách đúng.
Đã giải quyết hết vấn đề.
Để đối phó với thực tế nhiều thứ chúng ta đang học khá là phức tạp (cấu trúc dữ liệu và giải thuật), tôi đã phát triển quy tắc 50/50 này bất cứ khi nào tôi học code.
Tôi sử dụng 50% thời gian để thực hiện các công việc khó , nghiên cứu các khái niệm, giải thuật cơ bản và những thứ tương tự. 50% thời gian còn lại tôi đang làm dự án của riêng mình, các dự án mà tôi thực sự đam mê. Vì vậy, có một sự cân bằng khi nói đến việc nghiên cứu hàng ngày của tôi.
Vì lẽ đó, để tiếp tục , bạn cần yêu cái mà bạn làm. Điều này dẫn chúng ta đến nội dung chính tiếp theo.
3. Thật sự thích thú với những gì bạn đang làm là cách duy nhất để vượt qua tất cả những trở ngại.
Đôi khi sự thật chỉ đơn giản là vậy. Nếu bạn yêu thích con đường bạn đang nắm bắt, yêu công việc bạn đang làm, yêu hướng bạn đang đi … bạn không cần sự thừa nhận từ thế giới bên ngoài.
Loại tình yêu này không thể được mượn hoặc thay thế, hoặc thậm chí tệ hơn, giả mạo.
4. Tiếp tục quay lại code ngay sau khi hoàn thành các công việc khác hằng ngày.
Thực tế là khi nói đến tự học, chưa bao giờ chỉ là bản thân bạn, ở đó, học tập.
Trong cuộc sống, tất cả chúng ta đều có đầy đủ bổn phận mà chúng ta được giao phó. Bạn có thể là chồng, hoặc vợ hoặc cha mẹ của ai đó. Bạn cần phải chăm sóc gia đình , hoặc bạn có một công việc bạn cần phải tham gia. Hoặc có thể bạn là sinh viên cần hoàn thành bằng tốt nghiệp hoặc bậc học.
Với tất cả các bổn phận đặt trên vai chúng ta, đâu là nơi chúng ta tìm ra thời gian để code?
Sự thật là đôi khi bạn không có hoặc chỉ đơn giản là không thể. Có những lúc tôi bỏ qua code. Thời gian “ngưng code” dài nhất của tôi là hai tháng.
Nhưng sau đó, tôi quay lại code ngay lập tức. Và tôi phát hiện ra rằng tôi đã quên rất nhiều thứ mình đã học. Nó có thể gây bực bội khi bạn lấy lại cùng một cuốn sách , và đơn giản bạn không biết làm thế nào tiếp theo. “Chúa ơi, tôi có thực sự phải đọc lại tất cả các chương và làm lại tất cả các yêu cầu không?”
Đấy là lúc bạn chỉ cần phải kiên trì và phải nghiền nó ra.
Bạn cần phải tự nhủ: “Được rồi, giờ học đầu tiên này có vẻ thật sự chậm và không mấy hiệu quả. Nhưng được rồi, tôi sẽ tiếp tục học thêm nữa vào ngày mai. ”
Không còn cách nào ngoài việc tiếp tục, không ngừng và cố gắng cho vấn đề này. Tham gia diễn đàn hoặc Twitter và bày tỏ tâm sự của bạn. Nhưng một khi bạn đã làm xong, quay trở lại để code ngay lập tức.
5. Duy trì tạo động lực cho mình bằng mọi cách.
Tự học rất khác nhau với việc đến trường. Không có ai xung quanh bạn khi bạn đang code. Không bạn cùng lớp, không có tương tác xã hội, bạn không thể thấy “nghi lễ trọng đại” đang chờ bạn ở cuối đường hầm. Hầu hết thời gian bạn làm một mình ,cũng như ở một mình.
Vì vậy, bạn cần phải tìm động lực để giữ cho mình tiến lên phía trước.
Tôi dành toàn thời gian để kiểm tra (r / macsetups) ,bởi vì có nhiều các lập trình viên ở đó. Và họ đang sử dụng chung tất cả các phần cứng mạnh mẽ để tạo ra phần mềm. Không có gì đáng khen hơn thế.
Cũng tự thưởng cho bạn, và làm việc này trở thành một thói quen.
Nó có thể nhỏ, hoặc nó có thể lớn. Nó có thể là được tắm nước nóng vào cuối ngày, hoặc một thức uống lạnh. Hãy nói với bản thân rằng bạn đang làm một công việc tuyệt vời. Điều này cần thiết khi học lập trình. Treo bức ảnh này lên tường trước mặt bạn – bởi vì bạn phải tin vào một ngày bạn có thể là người đang ngồi trước mặt nó.
6. Đừng rơi vào sai lầm “học tập chỉ vì mục đích học” Đi phỏng vấn, gặp gỡ và nộp đơn xin việc.
Có những lúc chúng ta có thể lạc trôi khi học code. Tôi cảm thấy có những khoảnh khắc mà bạn chỉ muốn lười biếng. Không phải theo cách bạn không muốn học nữa , nhưng theo cách mà bạn âm thầm hy vọng chỉ cần ngồi trước màn hình cả ngày, bạn không phải đối mặt với thử thách thực sự: Kiếm một công việc với tư cách là nhà phát triển .
Đừng rơi vào suy nghĩ sai lầm rằng “Tôi dự định học cho đủ tốt. sau đó tôi sẽ nghĩ về việc làm khi đã sẵn sàng. ”
Để tiếp cận với khách hàng tiềm năng, kể cả xây dựng trang web miễn phí cho gia đình và bạn bè. Đây là điều tôi nên làm thường xuyên hơn.
Do đó, lần sau khi bạn tham gia phỏng vấn, bạn có trình bày loại công việc bạn đã làm. Nó sẽ thêm giá trị vào hồ sơ lý lịch của bạn. Bước đầu tiên luôn khó khăn nhất. Nhưng bạn phải làm điều đó như không có vấn đề gì.
Tất cả những điều trên là những thử thách và tình huống bạn sẽ phải đối mặt trên con đường để trở thành lập trình viên. Chấp nhận chúng, đối mặt chúng với thái độ đúng đắn – những rào cản bạn đối mặt chỉ có thể làm cho bạn mạnh mẽ và tốt hơn.
Cuối cùng nhưng không kém phần quan trọng, code vui vẻ! Tận hưởng những gì bạn đang gầy dựng, cho dù đó là dự án của bạn hay tương lai của riêng bạn.
Agile là gì? Scrum là gì? Hiện nay Agile là phương thức phát triển phần mềm được nhiều doanh nghiệp sử dụng, đặc biệt là Scrum. Bài viết này sẽ giải thích các khái niệm cơ bản nhất cũng như những giá trị cốt lõi về Agile và Scrum hiểu được lí do tại sao nó lại được sử dụng phổ biến đến vậy.
Agile là gì?
Agile là một phương pháp phát triển phần mềm linh hoạt, là một hướng tiếp cận cụ thể cho việc quản lý dự án phần mềm. Nó gồm một quá trình làm việc tương tác và tích hợp để có thể đưa sản phẩm đến tay người dùng càng nhanh càng tốt.
Trong các dự án phần mềm, đặc biệt là các dự án chúng ta sẽ gặp rất nhiều khó khăn trong việc thu thập đầy đủ và chính xác các requirements của product để lập plan tốt ngay từ đầu. Có quá nhiều vấn đề gây ảnh hưởng đến việc phát triển phần mềm mà chúng ta không lường trước được. Ví dụ như những vấn đề có thể đến từ những yếu tố như kinh doanh, kỹ thuật, con người, thời gian ra mắt ….
Những phương pháp phát triển phần mềm theo cách truyền thống ngày càng bộc lộ nhiều nhược điểm và tỷ lệ các dự án thất bại cao trong thời kỳ bùng phát của ngành công nghệ. Nhận ra vấn đề đó, một số cá nhân và công ty riêng lẻ đã đưa ra các phương pháp phát triển phần mềm hiện đại hơn và khác nhau để thích ứng với tình hình mới.
Những phương thức phát triển phần mềm này giúp phần nào giải quyết được một số vấn đề nhưng lại phát sinh vấn đề khác về sự cộng tác, kỹ thuật, công cụ, hướng phát triển, chia sẻ ….
Bản tuyên ngôn Agile (Agile Manifesto)
Vào năm 2001, bản tuyên ngôn Agile (Agile Manifesto) đã được thống nhất và ra đời bởi một nhóm người có uy tính trong phát triển phần mềm:
1. Cá nhân và sự tương tác hơn là quy trình và công cụ
Đặt trọng tâm vào con người và sự tương hỗ giữa những thành viên trong team. Nếu dự án có những thành viên có năng lực, chịu làm việc cùng nhau thì sẽ mang đến thành công cho dự án.
Nếu dự án của bạn có quy trình làm việc tốt, được hỗ trợ bởi những công cụ tốt nhất nhưng những thành viên không thống nhất hoặc cùng nhìn về một hướng thì khả năng dự án thất bại là rất lớn. Nói điều này không có nghĩa là phủ nhận tầm quan trọng của quy trình và công cụ nhưng trong Agile nó được đặt sau yếu tố con người.
Quy trình là các thủ tục cần thiết để phát triển dự án như thiết kế, sau đó đến lập trình, rồi kiểm tra QA/QC. Hay để đưa ra một chức năng nào đó cần phải có sự đồng ý của bộ phận QA/QC …. Quy trình này do mỗi công ty quy định và bắt buộc các nhân viên khi tham gia vào dự án phải tuân thủ.
Công cụ là phần mềm được sử dụng trong dự án như : Phần mềm quản lý công việc, phần mềm quản lý source code, phần mềm quản lý lỗi… Có rất nhiều công cụ được sử dụng để hỗ trợ một tổ chức vận hành.
2. Phần mềm chạy tốt hơn là tài liệu đầy đủ
Trong một số quy trình phát triển phần mềm, việc tạo ra và cập nhật các tài liệu về sản phẩm là bắt buộc. Nhóm lập trình viên không thể hoặc không đồng ý tiến hành công việc nếu không có tài liệu đặc tả về yêu cầu, thiết kế hệ thống.
Nhóm kiểm thử thì yêu cầu tài liệu về sản phẩm để có thể viết trường hợp kiểm thử và kiểm thử được. Nhóm QA đòi tất cả các tài liệu phải được viết trước khi sản phẩm được giao cho khách hàng nếu không thì không đủ điều kiện, chuẩn để giao sản phẩm cho khách hàng.
Việc viết tài liệu thật ra rất mất nhiều thời gian và được cho là rất chán. Ý tưởng ở đây là tại sao mình phải tập trung quá nhiều cho việc không cần thiết mà không dành thời gian đó để trao đổi để hiểu thêm về công việc phải làm. Sau đó đúc kết và chỉ viết những gì mà mọi người cần đọc.
3. Cộng tác với khách hàng hơn là đàm phán hợp đồng
Ta luôn nghe các câu này “Khách hàng là thượng đế” hay “khách hàng luôn luôn đúng”. Tuy nhiên thì khách hàng có nhiều dạng. Cách duy nhất để có thể làm việc tốt là phải cộng tác với khách hàng để hiểu được khách hàng muốn gì và cần gì để có thể tư vấn và điều chỉnh thay vì chỉ dựa vào những điều đã quy định trong hợp đồng.
Trao đổi và thảo luận với khách hàng về sự cần thiết có hay không của một chức năng trong sản phẩm, từ đó quyết định là có nên làm hay không. Tất nhiên để thuyết phục khách hàng thì cần có số liệu nghiên cứu cụ thể chẳng hạn.
4. Phản hồi với sự thay đổi hơn là bám theo kế hoạch
Có một điểm chung là hầu hết những dự án đều có sự thay đổi điều chỉnh khi triển khai. Sự thay đổi đó có thể là thay đổi về requirements, thay đổi tech stack, thay đổi nhân sự, thay đổi deadline, thay đổi phương thức làm việc… mặc dù kế hoạch đã được định ra rõ ràng từ đầu.
Agile không khuyến khích cho sự thay đổi nhưng khuyến khích chúng ta tập thích nghi với thay đổi.
Một trong các nguyên tắc cơ bản của agile là “phần mềm chạy tốt chính là thước đo của tiến độ”. Nguyên tắc này giúp nhóm dám loại bỏ đi các công việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm.
Để vận hành được cơ chế “làm việc dựa trên giá trị”, nhóm agile thường làm việc trực tiếp và thường xuyên với khách hàng, cộng tác trực tiếp với họ để biết yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn sớm nhất có thể cho dự án. Nhờ đó các dự án agile thường giúp khách hàng tối ưu hóa được giá trị của dự án. Một cách gần như trực tiếp, agile gia tăng đáng kể độ hài lòng của khách hàng.
12 nguyên tắc trong Agile software development
Nguyên tắc trong phát triển phần mềm Agile được trình bày trong Manifesto Agile và mô tả các giá trị và nguyên tắc cốt lõi của phương pháp phát triển Agile. Dưới đây là 12 nguyên tắc chính trong Agile software development:
Khách hàng hài lòng bằng cách cung cấp phần mềm có giá trị cao: Cung cấp phần mềm có giá trị cao, liên tục và sớm để đáp ứng nhu cầu của khách hàng và cải thiện sự hài lòng của họ.
Thay đổi yêu cầu là điều bình thường: Đón nhận và thích ứng với thay đổi yêu cầu, ngay cả khi phát triển ở giai đoạn muộn. Điều này giúp cung cấp giá trị tốt nhất cho khách hàng.
Phát triển phần mềm liên tục và thường xuyên: Cung cấp phần mềm có thể hoạt động một cách thường xuyên và liên tục, từ vài tuần đến vài tháng, với một chu kỳ phát triển ngắn hơn.
Hợp tác chặt chẽ giữa các bên liên quan: Hợp tác liên tục giữa các nhà phát triển và các bên liên quan (bao gồm khách hàng và các thành viên nhóm) trong suốt quá trình phát triển.
Xây dựng dựa trên đội ngũ tự quản lý và có động lực cao: Xây dựng dự án xung quanh các đội ngũ tự quản lý và có động lực cao. Đảm bảo rằng các thành viên đội ngũ có thể tự tổ chức và có đủ kỹ năng và sự tự tin để hoàn thành công việc.
Tạo ra phần mềm có thể hoạt động được: Phần mềm hoạt động là mục tiêu chính. Các bản phát hành nhỏ và có thể hoạt động là ưu tiên hàng đầu.
Thiết kế đơn giản và tối ưu: Thiết kế phần mềm đơn giản, với tối đa tính năng cần thiết để đáp ứng nhu cầu hiện tại. Tập trung vào việc giảm thiểu công việc chưa cần thiết và tối ưu hóa hiệu suất.
Tốc độ phát triển và khả năng duy trì cao: Duy trì khả năng phát triển nhanh chóng và có khả năng thay đổi dễ dàng. Điều này bao gồm việc duy trì mã nguồn đơn giản, dễ hiểu và có thể dễ dàng thay đổi khi cần thiết.
Phản hồi sớm và liên tục từ khách hàng: Nhận phản hồi thường xuyên từ khách hàng để đảm bảo rằng phần mềm đáp ứng nhu cầu và mong muốn của họ. Phản hồi nhanh chóng giúp điều chỉnh và cải thiện sản phẩm liên tục.
Kỹ thuật và thiết kế tốt: Khuyến khích kỹ thuật tốt và thiết kế phần mềm tốt, giúp duy trì sự nhất quán và chất lượng của mã nguồn. Đầu tư vào kỹ thuật và thiết kế sẽ giúp sản phẩm cuối cùng có chất lượng cao hơn.
Tạo môi trường làm việc tích cực: Tạo ra một môi trường làm việc tích cực, nơi các thành viên trong nhóm có thể giao tiếp mở, hỗ trợ lẫn nhau và làm việc cùng nhau hiệu quả.
Đánh giá và cải tiến thường xuyên: Đánh giá thường xuyên các quy trình làm việc, công cụ và kỹ thuật. Cải tiến liên tục giúp nâng cao hiệu suất nhóm và chất lượng sản phẩm.
Những nguyên tắc này giúp các nhóm phát triển phần mềm Agile đáp ứng nhanh chóng với sự thay đổi, duy trì chất lượng sản phẩm, và cải thiện hiệu quả công việc qua việc làm việc hợp tác và có tổ chức.
8 đặc trưng của Agile
Agile là một phương pháp phát triển phần mềm linh hoạt, nổi bật với khả năng thích ứng và phản ứng nhanh với thay đổi. Dưới đây là các đặc trưng chính của Agile:
Cung cấp sản phẩm làm việc sớm và thường xuyên
Agile tập trung vào việc cung cấp các phiên bản sản phẩm làm việc một cách sớm và liên tục. Thay vì chờ đợi đến cuối dự án để hoàn thành, Agile khuyến khích giao hàng các sản phẩm có thể sử dụng được trong các chu kỳ ngắn, thường là vài tuần đến vài tháng. Điều này giúp đánh giá và điều chỉnh sản phẩm dựa trên phản hồi thực tế từ người dùng và môi trường.
Đánh giá và ưu tiên liên tục
Trong Agile, việc đánh giá và ưu tiên công việc là một quá trình liên tục. Điều này đảm bảo rằng các phần của dự án được chọn và phát triển dựa trên giá trị hiện tại và phản hồi từ người dùng, thay vì theo một kế hoạch cứng nhắc ban đầu. Quyết định về các bước tiếp theo được đưa ra dựa trên dữ liệu mới nhất và thay đổi trong yêu cầu của khách hàng.
Giới hạn công việc đang thực hiện
Để tăng cường hiệu quả và khả năng phản ứng, Agile khuyến khích giới hạn số lượng công việc đang thực hiện đồng thời. Việc này giúp đội ngũ tập trung hoàn thành một nhiệm vụ trước khi bắt đầu nhiệm vụ khác, giảm thiểu công việc chưa hoàn thành và tối ưu hóa năng suất.
Kiến trúc phát triển dần và kiểm thử tự động
Agile khuyến khích xây dựng kiến trúc hệ thống đơn giản và dễ thay đổi, bắt đầu với các yếu tố cơ bản và mở rộng dần theo yêu cầu thực tế. Để đảm bảo chất lượng và tính ổn định, kiểm thử tự động là một phần không thể thiếu trong quy trình phát triển Agile.
Nhóm làm việc tự quản lý và đa chức năng
Các đội Agile thường là các nhóm nhỏ, tự quản lý và có thành viên từ nhiều lĩnh vực khác nhau, giúp họ có khả năng tự tổ chức và thực hiện các quyết định cần thiết để hoàn thành dự án. Điều này giúp nhóm có sự linh hoạt và nhanh nhạy trong việc phản ứng với thay đổi và thách thức.
Hợp tác chặt chẽ giữa khách hàng và nhà phát triển
Sự hợp tác liên tục giữa khách hàng và đội phát triển là trọng tâm của Agile. Khách hàng có cái nhìn sâu sắc về giá trị của sản phẩm, trong khi đội phát triển hiểu rõ các tùy chọn thực hiện và rủi ro. Việc duy trì sự hợp tác chặt chẽ giúp đảm bảo rằng sản phẩm cuối cùng đáp ứng được mong đợi và yêu cầu thực tế.
Tính minh bạch
Trong môi trường Agile, thông tin quan trọng về quá trình phát triển phải được minh bạch và dễ dàng tiếp cận đối với tất cả các thành viên trong nhóm. Điều này giúp duy trì sự đồng thuận và đảm bảo rằng mọi người đều có thể theo dõi tiến trình và hiểu rõ các mục tiêu và quyết định.
An toàn
An toàn là một yếu tố quan trọng trong Agile, bao gồm an toàn xã hội, an toàn trong nhóm và an toàn kỹ thuật. Đội ngũ cần phải có không gian an toàn để thử nghiệm và sáng tạo mà không lo lắng về sự thất bại, và hệ thống cũng cần được thiết kế để giảm thiểu ảnh hưởng của các lỗi hoặc sự cố.
Các Phương Pháp Agile Phổ Biến
Scrum: Scrum tập trung vào việc quản lý dự án qua các vòng lặp gọi là “sprints”, thường kéo dài từ 2 đến 4 tuần. Nó yêu cầu các nhóm làm việc nhanh chóng và liên tục cải tiến sản phẩm.
Kanban: Kanban sử dụng bảng để quản lý công việc và tối ưu hóa quy trình bằng cách giới hạn số lượng công việc đang thực hiện đồng thời. Nó giúp cải thiện hiệu suất và giảm thiểu thời gian hoàn thành công việc.
Extreme Programming (XP): XP nhấn mạnh vào việc cải thiện chất lượng phần mềm qua các kỹ thuật như lập trình đôi (pair programming) và phát triển dựa trên kiểm thử (test-driven development).
Lean Software Development: Được lấy cảm hứng từ sản xuất Lean, phương pháp này tập trung vào việc giảm lãng phí và tối ưu hóa quy trình phát triển phần mềm để tạo ra giá trị tối đa cho khách hàng.
Crystal: Crystal là một phương pháp linh hoạt, điều chỉnh quy trình phát triển dựa trên quy mô và mức độ rủi ro của dự án. Nó phù hợp với các dự án có nhu cầu và tình huống đa dạng.
Feature-Driven Development (FDD): FDD tập trung vào việc phát triển các tính năng cụ thể từ góc nhìn của người dùng cuối, với sự chú trọng vào việc lập kế hoạch và triển khai các tính năng chính trong sản phẩm.
Cùng tìm hiểu chi tiết hơn về Scrum – Phương pháp Agile phổ biến nhất hiện nay:
Scrum là gì?
Scrum là một “bộ khung làm việc” cơ bản để tiếp cận những công việc phức tạp. Dựa trên bộ khung này, nhóm làm việc có thể áp dụng những quy trình, kỹ thuật khác nhau cho công việc của mình… Nó là một thành viên của họ Agile.
Credit: Scrum.org
Scrum có ích gì cho phát triển phầm mềm hiện nay
Nó giúp loại bỏ những công đoạn phức tạp và chỉ tập trung vào những công đoạn cần thiết đáp ứng được nhu cầu của khác hàng đưa ra. Ba yếu tố nòng cốt tạo thành một mô hình quản lý tiến trình thực nghiệm gồm: sự minh bạch (transparency), thanh tra (inspection) và thích nghi (adaptation).
Ba giá trị cốt lõi của Scrum
1. Minh bạch
Muốn áp dụng thành công Scrum, các thông tin liên quan đến quá trình phải mình bạch và thông suốt. Các thông tin có thể là tầm nhìn của sản phẩm, yêu cầu của khách hàng, tiến độ công việc, các rào cản khác…
Từ đó mọi thành viên ở vai trò khác nhau có đầy đủ thông tin cần có để tiến hành quyết định trong việc nâng cao hiệu quả công việc.
2. Thanh tra
Phải thường xuyên thanh tra các hoạt động trong Scrum và tiến độ đến đích để phát hiện các bất thường không theo ý muốn. Tần suất thanh tra không nên quá dày để khỏi ảnh hưởng đến công việc. Công tác thanh tra khi được thực hiện bởi người có kĩ năng tại các điểm quan trọng của công việc sẽ giúp cải tiến liên tục trong Scrum.
3. Thích nghi
Scrum mang lợi thế là tính linh hoạt rất cao, nhờ đó mang lại tính thích nghi cao. Dựa vào thông tin liên tục và minh bạch từ quá trình thanh tra và làm việc, Scrum có thể cho lại các thay đổi tích cực, nhờ đó mang lại thành công cho dự án.
Lợi ích mà Scrum mang lại
Tính minh bạch, kiểm tra, và thích nghi là 3 nền tảng cơ bản của Scrum. Và dưới đây là những lý do tại sao nên dùng Scrum.
Cải thiện chất lượng phần mềm, dễ học và dễ sử dụng.
Rút ngắn thời gian phát hành phần mềm, cho phép khách hàng sử dụng sản phẩm sớm hơn.
Nâng cao tinh thần đồng đội, tối ưu hóa hiệu quả và nỗ lực của đội phát triển.
Gia tăng tỷ suất hoàn vốn đầu tư (ROI)
Tăng mức độ hài lòng của khách hàng
Kiểm soát dự án tốt, cải tiến liên tục
Giảm thiểu rủi ro khi xây dựng sản phẩm
Các khái niệm cơ bản Scrum
1. Scrum Team
Scrum team chia làm 3 vai trò bao gồm những thành phần sau:
Product Owner: Nhiệm vụ của Product Owner là đảm bảo việc quản lý những công việc còn tồn đọng (Product backlog) của việc phát triển sản phẩm phần mềm. Product Owner phải liên tục cập nhật thông tin cho các thành viên trong team để họ hiểu về yêu cầu hay các tính năng cần có của sản phẩm ngay cả khi họ không trực tiếp phát triển tính năng đó.
Development Team: là những lập trình viên sẽ tham gia vào việc phát triển từng tính năng cụ thể. Các lập trình viên này có thể sẽ có kỹ năng khác nhau và một số sẽ giỏi về những kỹ năng nhất định. Tuy nhiên khi sử dụng Scrum thì tất cả các thành viên của Development Team yêu cầu phải có khả năng làm việc thay thế vị trí của nhau và không ai chỉ chịu trách nhiệm phát triển một (hoặc một số) tính năng nhất định.
Scrum Master: sẽ chịu trách nhiệm cho việc lên kế hoạch để phân công công việc, sắp xếp thứ tự ưu tiên giải quyết những công việc tồn đọng nào có trong Backlog trước, tổ chức các buổi họp với Product Owner để theo dõi tình hình và nắm thông tin cần thiết.
2. Sprint
Sprint là mộ phân đoạn lặp đi lặp lại trong quy trình phát triển phần mềm, có khung thời gian thường là 1 tháng (từ 1 – 4 tuần) mà theo đó sản phẩm sẽ được release phiên bản mới. Khi một Sprint kết thúc thì Scrum Master cần phải chuyển trạng thái của nó sang Done.
Khi bắt đầu một Sprint thì Scrum Master cần đưa ra mục tiêu của Sprint đó và mục tiêu này không được phép thay đổi cho tới khi Sprint hoàn thành. Tuy nhiên Product Owner vẫn có quyền huỷ một Sprint trước thời hạn kết thúc của nó.
Mặc dù để làm điều này thì Product Owner cần sự đồng thuận của Development Team cũng như Scrum Master. Sau khi một Sprint kết thúc thì các bên sẽ dựa trên kết quả của Sprint đó để lên kế hoạch cho Sprint tiếp theo.
3. Sprint Planning
Đây là bước đầu tiên cần phải thực hiện trước khi một Sprint bắt đầu. Development team họp với Product Owner để lên kế hoạch cho một sprint. Những công việc nào cần phải được hoàn thành trong Sprint này và làm sao để có thể hoàn thành những công việc này.
Sau khi thống nhất được số lượng công việc, thời gian hoàn thành thì chúng ta có thể bắt đầu Sprint. Trong khi thực hiện một Sprint chúng ta sẽ phải có những buổi họp được gọi là Daily Sprint hay Daily Meeting.
4. Daily Sprint
Các buổi họp Daily Sprint thường kéo dài khoản 15 phút, trong buổi họp này tất cả các thành viên sẽ lần lượt báo cáo lại:
Những gì họ đã làm được ngày hôm qua
Những gì họ cần làm ngày hôm nay
Những khó khăn mà họ gặp phải
Mỗi buổi họp này sẽ giúp việc dự kiến được kế hoạch đưa ra trong Sprint đang làm sẽ tiến triển ra sao và liệu có cần phải cập nhật lại bản kế hoạch đã đưa ra hay không. Tất nhiên cần nhớ rằng việc thay đổi kế hoạch này không bao gồm thay đổi mục tiêu đã đưa ra của Sprint.
Ví dụ bạn có thể tăng thêm thời gian để hoàn thành một chức năng và qua đó khiến Sprint phải kéo dài hơn dự kiến. Tuy nhiên mục tiêu của Sprint là cho phát hành một phiên bản mới cần được giữ nguyên.
5. Sprint Review
Là công việc được thực hiện bởi nhóm phát triển và product owner ở cuối mối Sprint nhằm đánh giá lại kết quả thực hiện được. Từ lúc Sprint mới hoàn thành và qua đó đưa ra những chỉnh sửa, thay đổi cần thiết ở Sprint sau.
6. Sprint Restrospective
Dưới sự trợ giúp của Scrum master, team phát triển sẽ tổng kết những kiến nghị và đánh giá từ bước Sprint Review ở trên để đưa ra những cải tiến nhằm nâng cao hiệu quả làm việc cũng như sản phẩm.
Scrum sử dụng các công cụ rất đơn giản nhưng hiệu quả để trợ giúp công việc.
Product backlog
Đây là danh sách ưu tiên các tính năng (feature) hoặc đầu ra khác của dự án. Có thể hiểu như là danh sách yêu cầu (requirement) của dự án.
Product Owner chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục (Product Backlog Item) trong Product Backlog dựa trên các giá trị do Product Owner định nghĩa (thường là giá trị thương mại – business value).
Sprint backlog
Đây là bản kế hoạch cho một Sprint; là kết quả của buổi họp lập kế hoạch (Sprint Planning).
Với sự kết hợp của Product Owner, nhóm sẽ phân tích các yêu cầu theo độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục trong Product Backlog dưới dạng danh sách công việc (TODO list).
Burndown Chart
Đây là biểu đồ hiển thị xu hướng của dự án dựa trên lượng thời gian cần thiết còn lại để hoàn tất công việc.
Burndown Chart có thể được dùng để theo dõi tiến độ của Sprint (được gọi là Sprint Burndown Chart) hoặc của cả dự án (Project Burndown Chart).
Biểu đồ burndown không phải là một thành tố tiêu chuẩn của Scrum theo định nghĩa mới, nhưng vẫn được sử dụng rộng rãi do tính hữu ích của nó.
Các công cụ quản lý dự án theo Agile mà bạn nên biết
Trello
Trello là một trong những ứng dụng quản lý dự án nổi tiếng và được sử dụng nhiều nhất. Nó có cả tài khoản miễn phí và cao cấp mang đến cho bạn cơ hội tuyệt vời để sử dụng hầu hết các chức năng phổ biến.
Cấu trúc của Trello dựa trên phương pháp kanban. Tất cả các dự án được đại diện bởi các bảng, có chứa danh sách. Mọi danh sách đều có các thẻ lũy tiến mà bạn được tạo dưới dạng kéo và thả. Người dùng có liên quan đến bảng, có thể được gán cho thẻ.
Tóm lại, nó có nhiều tính năng hay, nhỏ nhưng không kém phần hữu ích: viết bình luận, chèn tệp đính kèm, ghi chú, ngày đáo hạn, danh sách kiểm tra, nhãn màu, tích hợp với các ứng dụng khác, v.v. Ngoài ra, Trello được hỗ trợ bởi tất cả các nền tảng di động. Trello là công cụ có thể được sử dụng cho cả công việc và các quy trình cá nhân.
JIRA
JIRA là một công cụ được phát triển để theo dõi lỗi, theo dõi vấn đề và quản lý dự án cho các quy trình phát triển phần mềm và di động. Bảng điều khiển JIRA có nhiều chức năng & tính năng hữu ích có thể xử lý các vấn đề khác nhau một cách dễ dàng.
Một số tính năng và sự cố chính: loại sự cố, quy trình làm việc, màn hình, trường, thuộc tính vấn đề. Một số tính năng bạn sẽ không tìm thấy ở nơi khác. Bảng điều khiển trên JIRA có thể được tùy chỉnh để phù hợp với quy trình kinh doanh của bạn.
Asana
Asana là công cụ quản lý công việc cho phép các nhóm chia sẻ, lập kế hoạch, tổ chức và theo dõi tiến trình của các nhiệm vụ mà mỗi thành viên đang thực hiện. Nó đơn giản, dễ sử dụng và miễn phí cho tối đa 30 người dùng trong một nhóm.
Như tất cả các nền tảng phần mềm quản lý dự án Agile trước đây với mục tiêu chính là cho phép quản lý các dự án và nhiệm vụ. Điều đáng chú ý là bạn không cần phải có email để sử dụng Asana. Mỗi nhóm có thể tạo nơi làm việc sẽ chứa các dự án và nhiệm vụ của dự án: mỗi tác vụ có thể có ghi chú, nhận xét, tệp đính kèm và thẻ.
Công cụ này có thể được sử dụng cho các quy trình nhỏ và cho các quy trình lớn mà không có bất kỳ giới hạn nào trong các ngành hoặc bộ phận.
Cleeksy
Cleeksy là một phần mềm quản lý dự án chú trọng vào cộng tác và làm việc hiệu suất cao trong thời kỳ số, đã có mặt trên cả giao diện desktop và di động. Cleeksy cung cấp tính năng quản lý dự án theo sprint cho những team đang hoạt động theo phương pháp Agile (Kanban, Scrum…). Từ đó, bạn dễ dàng tạo và quản lý các backlog dự án, chia nhỏ thành các sprint ngắn hạn, bám sát tình hình thực tế, linh hoạt điều chỉnh để đáp ứng tốt hơn những thay đổi trong yêu cầu của khách hàng và thị trường.
Đối với các team làm remote hay hybrid, team cũng dễ dàng cộng tác liền mạch trên 1 nền tảng khi dễ dàng giao-nhận việc và thực thi, phê duyệt, trao đổi, báo cáo trong những buổi retro và rút gọn thời gian làm các đầu việc thủ công bằng tự động hoá.
Bạn có thể bắt đầu 30 ngày dùng thử miễn phí nền tảng vận hành doanh nghiệp Cleeksy không giới hạn tính năng. Phiên bản FREE không giới hạn thời gian.
Resource cho bạn tìm hiểu về Agile và Scrum:
Việc làm, tuyển dụng Agile: Có rất nhiều tại TopDev với mức lương cực hấp dẫn.
Scrum.org: đầy đủ kiến thức cơ bản, nâng cao về Scrum và các chứng chỉ Scrum.
Agile Manifesto: cơ bản về Agile, tuyên ngôn Agile cho người mới bắt đầu.
Bạn cần lưu ý rõ điều này Agile không phải là “một phương pháp” mà là tư duy, cách tiếp cận, là tập hợp những phương pháp, sự thực hành dựa trên những giá trị và nguyên tắc nêu ra trong bản tuyên ngôn Agile.
Bước vào Ekino nghĩa là bạn gia nhập đội ngũ làm việc với cuộc cách mạng kỹ thuật số trong các công ty khởi nghiệp cũng như các tập đoàn lớn.
Ekino đang tham gia vào các dự án cho khách hàng châu Âu và khách hàng châu Á, như AccorHotels, BNP Paribas, ACB, Arval, Carmignac, Volkswagen, Bolloré Logistics … hỗ trợ khách hàng của mình, từ các công ty lớn đến các công ty khởi nghiệp, trong việc tạo ra hoặc chuyển đổi mô hình kinh doanh của họ trong kỷ nguyên kỹ thuật số. Khách hàng lựa chọn Ekino vì sự chuyên môn sâu về kỹ thuật số và trên tất cả là sự gắn kết và chuyên nghiệp trong đội ngũ.
Ekino tin tưởng rằng sự phát triển của bạn và công ty luôn đồng hành với nhau. Do đó Ekino tạo điều kiện cho khát vọng nghề nghiệp của Technical Project Manager: Tại đây, không có con đường được định sẵn. Nguyên tắc quản lý dựa trên sự tin tưởng, tự chủ, tự do để thử nghiệm các ý tưởng của bạn, để bạn rút kinh nghiệm và cải thiện tốt hơn từ những sai lầm.
Trải nghiệm ngày hôm nay, công nghệ ngày mai – cơ hội mở rộng dành cho các Technical Project Manager (Agile, Waterfall)
Năm 2013, Ekino xây dựng đội ngũ chuyên gia kỹ thuật tại Việt Nam, cùng hợp tác với các trụ sở Ekino khác của Ekino trên toàn thế giới để cung cấp những giải pháp phù hợp nhất đến khách hàng. Năm 2015, Ekino gia nhập Tập đoàn Havas để tăng cường giải quyết những thách thức kỹ thuật số mà các thương hiệu phải đối mặt ngày nay. Đóng vai trò quan trọng trong việc thúc đẩy sự phát triển của tập đoàn Havas, cùng với những nỗ lực không ngừng, năm 2016, trụ sở Ekino tại Pháp được công nhận là một trong những nơi tuyệt vời nhất để làm việc.
Tính đến nay, Ekino đã có kinh nghiệm hơn 10 năm trong ngành, 7 văn phòng trên toàn thế giới và hơn 500 nhân tài giàu kinh nghiệm và đam mê với kỹ thuật. Hiện nay, Ekino tại Việt Nam chào đón các Technical Project Manager tham gia vào đội ngũ để có cơ hội cùng trải nghiệm:
Là cầu nối giao tiếp chính với khách hàng, chuyên gia tư vấn kỹ thuật từ Pháp để đảm bảo rằng các dự án đáp ứng yêu cầu và sự hài lòng của khách hàng;
Phối hợp với Trưởng nhóm kỹ thuật trong việc giải quyết các vấn đề kỹ thuật dự án;
Phối hợp với nhóm kiểm thử phần mềm để xác định / điều chỉnh quy trình phát triển phần mềm;
Phối hợp với nhóm quản trị hệ thống CNTT để đảm bảo các dự án vận hành trôi chảy;
Hướng dẫn, huấn luyện, đánh giá hiệu suất cho các thành viên trong dự án;
Đãi ngộ, phúc lợi “có tâm và có tầm” cùng đội ngũ đam mê trải nghiệm, định hướng tương lai dẫn đầu
Vì con người là giá trị quan trọng nhất đối với Ekino, đến với Ekino đội ngũ nhân viên sẽ có cơ hội làm việc với các công nghệ mới, các dự án đầy thách thức, huấn luyện tại chỗ và các chương trình đào tạo về ngôn ngữ, kỹ thuật và kỹ năng mềm.
Đội ngũ Ekino là những người cùng niềm đam mê công nghệ, luôn tạo điều kiện cho tất cả thành viên phát triển trong môi trường thân thiện và hướng đến sản phẩm. Chính sự đam mê này là động lực giúp Ekino luôn ở vị trí dẫn đầu, thông qua tầm nhìn năng động và chia sẻ: trải nghiệm ngày hôm nay, công nghệ của ngày mai.
Giá trị con người luôn được đề cao trong đội ngũ Ekino, thành viên tại mái nhà này luôn được trao tặng những chính sách đãi ngộ hấp dẫn, đặc biệt là mức lương cạnh tranh cao hơn so với những công ty trong nước:
Offer hấp dẫn xứng đáng năng lực bản thân;
Đánh giá năng lực hằng năm để khen thưởng, công nhận những nỗ lực phát triển;
Đảm bảo chế độ BHXH, BHYT, BHTN… đầy đủ theo quy định của công ty;
Thưởng cuối năm và thưởng theo kết quả thực hiện công việc;
Cải thiện kỹ năng liên tục với các công nghệ mới, các dự án đầy thách thức, chương trình đào tạo tại chỗ;
Cơ hội làm việc tại Pháp theo yêu cầu nhiệm vụ và dự án;
Các hoạt động gắn kết tại nơi làm việc (du lịch hằng năm, câu lạc bộ thể thao …): nâng cao tinh thần làm việc nhóm và tạo điều kiện hài hòa cuộc sống và công việc của bạn.
Đừng chần chừ nữa, bạn hãy nhanh tay ứng tuyển chiếc vé để gia nhập với chúng tôi – mái nhà “Greatest Place to Work”, nơi bạn không chỉ thăng tiến trên con đường nghề nghiệp mà còn được trao tặng những trải nghiệm dẫn đầu công nghệ, tỏa sáng tiềm năng!
Có nhiều cuộc thảo luận nào là JS không theo quy tắc, không ổn định, liên tục cập nhật khiến độ ổn định không cao. Nhưng các bản thăm dò đều cho thấy Javascript thống lĩnh, có thể nói rằng ngôn ngữ này đang là Fullstack nhất, nào là server side, client side, mobile app thậm chí là desktop app (VS Code là một ví dụ điển hình nhất). Vì vậy, ngưng lo ngại và hãy yêu quý nó!
Các bản update lớn sẽ được ra cẩn trọng hơn
ES6 quá lớn để cộng đồng ECMAScript quyết định cho ra các bản release nhẹ nhàng hơn. Đây là lí do mà ES6 cũng được gọi là ES2015, và đây là bản release đầu tiên của năm này – từ nay năm nào cũng sẽ có release. Nó dễ nắm bắt hơn, hiệu năng cao hơn và dễ sử dụng.
Có lẽ bạn follow rất nhiều người trên Facebook. Một số leader chia sẻ sắp đến sẽ có xu hướng gì, và thế là mọi người đều đổ xô dùng nó. Có thể họ thích hiển thị các snippet dùng các API mới nhất mà không giống với tiêu chuẩn.
Có lẽ họ có lí do riêng. Bạn thì không. Đừng rơi vào cái bẫy của những thứ lấp lánh, và tập trung vào công việc.
Không phải tuần nào cũng có framewok mới đâu
Có nhiều lời đồn thổi rằng “sẽ có library mới hằng tuần”. Điều đó đúng, có cả triệu người đang sử dụng JavaScript và nó rất tuyệt vời, mang đến sự cải tiến, bởi JavaScipt có cả một hệ sinh thái phong phú.
Nhưng có một thứ cần lưu ý đó là những thứ quan trọng thì không thay đổi nhiều.
React được 5 tuổi.
Vue được 4 tuổi.
4 năm là một hành trình dài trong ngành công nghệ. Chúng là các công nghệ ổn định. Học nó ngay, nó sẽ còn ở đây lâu.
Bạn vẫn còn rất nhiều thời gian để master được bất kì framework nào trên, vì chúng sẽ còn ở đây rất lâu.
Vài năm trước jQuery được dùng ở khắp nơi, giờ đây thì hiếm khi có project nào đi từ nó.
Vào năm 2013 Backbone.js rất hot. Giờ thì nó đã biến mất khỏi cuộc chơi.
CoffeeScript, dường như đã biến mất khỏi trái đất.
Ember.js, Angular.js và Meteor cũng đã xuất hiện và nổi tiếng được vài năm, giờ đây lại phải nhường ngôi cho React, Vue và Angular (hoàn toàn khác với Angular.js).
Chu kì của các framework nổi tiếng thường kéo dài khoảng vài năm. Tôi vẫn còn rất nhiều app Ember.js hoạt động còn tốt, và không cần phải update nếu chúng làm tốt việc của mình, và tôi cũng không có ý định đụng nó.
Công nghệ phát riển rồi trưởng thành, rồi nó sẽ dần quen với sự nổi tiếng và yếu dần.
Nếu bạn sử dụng jQuery, bạn không hề ngốc
Nếu bạn đọc đủ nhiều, bạn master 1 framework nào đó, bạn sẽ biến công việc trở nên dễ dàng. Những người không hiểu sâu sẽ luôn muốn chúng ta thay đổi này nọ.
Sau khi đã sử dụng PHP, tôi đã quen với việc người ta chê bai một cái gì đấy về ngôn ngữ này. Thậm chí đến Go, nổi tiếng về sự đơn giản dễ dùng của nó cũng bị người đời chê bai đến lên bờ xuống ruộng.
Để bạn dễ hình dung, tôi sẽ trích một tweet của Pieter Levels, người đã gây dựng cơ nghiệp chỉ nhờ một file PHP.
Nhưng nếu là ma mới, và bạn nghe rằng ai đó nói bạn đã chọn một tool cũ, thì bạn nên xài React thay thế.
Hãy lờ nó đi.
Chỉ cần nhớ rằng: cái gì hỗ trợ bạn tốt, thì nó là sự lựa chọn đúng đắn.
Nếu nó hỗ trợ tốt cho bạn, thì nó là của bạn.
Đa số thì công nghệ được build nên bởi các ông lớn công nghệ có nhu cầu, khác với cái của bạn, hoặc của team bạn. Hãy chọn cái bạn hiểu rõ, và tạo ra sự khác biệt kể cả khi không dùng các edge tech phổ biến.
Giờ đây có lẽ bạn không cần jQuery nữa. Nhưng dưới dạng framework – thuần JavaScript sẽ rất hợp.
Một phần khác của vấn đề đó là đừng sử dụng công nghệ nào chỉ làm bạn cảm thấy thông minh hơn. Hãy hiểu nó hơn. Và học cách khi nào thì sử dụng framwork hoặc library để hỗ trợ bạn.
Bạn không có nghĩa vụ phải biết mọi thứ. Tìm điểm cân bằng cho chính mình.
Nghe cứ như một câu quote đâu đó trên Facebook, thật sự là chẳng ai biết mọi thứ cả. Không ai có thể học hết những thứ đang có về frontend development cả. Trường học này sẽ kéo dài cả cuộc đời. Chắc chắn phải có cách hợp lý để tốt nghiệp luôn bây giờ.
Chọn loại tech có tư liệu thân thiện với user
Không phải tự nhiên mà React và Vue có nguồn tư liệu tuyệt vời.
Đó là phần chủ chốt trong sự thành công của họ.
JavaScript sẽ tiến hóa lần nữa
Năm ngoái ECMAScript đã ra mắt await/async và từ đó là feature được sử dụng rất phổ biến. Code dựa trên promise trông hơi tệ, như thể bạn phải viết lại từ đầu đến đuôi.
Đừng làm thế, thay vì thế hãy sử dụng các feature mới trong code bạn viết.
Điều tương tự sẽ xảy ra trong năm nay, bằng ES2018. Mọi người sẽ nói về nó một hồi, và rồi sẽ quay lại làm việc rồi sẽ đến ES2019.
Hãy trân trọng sự thay đổi. Nó tốt hơn nhiều so với việc đặt cược vào nó rồi sa vào những cái không liên quan: JavaScript is here to stay!
Học từ những cái căn bản và tự quyết định lối riêng
Develop trên Web Platform đòi hỏi nhiều sự tìm tòi học hỏi cái mới, kể cả việc tìm xem nó có khả thi không.
Đôi khi chỉ cần học 20% thời gian của 80% những thứ bạn cần là đủ, không cần phải đào quá sâu vào những edge case.
Cuộc hành trình bắt đầu
JavaScript vẫn còn khá trẻ so với những ngôn ngữ khác, những đã rất phổ biến và đã có thể thay đổi ngọan mục trong những năm vừa qua. Hằng ngày nó đã thu nạp về rất nhiều developer tài năng, và chỉ cần tưởng tượng về nó trong vòng 20 năm tới thôi cũng thấy thú vị. Con đường nghề nghiệp của các lập trình viên Javascript thì khỏi phải bàn tới, các công ty công nghệ lớn luôn có vị trí việc làm JS lương cao ngất ngưỡng.
Thực ra thì, việc xác định ngày bắt đầu chính xác cho Mobile Gaming là điều không dễ dàng. Tuy nhiên nếu chúng ta xem nó như một ngành công nghiệp có điểm bắt đầu và kết thúc, thì đó có lẽ là năm 1997 – năm mà Snake trở thành Mobile Gaming chính thống đầu tiên trên xuất hiện trên điện thoại.
Trong thời kỳ bắt đầu, mọi người đều nghĩ điện thoại di động chỉ dùng cho việc liên lạc và kết nối, và nó việc giải trí với các trò chơi trên nó chỉ là thứ yếu sau hầu hết các PC và máy chơi game. Nhưng trong hai mươi năm qua, trò chơi di động đã chuyển từ các pixel nhấp nháy của Snake sang toàn bộ thế giới ảo được kết nối cùng lúc bởi hàng ngàn người trên toàn cầu, biến các công ty game di động thành doanh nghiệp tỷ đô trong quá trình này. Và bây giờ, chúng ta có thể nói rằng tương lai của Mobile Gaming chính là tương lai của các Trò chơi. Bây giờ, rõ ràng rằng tương lai của trò chơi di động là tương lai của trò chơi.
Vậy nên, nếu chúng ta đã có những thay đổi rất đáng kể trong 2 thập kỷ qua, vậy thì tương lai của Mobile Gaming sẽ ra sao trong 5 năm nữa? Và điều đó sẽ được trả lời thông qua loạt series mới “Future of Mobile Gaming”. Thông qua loạt bài viết này, chúng ta sẽ có cái nhìn tổng quan về từng khía cạnh cụ thể của tương lai Mobile Gaming, từ thay đổi phần cứng và triển khai 5G cho đến vai trò ngày càng tăng của công nghệ mới nổi như AI và VR. Cuối cùng là một bức tranh về tương lai mà các nhà phát triển, nhà xuất bản và những người đam mê chơi game có thể sử dụng để dự báo kế hoạch của riêng họ.
Vì vậy, nếu chúng ta đạt được điều đó trong hai thập kỷ, thì tương lai đó có gì cho trò chơi di động trong 5 năm nữa? Đó là câu hỏi mà chúng tôi sẽ trả lời trong loạt bài mới của chúng tôi, Tương lai của trò chơi di động.
Như đã đề cập ở trên, chúng ta sẽ bắt đầu câu chuyện của mình vào năm 1997, khi Snake trở thành trò chơi di động thực sự đầu tiên sau khi đưa vào điện thoại Nokia 6110. Từ đó, cơ sở hạ tầng để chơi game trên thiết bị di động đã được triển khai với việc thiết lập Giao thức Internet không dây (WiFi) trước khi ngành công nghiệp tiến một bước nhảy vọt với việc ra mắt App Store iOS vào năm 2007, theo sát là Android Market của Google ( hiện được gọi là Google Play Store).
Đến năm 2012, điện thoại thông minh ở Mỹ đã vượt qua mức chuẩn phổ biến 50% và các báo cáo dữ liệu đáng tin cậy đầu tiên về hoạt động của App Store được ghi lại. Và điều này đã thể hiện rằng ngay từ đầu, rõ ràng các nhà phát hình và xuất bản trò chơi sẽ đóng vai trò quan trọng, cùng với người chơi sẽ giúp cho Mobile Gaming phát triển trọng Vũ trụ Gaming.
Chơi game trên thiết bị di động đã dần trở thành xu hướng, nhưng mãi đến năm 2016, doanh thu trò chơi trên thiết bị di động đã vượt qua máy chơi game và PC, đưa ngành công nghiệp từ giai đoạn trứng nước đến khi trưởng thành chỉ sau 20 năm:
Đó là một chặng đường dài nhưng đầy những tín hiệu tích cực và hiệu quả, điều đó đã tạo nên 1 nền tảng vững chắc cho Mobile Gaming sẵn sàng với những bước đột phá mới.
Hiện tại của Mobile Gaming: 2017 – 2019
Mặc dù nhiều người vẫn còn nghi ngờ vị trí của Mobile Gaming trong Gaming Universe nhưng
điều đó dần đã bị loại bỏ vào năm 2017. Đáng chú ý nhất là sự nổi lên của các game Battle Royale như Fortnite và PUBG Mobile đã chứng minh rằng công nghệ cuối cùng đã phát triển đến mức trải nghiệm chơi game trên thiết bị di động giữa console / PC và di động đã gần như là một, và phần thưởng dành cho các nhà phát triển là hấp dẫn. Tính đến mùa hè năm 2018, một mình Fortnite đã thu về hơn 100 triệu đô la mỗi tháng và đó chỉ là doanh thu trực tiếp cho nhà xuất bản.
Nhưng dù các trò chơi sinh tồn tiếp tục thu được sự quan tâm, thì đó cũng chỉ là một phần trong một bức tranh của Mobile Gaming. Năm vừa qua đã chứng kiến những tựa game bom tấn mới như Harry Potter: Wizards Unite và Jurassic World Alive, báo hiệu ngành công nghiệp đã hồi sinh và đầu tư vào công nghệ mới như AR với đại diện tiêu biểu là Pokemon Go.
Đồng thời, các trò chơi hyper-casual như Love Balls và Helix Jump đã trở thành những hiện tượng theo cách riêng của họ bằng cách cung cấp trải nghiệm dễ dàng truy cập nhưng rất hấp dẫn cho người chơi trên toàn thế giới.
Chơi game trên thiết bị di động đã trở nên mạnh mẽ hơn trong giai đoạn này. Các trò chơi đã có 1 bước tiến dài vào nền văn hóa nhân loại, và tất cả dấu hiệu cho thấy ngành công nghiệp này chỉ mới bắt đầu.
Và tương lai của Mobile Gaming: 2019 – …
Đã đến lúc chúng ta hướng sự chú ý về tương lai. Đối với loạt bài này, chúng ta sẽ nói về tương lai gần, như trong năm năm tới. Với tốc độ tiến bộ đáng kinh ngạc của công nghệ, mọi dự đoán ngoài khung thời gian đó có thể không khả thi hoặc xảy ra quá nhanh.
Như đã nói, sự phát triển của khoa học dữ liệu đã giúp dự báo một cách chính xác và khả thi hơn bao giờ hết. Kết hợp điều này với chuyên môn trong ngành và kiến thức về các xu hướng chính sắp tới như triển khai 5G, một bức tranh tương lai càng rõ ràng hơn bao giờ hết. Chúng ta sẽ thấy việc chơi game tiếp tục phát huy những tiến bộ về phần cứng và mạng, cùng với những tiến bộ khác như AI, sẽ mang lại trải nghiệm cá nhân hóa cao, đưa game di động vào mọi khoảnh khắc của cuộc sống.
Nhìn chung, sự tăng trưởng ở các thị trường đã phát triển và mới nổi sẽ giúp thúc đẩy chơi game trên thiết bị di động lên tầm cao hơn nữa khi các trò chơi được dự đoán là hạng mục cao nhất cho chi tiêu của người tiêu dùng vào năm 2023. Và sau đây là một số dự đoán:
Chi tiêu tiêu dùng toàn cầu hàng năm trong các trò chơi di động lên tới 100 tỷ đô la vào năm 2021.
Tổng số thiết bị di động để chơi game lên tới 6 tỷ vào năm 2022.
APAC sẽ chiếm phần lớn tổng doanh thu trò chơi toàn cầu vào năm 2023.
Từ một trò chơi đình đám đầu tiên vào thập niên 90 đến một tương lai – nơi doanh thu trò chơi trên thiết bị di động đã vượt qua đáng kể PC và máy chơi game, đây chính là cốt lõi của ngành công nghiệp trò chơi. Và đó còn là một bước chuyển mình nhanh chóng giữa quá khứ, hiện tại và tương lai của Mobile Gaming.
Topdev Blog via applovin.com
Tháng 6 này các chuyên gia, chủ nhân của nhiều ứng dụng nổi tiếng sẵn sàng hội tụ tại Vietnam Mobile Day 2019 và truyền đạt hàng trăm bí kíp làm app tại chuỗi sự kiện thường niên được giới devs công nhận và phát triển mạnh mẽ trong 9 năm qua, đừng bỏ lỡ những giá trị hữu ích mà VMD2019 do TopDev tổ chức năm nay nhé!
Bắt đầu với những kĩ năng quan trọng nhất của thế kỉ 21.
Chúng ta ngày càng bận rộn. Có rất nhiều thứ sẽ xảy ra với cuộc sống cá nhân cũng như nghề nghiệp nhưng trên hết, vài thứ như trí thông minh nhân tạo bắt đầu thời kì phát triển và bạn sẽ nhận ra rằng các kĩ năng của bạn sẽ hết hạn trong ít nhất 2 năm tới.
“Các kiến thức và kĩ năng của một full-stack developer sẽ không bao giờ đủ khi ngữ cảnh mọi thứ thay đổi. Trong 2 năm tới đây, full-stack cũng không được gọi là full-stack nếu không có kĩ năng AI.”
Đã đến lúc phải hành động tôi tự nghĩ đến việc tự nghiên cứu AI từ đâu. Và tôi đã làm những gì tôi cho là đúng đắn – cập nhật các kĩ năng của tôi như là 1 lập trình viên, mindset của tôi như 1 người làm product và triết lí của tôi như một doanh nhân để trở thành người theo định hướng data.
Như Spiros Margaris – nhà đầu tư mạo hiểm nổi tiếng và lãnh đạo tư tưởng trong AI và Fintech đã nói với tôi “Nếu các công ty và startups chỉ dựa vào thuật toán AI và Machine Learning tiên tiến thì sẽ không bao giờ là đủ. AI không phải là một lợi thế cạnh tranh nhưng nó chắc chắn là một điều bắt buộc. Bạn đã bao giờ nghe ai đó nói rằng họ sử dụng điện lại là lợi thế cạnh tranh chưa?
Xây dựng neural network
Lời khuyên phổ biến là hãy đăng kí khóa học của Andrew Ng trên Coursera. Đây là một nơi tuyệt vời để bắt đầu nhưng tôi lại nhận thấy rất khó khăn để tỉnh táo trong thời gian dài. Tôi không nói đây là 1 khóa học tồi tệ, nhưng tôi rất tệ khi phải tập trung vào giảng viên. Cách tôi học luôn thông qua thực tiễn, vậy nên tôi nghĩ việc tự nghiên cứu AI từ đâu? tại sao không thực hiện ngay mạng lưới thần kinh của riêng mình.
Tôi không nhảy thẳng tới mạng lưới neutral bởi vì luôn có vài cách khác tốt hơn để học. Tôi đã cố làm quen bản thân với tất cả các từ trong miền để tôi có thể học nói các ngôn ngữ.
“Bài tập đầu tiên không phải là học mà là làm quen”
Với background về Javascript và NodeJS, tôi không muốn thay đổi chuyên môn của mình. Vì vậy, tôi đã tìm kiếm một module mạng lưới thần kinh tên ngôn ngữ và sử dụng nó để thực hiện một cổng AND với một input giả. Lấy cảm hứng từ hướng dẫn này, tôi chọn vấn đề là cho bất kì input X,Y và Z nào thì output cũng nên là X và Y.
var nn = require('nn')
var opts = {
layers: [ 4 ],
iterations: 300000,
errorThresh: 0.0000005,
activation: 'logistic',
learningRate: 0.4,
momentum: 0.5,
log: 100
}
var net = nn(opts)
net.train([
{ input: [ 0,0,1 ], output: [ 0 ] },
{ input: [ 0,1,1 ], output: [ 0 ] },
{ input: [ 1,0,1 ], output: [ 0 ] },
{ input: [ 0,1,0 ], output: [ 0 ] },
{ input: [ 1,0,0 ], output: [ 0 ] },
{ input: [ 1,1,1 ], output: [ 1 ] },
{ input: [ 0,0,0 ], output: [ 0 ] }
])
// send it a new input to see its trained output
var output = net.send([ 1,1,0])
console.log(output); //0.9971279763719718
Theo ý kiến của cá nhân tôi, đây là một trong những bước xây dựng thành công nhất mà tôi đã làm. Khi output đạt đến 0.9971, tôi nhận ra rằng network đã học cách để làm một hệ thống AND và phớt lờ các input bổ sung của mình.
Đây là lí do chính của Machine Learning. Bạn đưa máy tính một set data và nó điều chỉnh các thông số nội bộ để đạt được khả năng trả lời câu hỏi trên dữ liệu mới trong khi lỗi được giảm đi từ cách máy tính quan sát từ dữ liệu gốc
Sau này tôi mới biết phương pháp này được gọi là Gradient descent.
Chuẩn bị kĩ càng cho trí tuệ nhân tạo
Một khi đã tràn đầy tự tin sau khi làm xong chương trình trí tuệ nhân tạo đầu tiên, tôi muốn biết mình có thể làm gì hơn với machine learning với tư cách là một developer.
Sử dụng data một cách hạn chế để dự đoán đội nào sẽ tháng một IPL match cho trước sử dụng multivariate linear regression. (Các dự đoán không tốt lắm nhưng nó cũng rất tuyệt)
Sau đó thực hiện rất nhiều demo trên Google Machine Learning cloud để xem AI có thể làm những gì (nó tốt đủ để Google thực hiện như một sản phẩm của SaaS)
Tôi còn tình cờ biết được AI Playbooks, một resource khá tốt bởi Andreessen-Horowits, quỹ đầu tư mạo hiểm. Thật sự là một những resources tiện dụng nhất cho developers và doanh nhân
Tôi có đọc được post này của Hackernoon về cách các showrunners tại Silicon Valley built Not HotDog app. Đây là một trong những ví dụ dễ tiếp cận nhất của deep learning mà chúng ta có thể làm.
Cộng thêm blog của Andrej Karpathy – Giám đốc AI của Tesla. Mặc dù tôi không hiểu nhiều và cảm thấy nhức đầu, tôi nhận thấy là sau khi cố gắng tìm hiểu nhiều lần nữa tôi cuối cũng cũng có thể hiểu được một vài khái niệm
Với một vài lời động viên, tôi bắt đầu thực hiện một vài hướng dẫn nguyên văn của deep learning (Copy & Paste) và cố gắng train model và run code trên machine của tôi. Đa số đều thất bại bởi vì đa số các model đều tốn thời gian training cao và tôi không có một cái GPU
Toàn bộ quy trình này được tập trung xung quanh việc tiêu thụ thụ động content và xây dựng tài liệu tham khảo trong tâm trí của bạn để lúc sau tôi có thể sử dụng khi khách hàng thực sự của tôi gặp vấn đề.
Là một fan cứng của bộ phim Her, tôi muốn build chatbots. Tôi đã chấp nhận thử thách và xoay sở để build một con sử dụng Tensorflow trong ít hơn 2 tiếng. Tôi đã vạch ra kế hoạch chuyến đi này ở một trong các bài viết của tôi nhiều ngày trước.
May mắn là bài viết này được viral rất tốt và được đề cử tại TechinAsia,CodeMentor và KDNuggets. Cá nhân tôi cảm thấy rất vinh hạnh về điều đó vì tôi chỉ mới bắt đầu viết Tech Blog thôi. Nhưng tôi nghĩ bài biết đó là một trong những đánh dấu trong sự nghiệp học hỏi về AI của tôi.
Tôi đã kết bạn được với rất nhiều người trên Twitter và Linkedin với những người mà tôi có thể hỏi cách tự nghiên cứu AI từ đâu, bàn luận về AI sâu và rộng và thậm chí có thể thoát khỏi những thứ tôi đã từng bị rối. Tôi đã nhận được một vài lời đề nghị để thực hiện ác dự án tư vấn và phần tuyệt vời nhất là các bạn lập trình viên trẻ và người mới bắt đầu AI đã bắt đầu hỏi tôi về cách tôi bắt đầu AI như thế nào.
Điều mang tôi tới việc viết bài này là để giúp mọi người tham khảo kinh nghiệm của tôi và bắt đầu nhưng dự án của chính họ.
“Bắt đầu là một trong những phần thách thức nhất của bất kì hành trình nào”
Salt & Pepper
Điều này thực sự không dễ dàng khi bắt đầu hiện thức hóa câu hỏi tự nghiên cứu AI từ đâu? Khi tôi bắt đầu cảm thấy bế tắc với Javascript, tôi nhảy sang Python và mất cả đêm để tìm cách code. Tôi bắt đầu hơi kích thích khi các mẫu của tôi không train được trên máy i7 hoặc sau nhiều giờ trainning, chúng sẽ trả về các kết quả mập mờ như khả năng thắng 50-50 của 1 trận Cricket. Học về AI không giống như học về một web framework.
Đó là một kĩ năng mà yêu cầu nhận thức về mọi thứ ở mức độ tính toán cực nhỏ và tìm kiếm ra cái gì quan trọng hơn với output của bạn – code hay data của bạn.
AI cũng không phải chỉ là một môn học. Nó là một cụm từ sử dụng cho mọi thứ từ vấn đề hồi qui đơn giản đến robot sát nhân sẽ giết chúng ta một ngày nào đó. Giống như mọi quy luật chúng ta phải tuân theo, có thể bạn sẽ muốn cherry-pick những vấn đề của AI mà bạn muốn giỏi như Computer Vision, hay Natural Language Processing hay God Forbid, thống trị thế giới.
Trong một cuộc trò truyện với Gaurav Sharma từ Atlantis Capital, một người leader có danh tiếng trong lĩnh vực AI, Fintech và Crypto, anh ấy tâm sự với tôi rằng:
Trong thời kì của trí tuệ nhân tạo, “trở nên thông minh” sẽ mang một ý nghĩa hoàn toàn khác. Chúng ta cần con người thể hiện một tư duy cao cấp hơn, sáng tạo và suy nghĩ và các công việc yêu cầu sự ràng buộc về cảm xúc cao.
Việc các máy tính nhanh chóng học cách làm việc bằng chính bản thân nó sẽ làm bạn phấn khích vô cùng. Kiên nhẫn và luôn tự chất vấn bản thân là 2 nguyên lí quan trọng mà bạn nên nhớ.
Đây là một hành trình rất rất dài hơi, rất mệt mỏi, kiệt sức và tốn thời gian ngoài ý muốn.
Nhưng phần tốt là, như mọi hành trình trên thế giới, hành trình này cũng bắt đầu từng bước một.
Nếu như một ngày, bạn thức dậy và quyết tâm trở thành một nhà văn giỏi, bạn chắc hẳn đã nghe tới 2 lời khuyên: viết thật nhiều vào và đọc nhiều hơn cả viết nữa.
Trong lập trình, nhiều người viết code nhưng hiếm có người dành thời gian đọc code, đặc biệt là những dòng code ngoài phần công việc của họ. Đó thật sự là một sai lầm lớn. Khi còn chưa muộn, hãy hành động giống như một coder đầy tham vọng và đọc thật nhiều code vào.
Đọc nhiều và đọc thường xuyên là điều khác biệt giữa một software engineer bình thường và một software engineer giỏi.
Tại sao tôi phải đọc code?
Những nhà văn vĩ đại đều học từ những nhà văn mà họ đã từng đọc. Ví dụ như Joan Didion, người đã viết những câu trong Hemingway ở tuổi 16 để học cách viết câu. Hay như Abraham Lincoln, người đã làm thơ trữ tình dựa trên cuốn kinh thánh King James mà ông yêu thích.
Tương tự như thế, nhìn nhiều code thực tế sẽ mở mang kiến thức của bạn để có thể tự viết code. Đọc code của người khác sẽ thấy được chức năng của các ngôn ngữ lập trình mới và nhiều thể loại code khác nhau.
Đọc dependencies của bạn sẽ giúp bạn làm việc năng suất hơn. Bạn sẽ biết được đầy đủ chức năng mà dependencies của bạn cung cấp. Bạn sẽ biết chính xác cách chúng hoạt động và chúng đang tradeoff cái gì. Bạn sẽ biết nơi để debug khi có lỗi xảy ra.
Đọc code một cách thoải mái cũng hạn chế bớt sự “ảo tưởng” đối với code của chính bạn. Bạn đọc càng nhiều, bạn càng cảm thấy code của người khác thú vị, thì bạn càng muốn làm code của bạn tốt hơn. Sự thay đổi này sẽ làm giảm khả năng bạn bị mắc hội chứng “not invented here”.
Chú thích: “Hội Chứng Not InventedHere” là khuynh hướng của một nhóm chủ thể quá tin tưởng vào những kiến thức độc đoán trong lĩnh vực của mình, từ đó chối bỏ những ý tưởng mới từ cá thể bên ngoài, đến mức tổn hại cả năng lực hoạt động của chính bản thân nó.
Nếu bạn là một người lập trình web, một data engineer hay một nhà mật mã học, trau dồi việc đọc thường xuyên sẽ dạy bạn các công cụ và sản phẩm khác với những công việc thường ngày của mình.
Đối với một web front-end, đọc một phần nhỏ codebase của raytracer sẽ đưa bạn đến một loạt các ràng buộc khác nhau. Đối với một database engineer, đọc code web trừu tượng cao có thể cho bạn biết người dùng của mình đang nghĩ gì. Còn đối với tất cả các kỹ sư phần mềm, bạn sẽ tìm được giá trị trong việc đọc ngôn ngữ lập trình khác với ngôn ngữ mà bạn đang dùng.
Như Donald Knuth nhấn mạnh: “đọc code thực sự đáng giá vì những thứ nó đem lại. Bạn đọc càng nhiều code từ người khác, bạn càng có khả năng phát minh ra nhiều thứ trong tương lai…”
Dưới đây là cách đọc code “không đau đớn” và năng suất nhất có thể dành cho bạn.
Hướng dẫn đọc code
Tiếp cận một nguồn code như cách mà bạn đọc một cuốn sách – Đọc từ đầu đến cuối – và nó thường không thành công (trớ trêu thay đây lại là cách duy nhất máy tính tự đọc code)
Đọc từ đầu nghĩa là bỏ qua context quan trọng và không có ý nghĩa đối với cấu trúc sau này. Đọc thụ động – bạn sẽ không thể kiểm tra hoặc sửa lỗi – sẽ cản trở bạn thực sự đi sâu vào các dòng code.
Không giống một cuốn sách, hầu hết những người bạn của mình đấu tranh để đọc code mà không có mục tiêu cụ thể. Trước khi đọc một codebase mới, hãy chắc chắn rằng bạn có mục tiêu muốn đạt được. Điều này sẽ làm cho codebase trở nên dễ quản lý hơn và tạo động lực để vượt qua khi bạn thấy nó khó quá.
Mình sử dụng phương pháp RSDW để đọc bất cứ codebase khó hiểu nào:
Run: dịch, chạy thử và hiểu code đang làm gì
Kiểm tra Structure: học cấu trúc level cao và xem các bài test tích hợp quan trọng.
Dive in: theo các luồng chính và đọc các cấu trúc dữ liệu quan trọng.
Write tests: Viết thử và ưu tiên các tính năng đơn giản và sửa lỗi.
Phương pháp RSDW chỉ là khởi động, nhưng về sau, bạn nên tự tìm cách riêng cho mình. Một vài người thề chỉ viết test và sửa lỗi, trong khi người khác luôn thích bắt đầu bằng việc xem các test tích hợp trước.
Thôi thì quay lại với phương pháp RSDW của mình nhé.
Run
Bước đầu trong việc đọc code không hẳn là đọc cho lắm. Chúng ta cần phải sử dụng phần mềm.
Đọc code chỉ khi bạn hiểu chức năng phần mềm cung cấp. Trong giai đoạn này, bạn nên nhìn tổng quan code và hiểu input và output có gì.
Sử dụng phần mềm bắt bạn phải làm nó chạy. Điều đó cũng có nghĩa là theo dõi các dependencies và, đối với một vài ngôn ngữ nhất định là phải dịch code. Đối với các thư viện, nó có nghĩa là gọi một vài chức năng phổ biến. Đây là thời điểm chạy thử nghiệm và xem các thông báo đầu ra.
Nếu bạn gặp vấn đề khi hệ thống chạy lần đầu, đó là thời điểm tốt nhất để ghi lại cho người khác cần những gì để chạy phần mềm.
Tiếp đến là xác định các phần quan trọng nhất của code. Quá trình này khác xa so với việc đọc sách. Thay vì bắt đầu lúc bắt đầu, bạn phải đi xung quanh để tìm các mối quan hệ chính trong code.
Bắt đầu với việc hiểu cấu trúc của code. Tối thiểu có thể chạy một vài tool tự động (như tree và cloc) để tìm ra ngôn ngữ và file của codebase.
Để xác định các file chính, nhìn vào các file nhiều sửa đổi nhất và sử dụng bất kỳ tool nâng cao nào khác cũng được. Xem lại các bài test tích hợp quan trọng, liệt kê các chức năng có thể gọi tên. Đánh dấu các bài test này để sau.
Có 1 cách dễ dàng để rút ngắn quá trình này: Tìm một ai đó đã từng làm việc với loại code này trước đây.
Hiểu cấu trúc là nhiệm vụ đầu tiên cho việc đọc code.
Deep Dives
Khi bạn đã có đất rồi, thì đào thôi.
Khi đọc code, bạn nên nhìn vào code flow (Nhìn các action đang được tạo ra) và cấu trúc dữ liệu / các đối tượng (nơi mà kết quả chạy được lưu trữ)
Chọn từ 3-5 dòng quan trọng bạn thấy từ bài test tích hợp chính, PRs quan trọng hoặc lúc bạn xem lại tệp nguồn. Sau đó đào sâu hơn. Bắt đầu từ đỉnh của một action đặc biệt và cứ đi theo các dòng code. Một vài lập trình viên thích dùng các trình gỡ lỗi. Những người khác thì thích tạo sơ đồ UML hay đồ thị flame hơn.
Lần khác mình sẽ dừng tại điểm smack dab ở giữa một chức năng quan trọng, và tìm cách đi đến stack để hiểu cách làm sao mình đến được đó. Nếu bạn quyết định làm theo code một cách thủ công, nhớ thiết lập sẵn trình soạn thảo của bạn cho phép bạn sử dụng “go to definition” và “find all references” một cách nhanh chóng.
Đối với cấu trúc dữ liệu, xem lại loại dữ liệu và khi nào các biến chính được bật. Sử dụng trình gỡ lỗi để truy vấn những cấu trúc dữ liệu này vào những thời điểm quan trọng.
Ngoài các bài test tích hợp, cách tốt để tiếp cận một codebase mới chính là review lại các pull request quan trọng. PRs thường dễ hiểu hơn, vì chúng gói gọn trong một tính năng tách biệt. PRs cũng cung cấp nền tảng narrative ngoài lý do và cách bổ sung code.
Trong quá trình đào sâu này, mình mở 2 doc markdown. Doc đầu là “level up my coding” nơi mình liệt kê các cú pháp mới mà mình thấy và các mẫu code mình thích khi tự học (người khác gọi nó là bảng kê). Cái doc thứ 2 để liệt kê các câu hỏi quan trọng mình dành cho những lập trình viên của codebase mình đang đọc. Ở giai đoạn này, mình cũng thêm vào documentation khi tôi thấy gaps.
Quá trình deep dives này thường sẽ hiệu quả hơn nếu bạn thực hiện cùng với một người nào đó biết về code. Nếu mình chỉ có ít thời gian với một lập trình viên trên project, mình luôn để họ theo dõi mình qua các flow chính. Khi mình đã hiểu căn bản một ít dòng chính, sẽ dễ dàng hơn khi mình tự đào.
Không giống trong văn chương, nơi đọc và viết là 2 cái tách biệt, một phần quan trọng của đọc code chính là viết code. Nếu không viết code, bạn không thể hiểu được một codebase. 2 cách tiếp cận dễ dàng để bắt đầu là viết test và giải quyết các feature/bug.
Viết test thử là một hình thức đọc tích cực, bắt bạn phải chú ý đến input và output của một tương tác cụ thể. Viết code giúp hằn sâu code trong đầu bạn – cái mà việc đọc không thôi thì không thể làm được.
Đối với mình, test từng phần là cách dễ dàng để bắt đầu. Khi mình thành thạo một số base, mình có thể chuyển sang test tích hợp để hiểu hơn về codebase. Thỉnh thoảng mình sẽ viết lại một test tích hợp đã có, để thử xem mình có hiểu cách một call quan trọng hoạt động hay không.
Một cách tiếp cận khác dễ dàng hơn đó là viết tính năng đơn giản hoặc address những lỗi dễ. Cả 2 cách này không yêu cầu bạn phải có kiến thức đầy đủ về codebase, nhưng vẫn bắt bạn phải “đối đầu” với code. Đóng góp cách sửa bug và tài liệu liên quan cũng là một cách dễ dàng để trả lại dependencies.
Những phương pháp này giúp bạn nhanh chóng hoàn thành khi bận đang cần. Bằng cách áp dụng RSDW nhiều hơn với một vài bài học mở rộng, việc đọc code sẽ đỡ khó khăn hơn nhiều.
Một vài tips đọc
Phương pháp RSDW không phải là duy nhất. Các engineer có thể tìm ra cách riêng mà họ thích để đào sâu vào một codebase mới (Quá trình đọc cũng thay đổi đáng kể tuỳ theo ngôn ngữ, các tool có sẵn và loại codebase bạn đang muốn)
Mặc dù vậy, phương pháp RSDW cũng là cách tiếp cận tốt khi bạn thấy code mới. Nó cũng kích thích sự thú vị khi đọc code, có thể là viết test hoặc chủ động sử dụng một trình gỡ lỗi để truy vấn cấu trúc dữ liệu. Quá trình đọc code khác xa so với quá trình đọc một cuốn sách.
Bạn cũng sẽ tìm đọc code mới một cách hứng thú. Bạn lưu lại các dòng code và cố gắng giữ đồng thời hàng chục cấu trúc dữ liệu và chức năng mới trong đầu. Đừng ngại nghỉ giải lao 1 tí khi bạn gặp một codebase mới. Khi mình bắt đầu với 1 codebase mới, một vài giờ rảnh trong ngày để đọc là tất cả những gì mình cần để năng suất hơn.
Mặc dù nó rất quan trọng để phát triển các kỹ năng đọc tốt, nhưng cũng quan trọng không kém khi suy nghĩ về những gì bạn đã đọc.
Bạn nên đọc code gì?
Khi bắt đầu sự nghiệp, mình tin rằng 60% thời gian của bạn nên dành cho việc đọc code. Có thể 1/3 trong số đó là code khác với codebase bạn sẽ build. Chắc hẳn là phải tốn rất nhiều thời gian, vậy chúng ta nên đọc gì?
Cách dễ nhất để bắt đầu đọc, và với ROI cao nhất, là học các dependency của bạn. Nội bộ hoá cách dependency của bạn làm việc để bạn dễ debug hơn trên toàn bộ hệ thống.
Một cách khác giúp mang lại năng suất cao khác là chọn một hệ thống quan trọng ở công ty của bạn mà bạn giao tiếp, và thử đọc qua nó. Điều này không chỉ đem lại giá trị cho công việc của bạn, mà các codebase chuyên nghiệp thì khác với codebase nguồn mở.
Ngoài các hệ thống mà bạn tương tác trực tiếp, hãy luôn sẵn sàng để đọc nhiều hơn nữa. Những ngày đầu trong sự nghiệp của mình, mình khuyên các bạn nên dành 1 giờ đồng hồ mỗi sáng hoặc mỗi tối để đọc code ngoài công việc hằng ngày của bạn. Nghe khá đau đớn vì sau một ngày làm việc mệt mỏi rồi, nhưng hãy cố gắng lượm nhặt codebase bạn thích và đào sâu vào nó trong 1 tuần thử nhé.
Ví dụ, Redis là nguồn nổi tiếng để bắt đầu học C. Để dễ đọc hơn và đọc được nhiều codebase phức tạp hơn, cách đơn giản là bắt đầu đọc từ subsystem cụ thể.
Các dự án phụ cũng là một cách tốt để đọc code, vì chúng buộc bạn phải học một thế giới khác. Bạn sẽ cần đọc nhiều dependency mới và khám phá những codebase khác nhau để biết mình đang build cái gì. Mặc dù không có vẻ là đọc cho lắm, nhưng đó là dự án mà có thể bắt bạn chủ động đọc những thứ bạn sẽ dùng.
Ngoài công việc, bạn nên đọc nhiều tools khác với những gì bạn đang làm. Nếu bạn đã quen với abstraction level cao, hãy học 1 (hoặc 3) abstraction level thấp hơn. Nếu bạn đang làm việc với 1 ngôn ngữ, chọn một ngôn ngữ khác để đọc vào lúc rảnh.Nếu bạn luôn nghĩ về 1 constraint (vd: thời gian để làm mới màn hình tiếp theo trong graphics programming), tìm một constraint khác (vd: tiết kiệm tuổi thọ pin cho lập trình mobile).
Một cách tiếp cận tốt khác để đọc code đó là đọc và viết lại từ những coder và bạn yêu thích. Trường hợp của Didion hồi trẻ đã viết nên Hemingway hoặc Hunter Thompson viết Great Gatsby, hoặc code của antirez/ gaearon/ mrdoob bắt đầu với 1 thư viện đơn giản. Đọc code khác của họ. Luôn cập nhật công việc gần đây nhất của họ.
Stephen King nói với các nhà văn rằng: “Nếu bạn không dành thời gian để đọc, bạn sẽ không có thời gian (hoặc công cụ) để viết, đơn giản vậy thôi”. Cũng tương tự thế đối với các kỹ sư phần mềm, viết code sạch có lẽ là điều vui nhất, nhưng chủ động đọc code mới là điều khiến bạn bứt phá ra khỏi vỏ bọc trước giờ.
Cách đây 2 năm (năm 2017), bên Pinterest đã tập trung build 1 đội viết lại trang web trên mobile sử dụng Progressive Web App.
Sau khi đã tối ưu được tốc độ load trang, thì điều tiếp theo họ nghĩ là làm thế nào để hiển thị dữ liệu được nhanh hơn.
Tôi nhận ra mình làm việc hiệu quả nhất bất cứ khi nào bản thân thực sự tập trung vào vấn đề đang làm ngay lúc đó, nhưng chính lúc đó tôi đã thực sự thư giãn, tận hưởng toàn bộ quá trình.
