Categories
Gambaru News

Cách giữ vững sự tập trung khi làm việc tại nhà

Làm việc tại một công ty phần mềm, tôi không hề xa lạ với trải nghiệm làm việc ở nhà.

Bản thân công việc của tôi đã có mức độ số hóa, online hóa cao nhất, văn hóa trong công ty cũng lại tập trung vào quản lý đầu ra chứ không quản lý thời gian.

Vô tình, những kỳ nghĩ lễ kéo dài ở quê, những ngày trời mưa to ngập phố, những ngày phải họp từ sáng sớm đến quá giờ quy định… đã đều chuẩn bị cho tôi một trải nghiệm làm việc ở nhà hiệu quả.

Và đây là cách tôi giữ cho mình có thể làm việc hiệu quả nhất, ngay cả khi đang ở trong môi trường… rất dễ chịu của căn nhà.

Cách tập trung khi làm việc tại nhà

Một không gian làm việc thật khác

Hãy tìm cho mình một “góc” riêng, để khi bước vào, tâm trí tự động chuyển sang chế độ làm việc.

Điều đầu tiên cần làm, đó là tạo cho mình một không gian làm việc thật khác.

Cách giữ sự tập trung khi làm việc tại nhà
Cách giữ sự tập trung khi làm việc tại nhà

Ví dụ, ở nhà tôi vốn đã có một không gian riêng để đặt PC chơi game và nghe nhạc.

Nhưng tôi không dùng chiếc bàn này để làm việc, thay vào đó, cứ mỗi sáng (và mỗi chiều) cách ly, tôi lại mang laptop ra bàn phòng khách ngồi.

Dĩ nhiên, không phải ai cũng sẽ có điều kiện để sở hữu nhiều không gian khác nhau, nhưng nguyên tắc vẫn chỉ có một: Hãy cố gắng mọi cách để không gian làm việc tách biệt ra hẳn những không gian thư giãn thường nhật.

Hãy tìm cho mình một “góc”, mà mỗi khi bạn bước vào, tâm trí bạn tự động chuyển sang chế độ làm việc.

Trong nhóm của tôi, nhiều người cũng như vậy.

Có người mang laptop lên kệ loa để đứng làm việc. Có người mua một chiếc ghế có gắn bàn nhỏ, hướng ra ngoài ban công. Còn nếu chỉ có một không gian, chỉ có một chiếc PC (hoặc laptop)…

Nếu bạn chỉ có một chiếc PC

Tôi đã từng phải đi làm việc ở nước ngoài trong một thời gian dài, đã có những ngày không thể lên công ty khách hàng ngồi mà phải làm việc tại khách sạn.

Chiếc laptop tôi mang theo cài đầy game, ban ngày dùng làm để làm việc…

Và đây là lời khuyên đặc biệt quan trọng với những người vốn chỉ dùng PC tại nhà để chơi game hay lướt face: khi phải dùng cỗ máy này cho công việc, hãy tạo một tài khoản người dùng (User Account) khác.

Tài khoản Windows cho công việc
Tài khoản Windows cho công việc

Trên tài khoản này, hãy ẩn đi toàn bộ các đường tắt tới Steam hay Origin, hãy đừng bao giờ đăng nhập vào Facebook hay Reddit.

Thay vào đó, hãy chỉ đặt các ứng dụng liên quan tới công việc mà thôi.

Tài khoản Windows cho giải trí
Tài khoản Windows cho giải trí

Không gian làm việc tối giản nhất có thể

Hãy nghĩ thật kỹ: Bạn thực sự cần thứ gì để làm việc?

Không gian làm việc tối giản
Không gian làm việc tối giản

Mở rộng một chút với lời khuyên bên trên: Hãy giữ cho góc làm việc của bạn luôn gọn gàng, ít vật dụng nhất có thể.

Một cuốn truyện đang đọc dở, một chiếc iPad dùng để “luyện” Netflix, bộ tai nghe “xịn”, đều có thể khiến bạn đứt mạch làm việc.

Dĩ nhiên, kỷ luật bản thân là cần thiết, nhưng hãy làm mọi cách để bản thân có thể tự giữ kỷ luật một cách dễ dàng hơn.

Đến cuối cùng, trong phần lớn trường hợp, thứ duy nhất bạn cần để làm việc chỉ là một chiếc PC mà thôi.

Liên tục “call” với team

Tùy vào mức độ gắn kết giữa các thành viên trong team (và dĩ nhiên là cả đường mạng), cả đội có thể bật cuộc gọi trong suốt chế độ làm việc.

Đây vừa là một cách giữ được sự liên lạc luôn được thông suốt (osmotic communication) trong quá trình làm việc, một nguyên tắc mà các coder tuân theo tư tưởng Agile luôn cố gắng thực hiện.

Liên tục call với team
Liên tục call với team

Hãy giả lập môi trường làm việc của team mình qua các ứng dụng gọi video.

Ngoài ra, đây cũng là một cách để cả đội có thể “nhắc khéo” nhau luôn tập trung cao độ trong quá trình làm việc nữa.

“Quy tắc giao tiếp” với gia đình

Nghe có vẻ hơi tiêu cực, nhưng các thành viên khác trong gia đình có thể khiến công việc (tại nhà) của bạn bị xao nhãng.

Ví dụ, đã có lúc tôi đang họp qua Slack thì mẹ tôi mở cửa vào phòng nói rất to: “Mẹ mua bánh mì về rồi, xuống ăn đi”.

Mọi người nghe thấy đều cười đùa, khiến buổi họp bị đứt mạch đôi chút.

Lời khuyên của tôi: hãy thiết lập một quy tắc giao tiếp với gia đình mình trong giờ làm việc.

Ví dụ, những ngày phải làm việc tại nhà, tôi luôn nhắc mẹ: Mẹ mua đồ ăn sáng thì cứ để ở bếp, xong việc đang làm con sẽ xuống ăn.

Hãy nhờ bố của bạn trả lời mỗi khi có ai bấm cửa.

Hãy dặn các bé (đã đủ lớn) tự ngồi học, ngồi chơi: “Bố ở nhà nhưng vẫn phải làm việc. Vẫn phải đến buổi tối, bố mới có thời gian để đọc truyện cho con”.

Chia nhỏ công việc, và cố gắng không bỏ dở đầu việc nhỏ

Các đầu việc nhỏ sẽ giúp bạn giảm thiểu ảnh hưởng từ các yếu tố xao nhãng.

Chia nhỏ công việc
Chia nhỏ công việc

Sẽ có những trường hợp bạn không thể bị ảnh hưởng.

Ví dụ, khi bạn phải vừa làm việc, vừa “để mắt” tới em bé để bà đi chợ ngày ông đi vắng chẳng hạn.

Để hạn chế ảnh hưởng theo cách này, hãy công việc của mình đủ nhỏ.

Ví dụ, công việc của tôi có thể chia thành các hàm (function) cần thực hiện. Công việc quản lý của bạn có thể chia thành từng hóa đơn, công việc viết lách có thể chia thành từng đầu mục (như 5 đầu mục trong bài viết này).

Hãy hoàn thành từng đầu việc nhỏ này trước khi bước sang việc khác.

Như vậy, khi có những điều xao nhãng xảy ra, ảnh hưởng sẽ chỉ gây ra với 1 đầu việc nhỏ mà thôi.

Nếu bạn đang code dở mà lại chuyển sang trả lời mail khách hàng và con bạn chạy vào, bạn sẽ phải tiếp tục tới 2 đầu việc đang dang dở. Đó sẽ là một trải nghiệm khó chịu hơn rất nhiều.

Và đừng quên những nguyên tắc chung

Chia nhỏ đầu việc chỉ là một trong những nguyên tắc chung mà bạn nên áp dụng khi làm việc ở bất cứ đâu – ở công ty hay ở nhà.

Hãy đặt cho mình các mốc thời gian để bắt đầu và kết thúc. Hãy viết các đầu việc cần làm lên note.

Hãy đảm bảo một môi trường nhiều ánh sáng.

Hãy đặt đồng hồ Pomodoro (ví dụ, làm việc 20 phút rồi tự cho phép mình “nghỉ ngơi 5 phút), nếu bạn tin vào phương pháp này.

Bởi đến cuối cùng, “công việc” ở đâu thì cũng vẫn là công việc.

Để có thể tập trung hơn, làm việc hiệu quả hơn, hãy ghi nhận tất cả sự khác biệt giữa khái niệm “làm việc” và “nghỉ ngơi”.

Và hãy tìm mọi cách để tạo cho mình 2 chế độ, dù rằng bạn vẫn đang chỉ ở nhà mà thôi.

Theo TechTalk via GenK

Categories
Dev's Corner

8 Công cụ CSS Web Developer phải có

Nếu bạn đang tìm danh sách các công cụ CSS giúp việc học và thành thục CSS trở nên dễ dàng và hiệu quả hơn, đây là bài viết dành cho bạn.

CSS là một trong những nền tảng cơ bản của lập trình web. Tuy nhiên, để hiểu thấu đáo về cách vận hành CSS lại không hề đơn giản.

Làm thế nào để code CSS với sự trợ giúp của các công cụ chuyên dụng cũng như học về CSS trong môi trường tương tác?

Hãy khám phá cùng Gambaru!

Công cụ tạo CSS trực tuyến

1. EnjoyCSS

Công cụ cực kỳ đơn giản này được coi là vị cứu tinh cho web developer đang mày mò CSS, cho phép thiết kế các element với UI đơn giản và đưa ra output phù hợp.

EnjoyCSS giảm thiểu thời gian và công sức cho lập trình viên để tạo các style phức tạp vì nó rất dễ sử dụng.

Đồng thời, bạn không bắt buộc phải có nền tảng quá sâu để hiểu về CSS phức tạp.

EnjoyCSS
EnjoyCSS mang đến sự thay đổi quy trình làm việc đáng kể.

2. CSS Arrow Please!

CSS Arrow Please! giúp tạo và xuất code cho các hộp với một mũi tên và có thể tùy chỉnh mũi tên kéo dài từ bất kỳ phía nào bạn muốn.

CSS Arrow Please
CSS Arrow Please! giúp tạo và xuất code cho các hộp với một mũi tên

Mặc dù điều này nghe có vẻ khá phức tạp để viết code từ đầu, nhưng công cụ này giúp chúng ta nhận được code chỉ sau vài cú nhấp chuột.

Khi nhận được, bạn có thể bắt đầu sử dụng code đó và thực hiện những thay đổi nhỏ, như thêm shadow chẳng hạn.

3. CSSmatic

CSS Matic
CSSmatic có giao diện người dùng đơn giản và trực quan.

Công cụ tất cả trong một này cung cấp những tính năng như:

  • Tạo gradient: Ta có thể sử dụng nhiều màu sắc và độ mờ để có được độ chuyển màu gradient đẹp đáng kinh ngạc.
  • Border radius: Siêu dễ sử dụng và siêu tiết kiệm thời gian. Tất cả các đường viền được chọn có thể được thay đổi cùng một lúc.
  • Noise texture: Tạo các background pattern tinh tế với các pixel chất lượng thấp và bị nhiễu, thay đổi màu sắc, giá trị và đồng thời xem trước được kết quả trong thời gian thực.
  • Box Shadow: Thay đổi độ mờ, màu sắc và kích thước đổ bóng – mọi thứ bạn cần để tạo bóng tuyệt vời cho 1 vật thể.

Tất cả những điều này có sẵn trên CSSMatic với một giao diện người dùng đơn giản và trực quan. Đây chắc chắn là một công cụ buộc phải có.

4. Patternizer và Patternify

PatterNizer
PatterNizer

Cả hai công cụ này cho phép tạo ra các pattern tuyệt vời với CSS trên giao diện thân thiện người dùng.

Với sự trợ giúp của PatternizerPatternify, bạn có thể tạo các pattern thú vị có thể dễ dàng áp dụng trên trang web của mình do nó được viết trực tiếp bằng CSS.

Công cụ học CSS trực tuyến

1. CSS Grid

CSS Grid
Khám phá 25 video bổ ích từ CSS Grid!

Trang web cung cấp một khóa học ngắn bốn giờ để hiểu được nền tảng căn bản về CSS Grid.

Khóa học hoàn toàn miễn phí này được sáng tạo bởi developer nổi tiếng – Wes Bos.

Hiện đang có tổng cộng 25 video đang chờ bạn mày mò và khám phá đấy.

2. Grid Garden

Grid Garden
Vừa làm vườn vừa viết code cùng Grid Garden!

Trò chơi tương tác Grid Garden nhắc bạn phải viết CSS code để trồng và chăm sóc vườn cà rốt của riêng mình.

Thật thú vị phải không?

Cách học này đảm bảo người dùng học được những điều cơ bản về CSS Grid theo một cách không hề khô khan chút nào.

Trò chơi bao gồm 28 cấp độ, mỗi cấp độ yêu cầu người dùng viết một CSS code để đáp ứng từng yêu cầu cụ thể.

3. Flexplorer

Flexplorer
Một ứng dụng hữu ích để học CSS.

Là một ứng dụng đơn giản, Flexplorer cho phép bạn mày mò nhiều tính năng Flexbox khác nhau và xem kết quả trực tiếp trên màn hình cùng với code.

Bạn cũng có thể chỉnh sửa văn bản trong các hộp và xem cách bố trí của các hộp này. Cách học mới lạ này hướng đến làm cho việc học dễ dàng và thuận lợi hơn.

4. Image Effects with CSS

Image Effects with CSS
Một công cụ học CSS bổ ích khác đáng để tìm hiểu.

Công cụ tuyệt vời này là sản phẩm của Bennett Feely, cũng là nhà sáng tạo Flexplorer.

Là một công cụ thực sự hữu ích, Image Effects with CSS cho phép người dùng thử nghiệm các thuộc tính CSS, như background-blend-mode, mix-blend-mode và filter để thao tác và tạo ra những hình ảnh tuyệt đẹp.

Happy coding!

Theo Mahdhi Rezvi.

Categories
Dev's Corner

Cộng đồng PHP: Mâu thuẫn và Tầm nhìn

Một bài viết tâm huyết từ một lập trình viên PHP. Dù bạn là developer trẻ, đang có hứng thú với ngôn ngữ lập trình này, hay một leader nhiều năm kinh nghiệm, hãy cùng Gambaru nhìn nhận góc nhìn của Neal và thảo luận ở phần comment cuối bài viết nhé.

Bạn có quan tâm về lập trình PHP?
Bạn có quan tâm về lập trình PHP? Ảnh: Pixabay – Pexels

Tôi đã lập trình với PHP được khoảng 7 năm, tự mình mày mò, khám phá về các framework, library, hệ sinh thái xung quanh các nền tảng quản lý nội dung, và quen biết một cộng đồng đông đảo lập trình viên PHP.

Rất nhiều người đã trở thành những người bạn thực sự và theo đánh giá của các bài phát biểu tại các diễn đàn tôi từng tham dự, tôi biết mình không đơn độc khi tin rằng chúng tôi có thể giúp mọi người cùng học hỏi và phát triển, xây dựng phần mềm tốt hơn, cũng như chung tay hỗ trợ lập trình viên tiến xa hơn trong sự nghiệp.

Ngôn ngữ PHP thường bị chỉ trích và chế nhạo bởi những lập trình viên cho rằng ngôn ngữ chúng ta lựa chọn chẳng khác gì một mớ hỗn độn và chỉ dân nghiệp dư mới sử dụng PHP.

(Có thể quan điểm này có lý trong quá khứ, nhưng bây giờ chỉ có người thiếu hiểu biết mới tranh luận như vậy, đặc biệt khi sự thật là PHP 7 đã đóng góp rất nhiều để giúp PHP trở thành một ngôn ngữ hoàn thiện hơn).

Tuy nhiên, cộng đồng PHP chẳng ngán gì “dăm ba lời khen chê này”, họ ngày càng bản lĩnh hơn và tiếp tục xây dựng các sản phẩm, thư viện, công cụ và tính năng mới.

Trong bài viết này, tôi muốn nói đến mâu thuẫn ngày càng gia tăng trong chính cộng đồng PHP, giữa những nhóm lập trình viên ủng hộ giữa các framework Laravel, Symfony và Doctrine ORM.

Nhiều người chuộng Symfony/Doctrine đưa ra những nhận xét chê bai về Laravel.

Đáp lại, những người ủng hộ Laravel dường như ngày càng trở nên chống đối và có xu hướng phản ứng quyết liệt với những lời chỉ trích (dù mang tính xây dựng hay không). 

Mâu thuẫn ngay trong chính cộng đồng PHP
Mâu thuẫn ngay trong chính cộng đồng PHP. Ảnh: freepik

Tôi chắc chắn rằng hầu hết lập trình viên chúng ta đều đã từng bị chỉ trích về cách mình code.

Chỉ trích cũng có đủ loại, có thể là “Cái quái gì thế này?” hoặc “Anh nên thử áp dụng các nguyên tắc SOLID / [x design pattern] ở đây, vì nó sẽ tiết kiệm thời gian và đỡ phải bực mình sau này đấy”.

Cách ta đưa ra và đón nhận phê bình đặt nền tảng cho cách ta phát triển như một nhà lập trình chuyên nghiệp cũng như sự nhìn nhận của những người xung quanh.

Đối với những người lãnh đạo, nó xác định cách những người theo gương và tôn trọng bạn cư xử ra sao đối với đồng nghiệp của họ.

Hiện nay, ta có thể thấy các lập trình viên ở vị trí Senior, các leader dự án và những nhân vật có tầm ảnh hưởng tham gia vào các cuộc tranh luận công khai trên các nền tảng như Twitter và Reddit.

Bạn đọc được những bình luận có tính gây hấn về khả năng mở rộng của dự án với framework x hoặc phương thức của library y chứa bao nhiêu dòng code.

Họ làm như vậy chẳng để đạt được điều gì ngoài việc thuyết phục người đọc rằng họ đã đúng khi không dùng những framework hay tool này.

Tóm lại, khi cứ mãi tranh luận như vậy, chúng ta đang cướp đi cơ hội của những lập trình viên ít kinh nghiệm hơn để thử nghiệm và trải nghiệm các cách tiếp cận khác nhau đối với các giải pháp chung.

Chúng ta phủ nhận họ có khả năng thoải mái thể hiện quan điểm và thảo luận về những cái lợi và hại của mỗi framework mà không sợ bị chế giễu.

Chúng ta ngăn họ đánh giá và học cách chọn công cụ phù hợp cho từng công việc cụ thể.

Chúng ta dần dần ngăn cản tiến trình sự nghiệp của họ. Điều này tạo ra một rào cản có hại cho họ và cho cả chúng ta như một hệ sinh thái của những nhà lập trình PHP.

Hãy nói về Symfony và Laravel nàoHãy nói về Symfony và Laravel nào
Hãy nói về Symfony và Laravel nào! Ảnh: Pixabay – Pexels

Về cá nhân mình, Symfony là framework ưa thích của tôi, nhưng tôi đã làm việc chuyên nghiệp với cả Laravel [versions 4 & 5] và Zend.

Symfony sử dụng Doctrine 1, triển khai ActiveRecord pattern, bao gồm rất nhiều tính năng bổ sung theo mặc định và khiến việc liên kết business logic với framework trở nên cực kỳ dễ dàng.

Là một opinionated framework (có tính quy chuẩn và áp đặt), Symfony đặt ra các công cụ nó mong đợi bạn sử dụng ngay trước bạn và cho phép bạn nhanh chóng bắt đầu công việc.

Symfony 2 bắt đầu thay đổi tất cả những điều đó.

Lập trình viên sử dụng Symfony muốn có nhiều sự lựa chọn và tính linh hoạt hơn khi chọn các công cụ và những gì cần đưa vào dự án. Họ muốn đưa các thư viện khác vào dễ dàng hơn nếu giải pháp ban đầu không còn ổn nữa.

Symfony đã phát triển rất nhanh giữa các phiên bản 1 và 2 và trở nên khác biệt so với phiên bản ban đầu.

Nó chuyển từ một framework cố định với tất cả các công cụ được đóng gói bên trong và một mức độ chưa đủ tinh vi sang khả năng tương tác với các gói bên ngoài Symfony.

Symfony đã đi một chặng đường dài để chuyển mình thành một tập hợp các gói và thành phần có thể tái sử dụng và việc kết hợp các đề xuất của PHP-FIG có nghĩa là các thành phần có thể dễ dàng được đưa vào các framework, library và hệ thống CMS khác.

Lập trình viên sử dụng Symfony có quyền tự hào về Symfony và mong muốn chia sẻ cách họ làm được điều đó.

Phần lớn các nhà lập trình tôi biết đồng tình rằng tài liệu của Laravel dễ tiếp cận hơn của Symfony và cũng dễ bắt đầu với Laravel hơn nhiều.

Ngày nay, Laravel có tính áp đặt hơn Symfony, vì vậy, tài liệu hướng dẫn có thể ít trừu tượng hơn và trực tiếp hơn về cách đạt được mục tiêu với các công cụ được cung cấp.

Người ta thường có xu hướng gán Laravel là framework cho người mới bắt đầu hoặc chỉ là một công cụ cho RAD (Rapid Application Development – phát triển ứng dụng / tạo mẫu nhanh) và khuyên không dùng nó cho các dự án phức tạp hơn.

Tất nhiên, phản ứng từ người dùng Laravel là sau đó sẽ là “Chà, nó đã được sử dụng trên trang x đó nhe!”.

Người dùng Doctrine phản ứng lại “Tụi tôi đã bỏ ActiveRecord từ lâu rồi, ORM của mấy ông phèn quá”, và rồi bên kia tiếp “Muốn cãi nhau về facade pattern thật sao?”, rồi lại một hồi dài tranh cãi.

Than phiền duy nhất của tôi về Laravel Eloquent là việc thêm các foreign key và index vào cơ sở dữ liệu sẽ tốn nhiều công sức hơn.

Tôi nghĩ đây là điều có độ ưu tiên cao khi thiết kế cấu trúc dữ liệu. Tôi đã kế thừa nhiều dự án Laravel bởi các công ty khác nhau, và không có dự án nào trong số đó có một foreign key hoặc index nào.

Điều này dẫn đến mất tính toàn vẹn của dữ liệu cũng như các vấn đề khác về hiệu suất.

Tôi cũng cảm thấy rằng Laravel và nhiều tài nguyên hướng dẫn về nó khuyến khích người dùng liên kết code ràng buộc với framework.

Một dev ở công ty tôi từng làm việc đã dành hàng tháng trời làm một việc đáng ra rất đơn giản là nâng cấp Laravel 4 lên Laravel 5. Anh chàng sao chép và viết lại các file và file logic được đặt trong controller.

Nếu như code được tách ra thì công ty hẳn sẽ chi ít tiền hơn cho việc nâng cấp này và anh ấy đã có thể chuyển sang phát triển tính năng mới sớm hơn nhiều.

Theo tôi, Laravel có thể được sử dụng cho các ứng dụng quy mô lớn, nhưng trừ khi lập trình viên đủ kinh nghiệm để biết những gì họ đang tìm kiếm trong tài liệu để cho phép scale ứng dụng, họ có thể sẽ không dùng Laravel.

Phải thừa nhận rằng rất dễ để liên kết code với Symfony controller, nhưng cộng đồng Symfony biết rằng làm như vậy là một ý tưởng tồi.

Theo trải nghiệm riêng, tôi chưa thấy người dùng Symfony chế nhạo ý tưởng tách code nhưng tôi thấy một số người dùng Laravel chế giễu cách làm này.

Dấu hiệu của một vấn đề sâu xa hơn
Tuy nhiên, tranh luận về việc này chỉ là một dấu hiệu của một vấn đề sâu xa hơn. Ảnh: Pixabay – Pexels

Lập trình viên chúng ta thường đưa ra lựa chọn về các công cụ yêu thích và hợp tác với những người khác đã giải quyết các vấn đề tương tự theo cùng cách.

Khi hạn chế bản thân bằng cách liên tục sử dụng những gì chúng ta biết và ở trong cộng đồng những người có cùng tư duy và ý tưởng, chúng ta hạn chế cách mình code và cả con đường sự nghiệp.

Tự ta buộc xích vào chân mình.

Việc ta giải quyết vấn đề theo một cách không nhất thiết có nghĩa là cách tiếp cận của người khác tốt hơn hay tệ hơn mà chỉ là chúng khác nhau mà thôi
Việc ta giải quyết vấn đề theo một cách không nhất thiết có nghĩa là cách tiếp cận của người khác tốt hơn hay tệ hơn mà chỉ là chúng khác nhau mà thôi. Ảnh: cottonbro – Pexels

Điều khiến tôi lo lắng nhất là ảnh hưởng mà chúng ta có thể có đối với lựa chọn của các lập trình viên trẻ, ít kinh nghiệm.

Có lẽ ai cũng đều cảm thấy hài lòng khi khuyên bảo một người và sau đó thấy họ nối gót mình.

Tuy nhiên, điều ta không nên làm là khuyến khích lập trình viên trẻ tuổi đừng thử nghiệm framework x hoặc y, đừng học lập trình ngôn ngữ z vì những thành kiến ​​của riêng mình. 

Hãy để người trẻ tự thử nghiệm và cho họ lời khuyên
Hãy để người trẻ tự thử nghiệm và cho họ lời khuyên. Ảnh: Arijit manna -Unsplash

Hãy để người trẻ tự thử nghiệm và cho họ lời khuyên. Hãy quan sát cách một người đưa ra và đón nhận chỉ trích.

Hãy nghĩ thử “Đây có phải là loại phản hồi đóng góp tích cực cho cộng đồng không? Đây có phải là mẫu người tôi nên lấy làm gương không? ”

Với tư cách là một leader, hãy tự hỏi bản thân “Tôi có đang buộc chiếc xích của chính mình vào chân những người xung quanh không? Tôi có ảnh hưởng tiêu cực đến người khác thông qua sự lựa chọn của chính mình không? ”

Các cuộc tranh luận gay gắt không có tác dụng gì trong việc thúc đẩy sự nghiệp chung của cộng đồng lập trình viên mà chỉ khiến mọi người e ngại gia nhập cộng đồng PHP toàn cầu mà thôi.

Theo Neal Brooks

Categories
Gambaru News

6 Công cụ lập trình web front-end hàng đầu năm 2020

Công cụ lập trình web front end
Công cụ lập trình web front end. Ảnh: KOBU Agency – Unsplash

Trong bài viết này, mời bạn cùng Gambaru khám phá một số công cụ giúp giải quyết các thách thức trong quá trình lập trình web front-end và đồng thời đảm bảo tăng năng suất làm việc nhé.

Các công cụ lập trình web front-end hàng đầu

1. Chrome DevTools

Chrome DevTools là bộ công cụ tạo web và debug được tích hợp sẵn của Google Chrome.

Nó có rất nhiều tùy chọn cho việc kiểm thử, debug và cải thiện chất lượng trang web.

Từ chỉnh sửa đến test được web trên nhiều độ phân giải khác nhau, DevTools chứng tỏ được sự hữu ích của nó, giúp việc xây dựng trang web nhanh hơn.

Cần thời gian và công sức để nghiên cứu và hiểu rõ UI của DevTools, song thành quả đạt được chính là năng suất làm việc sẽ tăng rất đáng kể nhờ công cụ hiệu quả này.

Sử dụng Chrome DevTools
Sử dụng Chrome DevTools. Ảnh: Medium

2. Các tiện ích mở rộng trên trình duyệt

Các trình duyệt hiện đại như Google Chrome giúp việc lướt web an toàn hơn và mang đến trải nghiệm người dùng mượt mà.

Ngoài ra, chúng còn cung cấp các công cụ tuyệt vời cho web developers xây dựng các ứng dụng xuất sắc.

Danh sách dưới đây là một số tiện ích mở rộng tốt nhất sẽ giúp front-end dev làm việc hiệu quả hơn:

Ngoài ra, bạn có thể tìm hiểu bài viết này để biết thêm danh sách chi tiết các tiện ích mở rộng trên Chrome tốt nhất.

3. Gulp và Grunt

Lập trình viên front-end không chỉ giải quyết các tasks phức tạp và tạo dựng web mà còn thường xuyên buộc phải thực hiện một số quy trình lặp đi lặp lại và tốn thời gian, như việc tổng hợp Less và SCSS thành các file CSS và nén các file hình ảnh chẳng hạn.

Tin vui là ta có thể tự động hóa các quy trình này với sự trợ giúp của bộ công cụ Gulp hoặc Grunt.

Cả hai đều cho phép ta kiểm tra file mới hoặc các thay đổi trong file hiện có và chạy các tác vụ áp dụng được cho chúng.

Một số tác vụ phổ biến nhất mà một trong hai công cụ có thể thực hiện bao gồm:

  • Tổng hợp các files Less hoặc Sass sang CSS.
  • Nén các file hình ảnh mà không làm ảnh hưởng đến chất lượng.
  • Tìm lỗi code trong mã nguồn (linting code).
  • Tối ưu dung lượng (minify), nối (concatenate) và dọn dẹp các files CSS và JavaScript.
  • Gửi cập nhật đến production server.

Bằng cách tự động hóa những tasks thường nhật này, ta có thể tiết kiệm một lượng lớn thời gian nên dành cho lập trình và tăng năng suất làm việc.

4. Các công cụ kiểm tra khả năng đáp ứng

Lập trình viên front-end cần biết đến khái niệm responsive web design (thiết kế web đáp ứng) và cách làm cho trang web hiển thị hoàn hảo trên mọi thiết bị hoặc kích thước màn hình.

Để đảm bảo rằng trang web hoàn toàn có tính đáp ứng như vậy, ta cần thực hiện test trên các thiết bị khác nhau.

Sự trợ giúp của các công cụ sau mang đến chất lượng test được cải thiện rõ rệt và giảm thời gian lập trình.

Responsinator

Responsinator rất dễ sử dụng và hoàn toàn miễn phí.

Bạn chỉ cần cung cấp URL của trang web và Responsinator sẽ cho bạn biết cách trang web đó sẽ được hiển thị ra sao ở các hình dạng và kích thước màn hình phổ biến nhất.

Gambaru.io - iPad landscape · width: 1024px
Gambaru.io – iPad landscape · width: 1024px

Google DevTools Device Mode

Google DevTools Device Mode giúp Dev dễ dàng mô phỏng thiết bị di động trong trình duyệt Chrome.

Bạn thậm chí có thể mô phỏng đầu vào thiết bị để chạm, định vị địa điểm và hướng thiết bị trong trình mô phỏng.

Gambaru.io trên Google DevTools
Gambaru.io trên Google DevTools

Browser Stack

Browser Stack là một trong những công cụ test tiên tiến, đầy đủ tính năng nhất hiện nay.

Công cụ trả phí này cung cấp quyền truy cập vào hơn 1.000 trình duyệt trên điện thoại di động và máy tính cho mục đích kiểm thử.

Test thử Gambaru.io trên Browser Stack!
Test thử Gambaru.io trên Browser Stack!

5. Một số công cụ CSS hữu ích

CSS ngày càng trở nên mạnh mẽ hơn và ngày nay cung cấp rất nhiều khả năng để tạo ra các trang web tuyệt đẹp về mặt trực quan.

Nếu quá trình tạo gradient và animation trở nên phức tạp, hãy thử áp dụng một số công cụ hữu ích sau:

Browserhacks

Browserhacks là một trang web cung cấp một bộ sưu tập các bản hack CSS và JavaScript dành riêng cho trình duyệt để giải quyết các vấn đề phức tạp và khó hiểu trang web của bạn có thể gặp phải.

Browserhacks
Browserhacks. Ảnh: Medium

Animista

Animista là một trang web tuyệt vời để tạo và tùy chỉnh code cho CSS animation với nhiều hiệu ứng đa dạng.

Chọn bất kỳ animation nào trong bộ sưu tập, như nền, hiệu ứng thoát, văn bản, v.v. và tha hồ tùy chỉnh nó.

Bước tiếp theo, bạn sẽ nhận được đoạn code cho hiệu ứng animation vừa rồi và chỉ cần tích hợp nó vào trang web của mình là xong!

Animista
Animista – Ảnh: Medium

Grabient

Grabient là một UI dễ sử dụng để tạo các gradient tuyến tính cho web. Chọn màu bạn muốn và điều chỉnh các góc cần thiết.

Khi đã có gradient mong muốn, hãy lấy gradient CSS và áp dụng nó vào trang web của mình.

Grabient
Grabient. Ảnh: Medium

6. Các thư viện UI Components

Thư viện được tạo ra là để giúp cuộc sống của các lập trình viên dễ dàng hơn. Một thư viện UI Components tốt là một tập hợp các thành phần giao diện người dùng được tạo sẵn có thể:

  • Cắt giảm thời gian lập trình.
  • Duy trì tính nhất quán của giao diện người dùng.
  • Duy trì khả năng tương thích và tính đáp ứng của trình duyệt.
  • Dễ dàng sử dụng và tùy chỉnh.

Sử dụng những thư viện như vậy trong ứng dụng sẽ tăng năng suất và giúp bạn hoàn thành nhiều đầu công việc hơn. Hãy thử xem qua Syncfusion nhé!

Theo Rajeshwari Pandinagarajan

Categories
Dev's Corner

Junior Ruby on Rails Developer cần có kỹ năng gì?

Kỳ này, Gambaru mời bạn theo dõi bài viết trên Medium của Krzysztof Kempiński, 1 lập trình viên Ruby on Rails, iOS và Elixir về những kỹ năng ông cho là quan trọng một Junior Ruby on Rails Dev cần trau dồi.

Hãy chia sẻ góc nhìn và trải nghiệm của riêng bạn ở phần comment cuối bài viết nhé.

Junior Ruby on Rails Dev cần kỹ năng gì?
Junior Ruby on Rails Dev cần kỹ năng gì? Ảnh: Pixabay – Pexels

Trong sự nghiệp của mình, tôi có nhiều cơ hội làm việc với lập trình viên Ruby on Rails cũng như tuyển dụng nhiều lập trình viên vị trí Junior cho các công ty.

Dưới đây là danh sách các kỹ năng theo tôi là cần thiết cho vị trí này.

Các kỹ năng Junior Ruby on Rails Developer cần trang bị

Lập trình viên Ruby on Rails không chỉ cần biết cách phát triển phần mềm mà còn phải liên tục cải thiện bản thân để trở thành một phần giá trị của đội nhóm, tạo ra được tác động đến sản phẩm mình xây dựng.

1. Kỹ năng mềm

Kỹ năng mềm - Junior Ruby on Rails Dev
Kỹ năng mềm. Ảnh: Team vector created by macrovector – www.freepik.com

Tiếng Anh

Kỹ năng mềm quan trọng nhất cho mọi lập trình viên. Lập trình viên sử dụng tiếng Anh hằng ngày trong công việc, chủ yếu là cho việc đọc hơn là viết.

Tuy nhiên, cải thiện kỹ năng giao tiếp trong tiếng Anh vẫn quan trọng do bạn sẽ sử dụng nó khi trao đổi, liên lạc với khách hàng và các thành viên trong nhóm.

Tham vọng

Bạn không muốn ở mãi vị trí Junior phải không?

Hãy chủ động tham gia giải quyết các vấn đề và các tasks khó, phức tạp hơn, bên cạnh những tasks thường nhật.

Tư duy “Tôi không biết”

Chỉ khi thừa nhận rằng mình không biết một điều, bạn mới có thể học nó.

Các đồng nghiệp Senior thường sẽ sẵn lòng giúp đỡ và hỗ trợ nếu bạn chia sẻ rằng mình chưa nắm rõ một điều gì.

Đừng ngại gì hết bạn nhé vì đây là một quá trình học hỏi bình thường.

Sẵn sàng và khát khao học hỏi

Hãy cố gắng thể hiện mong muốn học hỏi này.

Liên tục đặt câu hỏi, dành thêm thời gian nghiên cứu và tập code các dự án ngoài lề yêu thích của mình.

Kỹ năng tìm kiếm trên Internet

Là một lập trình viên Junior, bạn phải học cách để nhanh chóng biết nơi tìm câu trả lời cho câu hỏi của mình: Stack Overflow, Google hay trên các diễn đàn mạng v.v.

Sự phù hợp với Văn hóa / Doanh nghiệp

Tôi nghĩ điều này cực kỳ quan trọng.

Nếu bạn cảm thấy mình không thuộc về công ty, hoặc công ty biết bạn không hợp với tinh thần làm việc của họ, sẽ không có ý nghĩa gì cho hai bên nếu tiếp tục.

Hiệu suất làm việc sẽ tăng lên chỉ khi bạn cảm thấy ổn và thoải mái trong môi trường làm việc hiện tại.

2. Ruby

Cú pháp

Hãy tìm hiểu một số yếu tố cơ bản của ngôn ngữ Ruby on Rails như vòng lặp, lớp, câu lệnh điều kiện, mô-đun, v.v.

Lập trình Hướng đối tượng

Là một Ruby Dev, bạn sẽ làm việc chủ yếu với lập trình hướng đối tượng, do đó hãy tìm hiểu kỹ các khái niệm về OOP trong Ruby như: các lớp, đối tượng, inheritance – composition, blocks – procs – lambdas, include – extend một mô-đun.

3. Ruby on Rails

Kỹ năng Ruby on Rails.
Kỹ năng Ruby on Rails. Ảnh: Chris Ried – Unsplash

MVC Paradigm

Đây là cấu trúc của RoR framework. Bạn cần biết lớp nào chịu trách nhiệm cho việc gì và làm thế nào để cấu trúc được ứng dụng để có thể đặt business logic đúng nơi.

ERB / ​​Haml

Hai hệ thống templating / view phổ biến nhất. Tôi đề nghị bạn nên bắt đầu tìm hiểu về ERB trước.

ActiveRecord

Hầu hết các ứng dụng web sử dụng data persistent. Bạn phải biết ActiveRecord, về model, migration, association và validation.

Cấu hình của một ứng dụng mới

Hãy thường xuyên thực hành! Xây dựng một dự án của riêng mình và cố gắng học bằng coding. Để làm điều này, bạn sẽ phải biết cách cấu hình dự án mới ngay từ những giai đoạn đầu.

Unit testing với Rspec

Kiểm thử là cách tiếp cận rất phổ biến đối với các dự án được xây dựng bằng Ruby on Rails. Rspes là công cụ cực kỳ phổ biến.

Bạn phải biết cách viết các unit test với Rspec vì hiệu quả công việc cần được đảm bảo bởi các test để được approved/merged.

API + JSON

Ruby on Rails thường được sử dụng như một API provider, vì vậy bạn cần làm quen với khái niệm API và định dạng JSON.

Khái niệm cơ bản về giao thức REST và HTTP

Rất nhiều ứng dụng web hoạt động như một ứng dụng REST. Bạn nên làm quen với giao thức HTTP, ít nhất là xác định được HTTP verbs và một vài trạng thái phổ biến nhất.

4. Kỹ năng Front-end

Kỹ năng Front end
Kỹ năng Front end. Ảnh: Greg Rakozy – Unsplash

HTML5

Một số điều cơ bản về HTML

JS

Kiến thức về JavaScript, jQuery và các framework JavaScript phổ biến nhất. Và nếu bạn biết thêm một số kiến ​​thức về ES6 nữa là quá chuẩn rồi.

CSS

Kiến ​​thức về cách Cascading Style Sheets hoạt động và các khái niệm liên quan đến SCSS / SASS.

5. Cơ sở dữ liệu

Khái niệm cơ bản về SQL

Ngay cả khi không phải viết bất kỳ SQL nào vì ActiveRecord làm điều đó, bạn sẽ cần phải đọc logs để hiểu hoạt động gì đang xảy ra.

PostgreSQL / MySQL

Hai công cụ cơ sở dữ liệu phổ biến nhất. Sẽ rất tốt nếu biết một số khác biệt và cách cài đặt chúng trên máy của mình.

Khái niệm về cơ sở dữ liệu NoSQL

Mặc dù không phổ biến như cơ sở dữ liệu SQL, nhiều dự án hiện nay vẫn sử dụng NoSQL.

6. Công cụ

Git

Công cụ cần thiết để quản lý code. Bạn phải biết Git là gì, làm thế nào để tạo nhánh mới, cách pull và push code.

Deployment

Một số công cụ để deploy cần biết như Heroku, Capistrano, Docker, CI.

Công cụ quản lý dự án /ticket

Trello / Asana / Pivotal / Github v.v.

Công cụ mà Junior Ruby on Rails Dev sử dụngCông cụ mà Junior Ruby on Rails Dev sử dụng
Công cụ mà Junior Ruby on Rails Dev sử dụng. Ảnh: freepik.com

Theo Krzysztof Kempiński

Categories
Dev's Corner

Các mẹo hữu ích để debug Java nhanh hơn

Bên cạnh việc viết code hiệu quả, thành thạo các kỹ thuật debug java là một trong những điều hữu ích khiến cuộc sống của lập trình viên Java dễ thở hơn, đồng thời đây là kỹ năng giúp phân biệt được một developer xuất sắc.

Điều này còn đặc biệt quan trọng trong môi trường lập trình ngày nay, nơi thế giới phần mềm đang ngày càng chuyển sang các kiến ​​trúc phân tán và bất đồng bộ.

Lỗi phần mềm là không thể tránh khỏi cho nên việc phát hiện và sửa lỗi trong các bản build phức tạp ngày càng trở nên khó nhằn.

Quá trình debug java thậm chí là một thử thách cam go khi ta chuyển sang môi trường production.

Làm thế nào lập trình viên Java có thể tìm ra nguyên nhân gốc của bugs và nhanh chóng giải quyết chúng
Làm thế nào lập trình viên Java có thể tìm ra nguyên nhân gốc của bugs và nhanh chóng giải quyết chúng? Ảnh: Kevin Ku – Pexels

Gambaru giới thiệu cùng bạn bài viết trên Medium tập hợp một số mẹo hiệu quả nhất để debug các ứng dụng Java trong môi trường development và production.

Các mẹo Debug Java nhanh hơn

Sử dụng Breakpoints

Breakpoints là một tính năng đơn giản nhưng quan trọng, tạo nền tảng cho quá trình debug.

Breakpoints cho phép tạm dừng thực thi ứng dụng tại vị trí nghi ngờ bị lỗi để ta có thể phân tích trạng thái chương trình, biến đầu vào, logic và tìm hiểu lý do tại sao code lại lỗi.

Mỗi trình debug cung cấp một số loại breakpoints, bao gồm conditional breakpoints, exception breakpoints, watch points, và trace points.

Tìm hiểu cách thức và thời điểm áp dụng các loại breakpoints khác nhau có thể làm cho quá trình debug dễ dàng hơn.

Một số công cụ hiện đại còn hỗ trợ các breakpoints không gián đoạn (non-breaking breakpoints).

Điều này cho phép ta đặt các breakpoints trên code và thu thập dữ liệu debug mà không phải tạm dừng giai đoạn lập trình.

Dưới đây là ví dụ breakpoint trên Rookout web IDE, được đặt trên dòng 41.

Ví dụ breakpoint trên Rookout web IDE
Ví dụ breakpoint trên Rookout web IDE. Ảnh: Medium

Hiển thị cấu trúc logic

Tính năng này thường có sẵn trong chế độ xem variables và khá hữu ích khi theo dõi nội dung trong các lớp Java.

Khi bật tính năng này, danh sách biến hiển thị một array.

Điều này rất tiện dụng, đặc biệt trong trong trường hợp không có phương thức toString() – cho các đối tượng.

Hình dưới đây cho thấy tính năng này trên khung “hiển thị biến” (variable view) trên Eclipse IDE khi debug.

“Hiển thị biến” (variable view) trên Eclipse IDE khi debug
“Hiển thị biến” (variable view) trên Eclipse IDE khi debug. Ảnh: Medium

“Variable view” cũng cho phép sửa đổi trực tiếp các giá trị của biến trong quá trình debug.

Điều này giúp tiết kiệm thời gian đáng kể vì ta không phải khởi động lại phiên debug với dữ liệu đầu vào đã thay đổi.

Điều hướng thông qua Codebase

Mỗi trình debug Java cung cấp một số tính năng như run to line, step over, step into, step return, cho phép developers điều hướng qua các phần khác nhau của code khi debug.

Ngoài ra, hãy thử kết hợp những tính năng khác sau:

  • Drop to frame – Tính năng này được sử dụng để quay lại một điểm trong stack frame. Khi bỏ lỡ một điểm nào đó và cần quay ngược lại thời điểm đó, hãy sử dụng tính năng drop to frame.
  • Step filtering – Tính năng này cho phép bỏ qua một số package nhất định khi debug. Ta không cần phải điều hướng qua tất cả các lớp của hệ thống JDK khi chỉ cần đơn giản là lọc ra những phần không cần thiết phải debug.

Để cải thiện tốc độ điều hướng qua code, hãy thành thạo các phím tắt đến các chức năng quan trọng nhất.

  • F5 để step into
  • F6 để step over
  • F8 để chạy cho đến khi chạm đến breakpoint tiếp theo

Mặc dù các phím tắt debug có thể khác nhau tùy vào IDE, việc ghi nhớ chúng là quan trọng, giảm thiểu việc dùng chuột quá nhiều.

Học cách giải quyết Deadlocks

Deadlocks xảy ra khi hai hoặc nhiều luồng bị chặn vĩnh viễn sau khi hình thành một phụ thuộc vòng (cyclic dependency), như hình minh họa dưới đây.

Học cách giải quyết Deadlocks
Học cách giải quyết Deadlocks. Ảnh: Medium

Một tập hợp các luồng Java chờ một tài nguyên thuộc sở hữu của luồng kia, đây là tình huống có thể khiến ứng dụng bị đình trệ hoàn toàn.

Khá là khó để debug jstack deadlocks vì chúng không biểu hiện các triệu chứng như tăng đột biến trong bộ nhớ, CPU hoặc các thông số hệ điều hành khác.

Ngoài ra, chúng có xu hướng biểu hiện trong các điều kiện tồi tệ nhất, như heavy production load conditions (phải xử lý lượng lớn dữ liệu đồng thời), và rất khó để replicate.

Có nhiều cách khác nhau để khắc phục các tình huống deadlocks. Ta có thể capture các thread dump trong JVM.

Tùy vào kích thước của JVM mà việc này có thế tốn nhiều thời gian và công sức.

Một cách hay hơn là sử dụng một ứng dụng theo dõi giải pháp cung cấp mức độ JV và độ hiển thị theo mức độ code cần thiết để cô lập các thread deadlocks.

Có nhiều công cụ đột phá hiện có thể giải quyết vấn đề này – bao gồm một số trình debug tiên tiến cũng như các công cụ APM thương mại.

Sử dụng các công cụ này để có được khả năng hiển thị vào code Java và cô lập bugs giúp giảm thời gian đáng kể nên dành cho việc điều tra và phân tích.

Tận dụng các trình debug cho môi trường production

Quá trình debug điển hình mà hầu hết các lập trình viên thường tuân theo là: tái tạo môi trường → tái hiện bugs → tiến hành fix bugs.

Tuy nhiên, điều này không phải lúc nào cũng khả thi trong mọi môi trường production. Lúc này, developers có thể sử dụng các trình debug cho production.

Rookout là một trong những công cụ hiệu quả, cho phép thu thập dữ liệu debug từ các ứng dụng live mà không làm thay đổi trạng thái hoặc điều khiển luồng của ứng dụng.

Với Rookout, bạn có thể đặt các non-breaking breakpoints để lấy được full stack trace, nắm bắt các biến live hoặc bất kỳ dữ liệu ứng dụng nào khác cần để debug.

Tận dụng các trình debug cho môi trường productionTận dụng các trình debug cho môi trường production
Tận dụng các trình debug cho môi trường production. Ảnh: Medium

Vì vậy, thay vì sử dụng các giải pháp giám sát high-overload để debug cho môi trường production, hãy thử sử dụng các công cụ như Rookout để debug các ứng dụng live mà không cần deploy lại hoặc viết code mới.

Cho dù đang làm việc trên các ứng dụng không có máy chủ hoặc được đóng gói, Rookout sẽ là một bổ sung tuyệt vời cho kho công cụ debug.

Đừng quên về debug từ xa (remote debugging)

Phần lớn các IDE hàng đầu như NetBeans, Eclipse, Intellij IDEA Visual Studio hỗ trợ debug từ xa, một kỹ thuật cho phép debug code Java chạy trên máy khác.

Điều này đặc biệt quan trọng trong các tình huống trong đó hệ thống đích không hỗ trợ debug cục bộ hoặc trên các hệ thống thiếu tài nguyên để chạy trình debug.

Để thực hiện debug từ xa, ta cần cung cấp chi tiết cấu hình mà trình debug sẽ sử dụng để kết nối với cổng từ xa.

Ví dụ, nếu sử dụng Eclipse, đây là các cấu hình cần được cung cấp để khởi chạy phiên debug từ xa thành công.

Debug từ xa
Debug từ xa. Ảnh: Medium

Debug từ xa cũng có ích khi khắc phục bugs trong quá trình cài đặt môi trường production, khi lập trình viên cần kết nối với một ứng dụng và fix bugs từ xa.

Bugs là một câu đố lập trình, và có rất nhiều lập trình viên đã giải được những câu đố này mà không cần ở gần máy tính của họ
Bugs là một câu đố lập trình, và có rất nhiều lập trình viên đã giải được những câu đố này mà không cần ở gần máy tính của họ. Ảnh: Lukas – Pexels

Cuối cùng, hãy nhớ rằng việc debug đôi khi có thể mất nhiều thời gian hơn so với việc thực hiện thực tế.

Khi trau dồi kỹ năng debug Java, hãy luôn cố gắng viết code rõ ràng, dễ hiểu, tường minh, đặt tên biến và tên hàm có ý nghĩa – vì sau này khi debug sẽ đỡ cực hơn rất nhiều.

Và nếu mọi thứ dường như vượt ra khỏi tầm kiểm soát của mình, nghỉ ngơi một chút cũng không sao cả.

Mong bạn sử dụng thành công các chiến lược trên để trải nghiệm debug Java bớt “đau khổ” hơn nhé.

Happy coding!

Theo Ari Noman

Categories
Dev's Corner

Sự khác biệt giữa Junior, Mid-Level và Senior Developer

bài viết trước, Gambaru đã cùng các bạn tìm hiểu về vị trí Senior Software Developer.

Hôm nay, mời mọi người theo dõi góc nhìn của Daan, một back-end developer từ Hà Lan về:

Sự khác nhau giữa Junior, Mid-Level và Senior Developer

Sự khác nhau giữa Junior, Mid-level và Senior developer
Sự khác nhau giữa Junior, Mid-level và Senior developer. Ảnh: Soumil Kumar – Pexels

Số năm kinh nghiệm lập trình không đủ để xác định được ai là một Junior, Mid-level hoặc Senior Developer.

Tôi nghĩ điều quan trọng ở đây là kỹ năng.

Một Senior Developer chẳng phải là chuyên gia về mọi thứ, nhưng ta hoàn toàn có thể nói rằng Senior Developer có kỹ năng thành thục hơn Junior và Mid-level Developer.

Kiến thức

Senior Developer sở hữu lượng kiến thức lớn hơn nhiều so với Mid-level và Junior Developer.

Junior Developer cần mở mang hiểu biết về design pattern, architecture, automating testing, performance, security… mới thu hẹp được khoảng cách kiến thức với Mid-level và Senior Developer.

Đúng là rất quan trọng để biết mọi thứ trong quá trình phát triển phần mềm nên thực hiện như thế nào, nhưng chỉ biết những điều này chưa đủ để bạn trở thành một Senior Developer.

Kiến thức là một trong những yếu tố cho thấy sự khác biệt lớn nhất giữa các dev, nhưng nó chưa phải là tất cả
Kiến thức là một trong những yếu tố cho thấy sự khác biệt lớn nhất giữa các dev, nhưng nó chưa phải là tất cả. Ảnh: NeONBRAND – Unsplash

Coding

Trái với suy nghĩ của hầu hết mọi người, coding không phải là vấn đề về việc giao tiếp với máy tính.

Coding là việc giao tiếp với con người và hướng dẫn máy tính. Suy cho cùng, code được tổng hợp và biên dịch thành giá trị 0 và 1.

Code phải có ý nghĩa đối với những dev khác làm việc với nó trong tương lai.

Một team mới chưa bao giờ tiếp xúc với đoạn code vẫn có thể mở được nó và tiến hành làm việc với các tính năng mới hoặc fix bug.

Đây là nơi có thể thấy sự khác biệt lớn giữa Junior Developer và Senior Developer.

Tôi sẽ không nói về Mid-level Developer trong đoạn so sánh tiếp theo vì Mid-level Developer là một khu vực xám khi nói đến kỹ năng coding.

Phân biệt Junior Developer?

Junior Developer ít kinh nghiệm, một số vừa tốt nghiệp và lần đầu tiên đi làm.

Một Junior Developer thường chỉ nghĩ là phải làm cho code chạy được. Theo họ, phần mềm chạy được và phần mềm tốt là như nhau.

Viết được code tường minh không đơn giản và Junior Dev thường viết code rườm rà.

Bạn có thể nhận ra Junior Developer vì họ hay viết tất cả mọi thứ trên một dòng hoặc những lớp abstract phức tạp quá mức.

Đây là cách một Junior Developer thể hiện cho các dev khác biết họ có thể viết code tốt như thế nào. Và điều này là sai lầm.

Senior Developer thì sao?

Khi nhìn vào code của một Senior Developer, bạn có thể nghĩ: đây có phải là tất cả không?

Phần code còn lại đâu rồi? Một Senior Developer viết code đơn giản, dễ hiểu và thậm chí có thể là ngớ ngẩn.

Đây là một trong những phẩm chất làm lập trình lớn nhất một developer có.

Senior Developer tuân theo nguyên tắc KISS (Keep It Simple, Stupid).

Làm đơn giản thôi, ngốc ạ.
Làm đơn giản thôi, ngốc ạ. Ảnh: Myburgh Roux – Pexels

Senior Developer viết code và cân nhắc về khả năng code maintain được và mở rộng được.

Đây là một tư duy hoàn toàn khác so với Junior Developer – Senior nghĩ về những người phải làm việc với code, còn Junior chỉ nghĩ về việc làm cho nó hoạt động trên máy tính.

Không chỉ là kỹ năng lập trình

Nói chung, Junior Developer thực hiện các task hoặc task đơn giản nhất với độ ảnh hưởng thấp. Họ không thực hiện việc thiết kế kiến trúc hệ thống.

Mid-level Developer cũng không tạo ra solution, họ chỉ thực hiện task.

Sự khác biệt với Junior Developer là họ thực hiện task đó với ít sự giám sát hơn miễn là họ được giao cho các task có tính ổn định tương đối.

Senior Developer thì có thể hoàn toàn tự mình phát triển một ứng dụng.

Điều này không có nghĩa là Senior Developer không có bất kỳ câu hỏi nào trong quá trình làm việc.

Senior Developer biết cách đặt câu hỏi đúng và cách xử lý những câu hỏi này.

Mid-level Developer có thể đặt câu hỏi đúng liên quan đến các task họ thường xuyên làm, nhưng cần hỗ trợ ở những task phức tạp hơn.

Senior Developer không hoang mang và biết cách theo dõi những câu hỏi đặt ra với hành động hợp lý.

Senior Developer vẫn luôn nhờ sự giúp đỡ từ các dev khác vì đôi khi cách tốt nhất là chỉ cần nhờ dev có kinh nghiệm trong lĩnh vực đó giúp đỡ.

Mid-level Developer cũng có thể hỏi đúng câu hỏi, miễn là họ không được giao những task có độ phức tạp cao, đòi hỏi kiến thức chuyên sâu.

Ta không nên mong đợi một Junior Developer sẽ làm được điều này vì họ thiếu kinh nghiệm và cần hướng dẫn từ một dev có kinh nghiệm hơn, cần những nguồn lực cần thiết hoặc một sự thúc đẩy mạnh mẽ để đi đúng hướng.

Nâng cấp từ Junior lên Senior Developer

Tất cả chúng ta đều muốn cải thiện bản thân và trở thành một developer hoàn thiện hơn. Các bước cần thực hiện để đạt đến cấp độ tiếp theo là gì?
Tất cả chúng ta đều muốn cải thiện bản thân và trở thành một developer hoàn thiện hơn. Các bước cần thực hiện để đạt đến cấp độ tiếp theo là gì? Ảnh: Jerry Zhang – Unsplash

Junior lên Mid-level

Vì các Junior Developer đều thiếu kinh nghiệm, nên điều quan trọng là phải tự mình trải qua toàn bộ chu trình lập trình ít nhất một vài lần.

Bằng cách này, bạn sẽ mắc nhiều sai lầm và học cách tránh lặp lại chúng vào lần tiếp theo.

Bạn nên học cách viết code đơn giản. Hãy nghĩ về người tiếp theo sẽ làm việc với code đó.

Bạn cũng nên tìm hiểu cách debug vì điều này sẽ giúp ta hiểu rõ hơn về những gì xảy ra trong quá trình lập trình.

Ngoài ra, bạn nên làm quen với những thực tiễn tốt nhất và tìm hiểu về architecture, performance, security v.v. Mục tiêu là thu hẹp khoảng cách kiến thức cần có để đạt đến mid-level.

Mid-level đến Senior

Đi từ Mid-level đến Senior là một chặng đường khá khó khăn. Một số dev sẽ chỉ ở mức Mid-level trong suốt sự nghiệp của mình.

Senior Developer biết khi nào cần đi đường tắt và khi nào thì không.

Đây là những bài học khó nhằn chỉ học được bằng cách mắc sai lầm trong quá khứ.

Nếu muốn lên Senior Level, bạn phải sẵn sàng nhận những task mà không ai biết cách xử lý và nên biết nhiều hơn ngoài việc làm thế nào để hoàn thành công việc.

Là một Senior Developer, bạn cũng có công việc hỗ trợ các dev ít kinh nghiệm hơn.

Và bạn sẽ chẳng ngạc nhiên khi tôi nói rằng Senior Developer làm chủ được công nghệ của mình.

Bên cạnh kỹ năng coding, họ biết tất cả các công cụ và ứng dụng đang được sử dụng trong công ty mình đang làm.

Tôi xin kết bài bằng một câu nói từ Martin Fowler:

Bất kỳ kẻ ngốc nào cũng có thể viết code sao cho máy tính hiểu được. Lập trình viên giỏi viết code con người có thể hiểu được.

Theo Daan

Categories
Dev's Corner

Senior Software Engineer cần đáp ứng những tiêu chí nào?

Tylor Borgeson, một full-stack software developer chia sẻ quan điểm của mình về những kỳ vọng dành cho vị trí Senior Software Engineer. Gambaru mời các bạn đón đọc và cùng chia sẻ.

Tiêu chí của một Senior Software Engineer.
Tiêu chí của một Senior Software Engineer. Ảnh: Christina Morillo – Pexels

Những năm gần đây trong ngành công nghệ phần mềm, các công ty không còn đòi hỏi kỹ sư phải có một bằng cấp cụ thể nữa.

Cá nhân tôi thích điều này bởi vì để làm ngành này, điều thực sự quan trọng là năng lực.

Ứng viên dù có bằng Cử nhân hoặc Thạc sĩ mà không thể giải các bài toán lập trình, hoặc có thể giải thích về Big-O notation (độ phức tạp của thuật toán) nhưng lại không hiểu rõ cách thức hoạt động của MVC (Model-View-Controller) thì chẳng được đánh giá cao.

Tôi cũng cho rằng trở thành một Senior Sofware Engineer làm việc cùng một team đòi hỏi nhiều hơn là số năm kinh nghiệm.

Những tiêu chí để nhận ra một Senior Software Engineer

Code tốt

Đây hẳn là điều hiển nhiên nhất, song những điều cơ bản như vậy giúp phân biệt một dev giỏi và một dev xuất sắc
Đây hẳn là điều hiển nhiên nhất, song những điều cơ bản như vậy giúp phân biệt một dev giỏi và một dev xuất sắc. Ảnh: Chris Ried – Unsplash

Senior Software Dev làm được những việc đơn giản như đặt tên biến và phương thức một cách hiệu quả vì điều này sẽ tạo được tác động lớn.

Họ bắt buộc phải luôn chú tâm đến nguyên lý SOLID, liên tục tìm xem code nào cần tái cấu trúc, tìm dead code, đảm bảo việc test cũng quan trọng như việc code.

Senior Software Dev là người trong team có thể tìm thấy sự cân bằng để code vừa tối ưu vừa dễ hiểu và đảm bảo duy trì được sự cân bằng đó trong team của mình.

Chia sẻ kiến thức

Tôi tin rằng một trong những trách nhiệm quan trọng nhất đối với một Senior Engineer là giúp team member phát triển nhanh nhất có thể.

Điều này có thể được thực hiện theo nhiều cách, chẳng hạn:

  • Lập trình cặp (pair programming) với các dev khác trong team và không cô lập mình.
  • Khi thực hiện một dự án phức tạp, họ chia sẻ giải pháp với các thành viên, có thể trong một cuộc họp riêng. (Nhiều team thường thực hiện buổi chia sẻ kiến thức vào cuối một Sprint để trao đổi với nhau những điều quan trọng mình đã học).
  • Họ biết sự khác biệt giữa việc để team member học hỏi thông qua thử thách và việc hỗ trợ họ, đồng thời tạo được sự cân bằng sao cho member của mình cảm thấy tự tin thay vì thấy kém cỏi.
Giúp team member nâng cao năng lực nhanh nhất có thể
Giúp team member nâng cao năng lực nhanh nhất có thể. Ảnh: Freepik

Kiên trì

Kiên trì là một trong những yếu tố quan trọng nhất để trở thành kỹ sư phần mềm
Kiên trì là một trong những yếu tố quan trọng nhất để trở thành kỹ sư phần mềm. Ảnh: Gelgas – Pexels

Bạn tìm thấy bug. Bạn bắt tay fix lần đầu, lần hai và thậm chí là lần thứ 50 đều chẳng thành. Bạn bắt đầu bực bội, và sau một lúc, tự hỏi mình muốn làm nghề này bao lâu nữa.

Tuy nhiên, khi một cá nhân lùi lại một bước sau khi thử và thất bại 50 lần, hít một hơi thật sâu, ăn một ít sô cô la, và sau đó thành công trong lần thử thứ 51, đó chính là điều bắt buộc để cá nhân đó trở thành một Senior Engineer – một người chịu khó, bản lĩnh để nâng đỡ team vượt qua mọi thử thách.

Cởi mở, ham học những điều mới

Ngành công nghệ là một trong những ngành phát triển nhanh, nếu không muốn nói là nhanh nhất trên thế giới.

Cứ mỗi một hoặc hai năm, một số công nghệ, công cụ hoặc ngôn ngữ mới ra đời để giải quyết vấn đề hoặc mở rộng một cái gì đó đang có sẵn.

Để theo kịp, Developer phải luôn học hỏi những điều mới
Để theo kịp, Developer phải luôn học hỏi những điều mới. Ảnh: Blake Meyer – Unsplash

Một trong những điều đáng buồn nhất là khi một người lập trình theo cùng một cách, hoặc với cùng một công nghệ trong nhiều năm và do đó cảm thấy không cần phải học một cái gì đó mới, hoặc thử mày mò một cái gì đó nữa.

Tôi thường nghe câu đại loại như “Tôi muốn sử dụng ngôn ngữ A vì tôi không phải là chuyên gia về ngôn ngữ B” và tôi có thể hiểu điều này, nhưng có lẽ ngôn ngữ B phù hợp với vấn đề bạn đang phải giải quyết hơn thì sao?

Và nếu như tất cả các member khác đều giỏi ngôn ngữ B hơn thì sao?

Việc biết cú pháp và thủ thuật một ngôn ngữ lập trình không quan trọng bằng quá trình tư duy và hiểu biết về hệ thống và cách các thành phần tương tác với nhau.

Ta luôn có thể tìm hiểu về cú pháp hoặc thủ thuật trên Stack Overflow.

Ngoài ra, học một cái gì đó mới cũng có nghĩa là có được trải nghiệm mới và những cách tư duy vấn đề mới mẻ hơn.

Khả năng nhìn nhận tổng quan

Khả năng nhìn nhận được tổng quan về toàn bộ hệ thống
Khả năng nhìn nhận được tổng quan về toàn bộ hệ thống. Ảnh: Alex Powell – Pexels

Điều này đôi khi liên quan trực tiếp đến việc một người đã làm ở công ty bao lâu, nhưng tất cả Senior Engineer giỏi nhất mà tôi đã làm việc cùng đều có khả năng tuyệt vời nhìn nhận được tổng quan về toàn bộ hệ thống và do đó nhanh chóng hiểu được chức năng có thể hoặc nên được thực hiện như thế nào, và, thậm chí, có thể nhanh chóng xác định điều gì gây ra bug.

Khi đang cùng xử lý bug, một teammate của tôi đã không cần nhìn vào code mà nói với tôi rằng khả năng là do File A trên Dòng 25 hoặc File B trên Dòng 47.

Điều đó thật sự rất ngầu.

Đồng cảm

Cuối cùng, theo tôi, điều quan trọng nhất mà một Senior Engineer cần có, là sự đồng cảm
Cuối cùng, theo tôi, điều quan trọng nhất mà một Senior Engineer cần có, là sự đồng cảm. Ảnh: Andre Moura – Pexels

Hãy hiểu rằng mọi member của mình đang cố gắng hết sức, rằng mọi người vẫn đang học hỏi và sẽ tiếp tục học hỏi, kể cả bạn.

Hãy công nhận sự liên quan và tiềm năng của tất cả các ý tưởng khác nhau, không phải chỉ của riêng mình.

Những điều này gần như không thể dạy được, bạn phải tự trải nghiệm và tự học, nhưng chúng sẽ tạo ra tác động tích cực lớn hướng tới việc xây dựng một team nơi mọi người đều cảm thấy thoải mái và được tin tưởng.

Tôi hy vọng rằng mình sẽ không bị hiểu lầm khi nói rằng hơn 8 năm kinh nghiệm không phải là yếu tố làm nên vị trí Senior Dev.

Kinh nghiệm là quan trọng. Nhưng tôi cũng tin rằng vị trí này đòi hỏi những kỹ năng khác cần liên tục được trau dồi.

Theo Tylor Borgeson

Categories
Dev's Corner

7 Thói quen của một lập trình viên thành công

Để chuẩn bị cho một buổi phỏng vấn, các kỹ sư phần mềm thường dành nhiều thời gian tập code trên leetcode (https://leetcode.com/) và tút tát lại CV.

Và rồi sau khi nhận được một công việc hấp dẫn, họ mới nhận ra những kỹ năng hiện có lại chưa phù hợp với những gì hằng ngày mình đương đầu.

Làm thế nào để rèn luyện và nâng cao những kỹ năng cần thiết luôn là chủ đề lập trình viên quan tâm. Hãy cùng Gambaru tìm hiểu:

7 Thói quen của lập trình viên thành công

1. Học cách đọc code người khác viết

Bạn đang có tư duy “Tất cả mọi người trừ tôi đều viết code dở tệ
Bạn đang có tư duy “Tất cả mọi người trừ tôi đều viết code dở tệ”? Ảnh: Medium

Cho dù code được viết bởi một dev làm trước bạn hay thậm chí là do bạn viết một năm trước có lộn xộn thế nào, bạn vẫn cần phải học cách hiểu được nó.

Kỹ năng này mang đến nhiều lợi ích.

Thứ nhất, có thể đọc được code người khác viết là cơ hội tuyệt vời để hiểu về cách code, những gì nên và không nên khi code.

Quan trọng hơn, bạn biết thêm rằng loại code nào thì dễ dàng cho dev hiểu và kế thừa sử dụng.

Có thể đọc được những đoạn code lộn xộn người khác viết cũng giúp bạn dễ dàng cập nhật khi cần, đôi khi là cập nhật những đoạn code bạn có ít kinh nghiệm.

Tôi đã từng đọc một script từ Powershell sang Python sang Perl.

Dù có kinh nghiệm hạn chế về Perl, nhưng tôi vẫn có đủ nền tảng để hiểu những gì đang diễn ra và thực hiện các thay đổi cần thiết.

Điều này xuất phát từ việc có độ am hiểu về tất cả các code cũng như có thể đọc được các Perl script.

2. Độ nhạy đối với các dự án tệ

Phải thực hiện rất nhiều dự án tệ trước khi bạn nhận ra được ngay một dự án có ổn hay không
Phải thực hiện rất nhiều dự án tệ trước khi bạn nhận ra được ngay một dự án có ổn hay không. Ảnh: Snapwire – Pexels

Có nhiều kỹ năng cần mất nhiều thời gian để học nhưng xứng đáng. Một trong những kỹ năng đó là hiểu những dự án nào không đáng làm và chỉ đi vào ngõ cụt.

Một số dự án có thể chẳng có giá trị kinh doanh nào và được quản lý rất kém. Điều này không có nghĩa là bạn nên từ bỏ ngay khi cảm thấy không đồng tình với nó.

Tuy nhiên, nếu các bên liên quan không thể giải thích chính xác những gì họ sẽ làm với kết quả cuối cùng, thì có lẽ dự án đấy không đáng tham gia.

Ngoài ra, một số dự án có thể tập trung vào công nghệ thay vì giải pháp đến mức có thể rõ ràng ngay từ đầu rằng dự án đấy không mang được nhiều tác động.

Kỹ năng này đòi hỏi phải thực hiện rất nhiều dự án tệ trước khi bạn nhận ra được ngay một dự án có ổn hay không. Tại một số thời điểm trong sự nghiệp của mình, tự khắc bạn sẽ có dự cảm đúng.

3. Tránh các cuộc họp không cần thiết

Tranh các cuộc họp không cần thiết
Sắp xếp thời gian hợp lý cho các cuộc họp cần thiết. Ảnh: Burst

Dù bạn là software engineer hay data scientist, các cuộc họp là cần thiết bởi ta cần phải thống nhất quan điểm với PM, end-user và client của mình. Tuy nhiên, cũng có lúc những cuộc họp không cần thiết chiếm lấy toàn bộ lịch trình trong ngày.

Mục tiêu ở đây là đảm bảo bạn dành thời gian cho các cuộc họp quan trọng, thúc đẩy được quyết định và giúp team phát triển.

Phương pháp phổ biến nhất là sắp xếp hai giờ mỗi ngày cho việc họp hành.

Thông thường, hầu hết mọi người sẽ có một cuộc họp định kỳ tại thời điểm họ thấy có lợi và dùng thời gian đó để nắm được tiến độ công việc.

Một cách khác là đi làm sớm. Điều này hữu ích với tôi vì lúc đó văn phòng yên tĩnh hơn, ít ai làm phiền mình.

Quản lý thời gian tốt là rất quan trọng đối với dev vì công việc đòi hỏi họ những lúc phải tập trung và không nói chuyện với người khác.

Vào thời điểm đang tập trung, có rất nhiều ý tưởng phức tạp trong đầu và nếu liên tục dừng lại, có thể rất khó để để họ nối lại dòng suy nghĩ trước đó.

4. Sử dụng Git

Biết cách sử dụng Git mang lại nhiều lợi ích
Biết cách sử dụng Git mang lại nhiều lợi ích. Ảnh: Medium

Đối với kỹ sư phần mềm, Git chứa các lệnh và quy trình phức tạp. Không ai chắc chắn 100% những gì mình đang làm (lý do tại sao cheat sheet lại phổ biến).

Cho dù công ty của bạn sử dụng hệ thống lưu trữ nào, sử dụng Git sẽ hữu ích nếu dùng đúng cách và gây trở ngại nếu ngược lại.

Push và commit sai, bạn phải dành hàng giờ cố mà gỡ rối nhiều branch chồng chéo. Ngoài ra, nếu liên tục quên pull bản repo mới nhất, bạn sẽ phải xử lý các merge conflict chẳng vui chút nào.

Hãy làm cuộc sống dễ thở hơn bằng việc giữ một bản Git command cheat sheet chẳng hạn.

5. Viết code đơn giản, dễ maintain

Viết code đơn giản, dễ maintain
Đừng nên tạo ra sự phức tạp không cần thiết. Ảnh: Medium

Các dev trẻ tuổi hay có xu hướng cố thực hiện tất thảy điều mình biết vào một giải pháp, áp dụng hiểu biết về lập trình hướng đối tượng, cấu trúc dữ liệu, design pattern và công nghệ mới vào mọi code họ viết ra.

Thực tế, điều này tạo ra một sự phức tạp không cần thiết bởi vì nó rất dễ bị gắn quá nhiều vào một giải pháp hoặc design pattern bạn đã từng sử dụng.

Có một sự cân bằng giữa các khái niệm design phức tạp và code đơn giản.

Các design pattern và object-oriented design được cho là để đơn giản hóa code trong bức tranh tổng thể. Quá trình càng được trừu tượng hóa (abstracted), đóng gói (encapsulated) và black-box, thì càng khó để debug.

6. Học cách từ chối và ưu tiên

Học cách từ chối và ưu tiên
Khối lượng công việc luôn là vô tận. Hãy đảm nhận những gì mình có thể được thực hiện. Ảnh: Pexels

Kỹ năng này thực sự phù hợp với bất kỳ vai trò nào, dù bạn là nhà phân tích tài chính hay kỹ sư phần mềm.

Ưu tiên và từ chối có thể là hai kỹ năng khác nhau, nhưng chúng có mối liên hệ chặt chẽ.

Ưu tiên có nghĩa là bạn chỉ dành thời gian tạo ra tác động lớn cho công ty. Từ chối đôi khi chỉ có nghĩa là tránh nhận việc nên được xử lý bởi một team khác.

Chúng thường xảy ra song song cho tất cả các vai trò.

Đây có thể là một kỹ năng khó đạt được vì ai trong chúng ta cũng thường có mong muốn hoàn thành mọi yêu cầu được đặt cho mình.

Đặc biệt là nếu vừa tốt nghiệp đại học, bạn sẽ muốn tránh làm người khác thất vọng.

7. Tư duy thiết kế vận hành

Thiết kế tư duy vận hành
Suy nghĩ thấu đáo về các kịch bản vận hành. Ảnh: Medium

Một kỹ năng khó để kiểm tra khi phỏng vấn và khó có thể học theo khi học đại học là suy nghĩ về cách end-user có thể sử dụng phần mềm của bạn không chính xác.

Tôi gọi đó là suy nghĩ thấu đáo về các kịch bản vận hành. Tuy nhiên, đây chỉ là một cách lịch sự để nói rằng bạn phải cố gắng viết code sao cho dễ hiểu và sử dụng nhất thôi.

Ví dụ, vì phần lớn việc lập trình là maintain nên ta thường phải thay đổi code bị rối bằng code khác.

Ngay cả một thay đổi đơn giản cũng yêu cầu truy tìm mọi tham chiếu có thể có của một object, method, và/hoặc API.

Nếu không, ta có thể dễ dàng vô tình break các mô-đun được đính kèm mà không nhận ra, ngay cả khi chỉ thay đổi một loại dữ liệu trong database.

Nó cũng bao gồm nghĩ thấu đáo về các các edge case và toàn bộ thiết kế cấp cao trước khi lập trình.

Đối với các trường hợp phức tạp hơn khi đang phát triển các mô-đun hoặc microservice mới, điều quan trọng là phải dành thời gian nghĩ về các kịch bản vận hành của những gì đang xây dựng.

Hãy hình dung cách người dùng trong tương lai có thể cần sử dụng mô-đun mới, cách họ có thể sử dụng nó không chính xác, những tham số nào có thể cần thiết và những cách khác nhau một dev có thể cần code của bạn trong tương lai.

Rất dễ tạo ra phần mềm hoạt động tốt trên máy tính của bạn, nhưng có rất nhiều cách code có thể bị triển khai sai.

Ở quá trình production, bạn khó có thể nói code sẽ được sử dụng như thế nào và code nào khác sẽ được gắn vào code gốc của bạn.

Năm năm kể từ bây giờ, một dev có thể cảm thấy khó chịu về những hạn chế bởi code bạn viết ra.

Theo SeattleDataGuy