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 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! 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
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
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 Patternizer và Patternify, 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
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
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
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
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.
Những lần gặp khó khăn khi code là những lần ta tích lũy kinh nghiệm, nhận ra được các mẫu có tính lặp lại và khám phá những chiến lược nhất định. Nếu phân loại được đoạn code và những vấn đề tương tự sẽ giúp ích rất nhiều cho lập trình viên.
Tập trung giải quyết vấn đề để cải thiện kỹ năng lập trình. Ảnh: lloorraa – Pixabay
Việc học giải quyết vấn đề theo hệ thống như vậy đã được thảo luận từ rất lâu.
Gambaru xin giới thiệu với các bạn một trong những nhà toán học tuyệt vời đã chia sẻ về vấn đề này, George Polya, qua cuốn sách nổi tiếng How to solve it, a new aspect of mathematical method xuất bản lần đầu năm 1945.
Không rõ George Polya có mong đợi lập trình viên thế kỷ 21 đọc được tác phẩm toán của mình hay không, nhưng tôi mong các bạn nhận ra được những góc nhìn của ông có giá trị đến thế nào.
Nhà toán học George Polya. Ảnh: Alchetron
Sách How to Solve it – A new aspect of mathematical method viết bởi George Polya. Ảnh: Amazon
Giải quyết vấn đề không phải là một năng khiếu
“Giải toán là một kỹ năng thực tế như bơi lội. Chúng ta thành thục được bất kỳ kỹ năng nào bằng cách bắt chước và thực hành. Khi tập bơi, bạn bắt chước theo cách mọi người dùng tay và chân để giữ cho đầu ở trên mặt nước và cuối cùng, bạn biết bơi nhờ tập luyện. Khi tập giải toán, bạn quan sát và bắt chước những gì người khác làm khi giải toán và cuối cùng, bạn biết giải toán nhờ thực hành.”
– George Polya, How to solve it
Giải quyết vấn đề không chỉ là về “trí óc”
“Dạy giải toán chính là sự rèn luyện ý chí. Để giải quyết những bài khó, người học sẽ học cách kiên trì vượt qua thất bại, trân trọng những tiến bộ nhỏ, chờ đợi ý tưởng cần thiết và tập trung hết sức khi ý tưởng xuất hiện.”
– George Polya, How to solve it
Quyết tâm và cảm xúc đóng một vai trò quan trọng khi giải quyết các vấn đề khó.
Quy trình giải quyết vấn đề
Bất cứ khi nào thực hiện quá trình giải quyết vấn đề, hãy ghi nhớ bốn bước sau:
Hiểu vấn đề
Lập kế hoạch
Thực hiện kế hoạch
Nhìn lại và đánh giá
1. Hiểu vấn đề
“Thật ngớ ngẩn khi trả lời một câu hỏi bạn không hiểu. Thật đáng buồn khi làm việc để ra một kết quả bạn không mong muốn.” – George Polya, How to solve it. Nguồn ảnh: Rawpixel
Trước khi đi tìm giải pháp, cần phải trình bày được tất cả các yếu tố của vấn đề để hiểu nó rõ hơn.
Bạn có thể nêu vấn đề trong một câu không?
Bài tập nhỏ này rất hữu ích: thuyết phục bản thân rằng bạn đã hiểu mục tiêu và không tốn quá nhiều năng lượng để hiểu nó nữa khi đang tập trung giải quyết vấn đề.
Như được đề cập trong sách The Pragmatic Programmer, khi lập trình viên debug với “vịt cao su” chính là buộc bản thân phải hiểu rõ vấn đề để có thể dạy nó cho người khác.
Kỹ thuật debug đỉnh cao với vịt cao su: Bạn có giải thích được vấn đề cho người khác
Có những ràng buộc nào cần phải đáp ứng không?
“Trước hết, hãy hiểu vấn đề một cách tổng thể. Từ đó, ta mới có thể đánh giá những điểm cụ thể nào là quan trọng nhất. Sau khi xem xét một hoặc hai điểm trọng yếu, ta mới có thể đánh giá xem chi tiết nào đáng để điều tra kỹ hơn. Hãy đi vào sâu chi tiết và phân tích vấn đề dần dần, nhưng không đi xa hơn mức mình cần.” – George Polya, How to solve it. Ảnh: Freepik
Những hạn chế trong vấn đề bạn đang giải quyết là gì?
Hãy viết chúng ra. Nó có thể là một comment phía trên dòng đầu tiên của một hàm bạn viết, một danh sách các gạch đầu dòng trên đầu tài liệu thiết kế.
Điều quan trọng là phải tập trung vào chúng khi cố gắng tìm giải pháp.
Gỡ bỏ nhiều ràng buộc khỏi bộ não cũng là một cách loại bỏ một số quả bóng khi tâm trí ta chơi trò “tung hứng” trong khi cố gắng đưa ra một ý tưởng hay.
Ngoài ra, hãy cẩn thận nếu có quá nhiều ràng buộc.
Theo Polya, nếu xem xét quá nhiều chi tiết cùng một lúc, bạn có thể lạc lối. Chúng có thể khiến bạn mất tập trung vào điểm chính yếu hoặc thậm chí không nhìn thấy điểm chính yếu đó.
Bạn có thể vẽ hình minh họa hay một hệ thống ký hiệu phù hợp?
Vẽ minh họa hay hệ thống ký hiệu “Một bước quan trọng khi giải toán là chọn hệ thống ký hiệu. Điều này cần được thực hiện một cách cẩn thận. Làm được ta sẽ tiết kiệm thời gian cho sau này do tránh được những do dự và nhầm lẫn không đáng.” – George Polya, How to solve it. Nguồn ảnh: Sarah Pflug – Burst
Các bản vẽ hay phác thảo sẽ giúp bỏ bớt một số suy nghĩ ra giấy và tạo nhiều khoảng trống hơn cho bộ não tập trung vào những phần khó.
Hãy chọn hệ thống ký hiệu giúp bạn hiểu rõ mọi thứ hơn: diagram, flowchart….
2. Lập kế hoạch
“Ta có kế hoạch khi biết, hoặc ít nhất là biết sơ bộ, mình phải thực hiện những phép tính, thuật toán hoặc cấu trúc nào để tìm ra lời giải. Con đường từ hiểu vấn đề đến hình thành một kế hoạch có thể dài và quanh co. Thành tựu chính khi tìm ra giải pháp là hình thành ý tưởng về một kế hoạch.” – George Polya, How to solve it. Nguồn ảnh: ThisIsEngineering – Pexels
Giải quyết vấn đề trên giấy trước. Việc viết code luôn có vẻ dễ dàng hơn trong đầu và trở nên phức tạp hơn nhiều khi làm nó chạy được.
Đừng làm cả hai việc cùng một lúc. Đầu tiên, hãy giải quyết vấn đề. “Chạy thử” một ví dụ trên sổ hoặc trên pseudocode. Sau đó, chạy trên máy.
Bạn có biết một vấn đề liên quan?
Bạn cần biết ít nhất loại vấn đề hoặc nhóm vấn đề bạn đang giải quyết. Đối với dân phần mềm, hãy thử trả lời những câu hỏi sau:
Đây có phải là vấn đề kiến trúc không?
Có những mẫu kiến trúc nào thường được sử dụng trong kịch bản này không?
Vấn đề này có nhiều hơn ở cấp độ của một giải thuật không?
Có giải thuật đã được chứng minh có thể giải quyết loại vấn đề này không?
Khi có thể tìm thấy một vấn đề liên quan đến vấn đề của mình và đã được giải quyết trước đó, bạn nên ăn mừng.
Đặt tiếp câu hỏi: “Mình có thể sử dụng nó không?”
Nhiều vấn đề có thể có một số điểm chung, nhưng những vấn đề có chung các yêu cầu hoặc nền tảng cốt lõi nhất có lẽ sẽ hữu ích nhất.
Bạn có thể trình bày lại vấn đề được không?
Bạn có thể nhìn nhận vấn đề ở một góc độ khác? Có thể bỏ một phần điều kiện hoặc một số yêu cầu không? Có thể nêu vấn đề này theo một kịch bản cụ thể hơn không?
Nếu đang viết các bài test, hãy thử nghĩ đến các ví dụ đơn giản được tạo ra chỉ bởi các điều kiện cụ thể của vấn đề để tìm ra giải pháp cuối cùng, tổng quát hơn.
Điều này dẫn chúng ta đến…
Nếu không thể giải quyết vấn đề được đề xuất, hãy cố giải quyết một số vấn đề liên quan trước tiên
Hoặc một vấn đề liên quan và đơn giản hơn.
Giống như viết phần mềm hiệu quả, việc thực hiện giải quyết vấn đề hiệu quả có thể được coi là một quá trình mang tính tịnh tiến.
Đừng cố làm mọi thứ cùng một lúc.
Xây dựng code cuối cùng hoặc thậm chí là các sơ đồ và ý tưởng thiết kế hệ thống là một quá trình sẽ mang lại lợi ích rất nhiều từ việc thực hiện điều tương tự cho các vấn đề quy mô nhỏ hơn.
3. Thực hiện kế hoạch
“Đề ra phương án, hình thành ý tưởng giải pháp không hề đơn giản. Ta cần rất nhiều yếu tố để thành công: kiến thức tích lũy, thói quen tư duy, sự tập trung và may mắn. Thực hiện kế hoạch lại dễ hơn nhiều; yếu tố chủ chốt là kiên nhẫn.” – George Polya, How to solve it. Nguồn ảnh: Pixabay
Phiên bản dành cho lập trình viên của câu trên là “Nghĩ trước, code sau”. Khi đã hiểu các bước của giải thuật hoặc thiết kế hệ thống, việc triển khai sẽ dễ dàng hơn rất nhiều.
Polya cho rằng những người giải toán giỏi có khả năng kiểm tra từng bước trong giải pháp sau khi hoàn thành và chất vấn từ đầu đến cuối.
Chỉ một dòng suy nghĩ về phân tích, phép toán sai sẽ làm hỏng mọi thứ.
Điều này có vẻ không mang đến nguy hiểm tức thì trong lập trình phần mềm, nhưng nó có thể là nguy hiểm chí mạng, vì bug nghiêm trọng sẽ xuất hiện trong thời điểm tồi tệ nhất – và có thể trong trường hợp rất cụ thể.
Điều này có nghĩa là cần có phạm vi kiểm thử tốt.
Nếu không kiểm thử, bạn sẽ không chất vấn, cứ tự tin coi giải pháp của mình là hoàn hảo.
Rất hữu ích khi có tư duy “Nó sẽ có lỗi chứ?” và liên tục đưa ra tất cả các kịch bản thất bại khác nhau trong giải pháp của mình và tư duy này sẽ được thể hiện rõ trong các bài test phần mềm.
4. Nhìn lại
“Ngay cả học sinh khá giỏi, khi đã có được lời giải bài toán và viết xong các lập luận, các bạn liền đóng tập lại. Các bạn đã bỏ lỡ một giai đoạn quan trọng. Khi nhìn lại bài giải, xem xét và nhìn nhận lại kết quả và con đường dẫn đến nó, các bạn có thể củng cố kiến thức và phát triển khả năng giải quyết vấn đề của mình.” – George Polya, How to solve it. Nguồn ảnh: Reshot
Không nhìn lại và đánh giá sự đánh đổi của giải pháp thường xảy ra khi mọi thứ được thực hiện trong vội vàng.
Nếu đó là một giải thuật, bạn có thể nói rõ độ phức tạp về thời gian và không gian không? Code có đọc tốt không?
Nếu đang đưa ra quyết định sẽ có tác động đến toàn hệ thống, hãy ghi ra những đánh đổi.
Dành một giờ để xem xét lại kết quả công việc sẽ giúp bạn tiết kiệm hơn rất nhiều sau này.
Bạn có thể nghỉ ngơi rồi quay lại với nó sau. Việc đắm chìm sâu vào vấn đề đang giải quyết có thể sẽ khiến bạn quên mất những chi tiết liên quan.
Ngoài ra, giải pháp cho vấn đề cụ thể đó có thể được tổng quát hóa để được sử dụng trong nhiều tình huống.
Dùng sự nhạy bén và tư duy cẩn thận để tạo ra những abstraction mới là một cách giải quyết vấn đề đó cho những người khác đối mặt với nó sau này.
Kết
Dù là một cuốn sách dạy giải toán, nhưng How to solve it của George Polya với những lời khuyên vượt thời gian của ông lại hữu ích với dân lập trình như tôi khi tập giải quyết vấn đề bởi lập trình thực sự là một quá trình sử dụng nhiều tư duy và kỹ năng giải quyết vấn đề hiệu quả.
Extension Visual Studio Code mọi developer phải có. Ảnh: techrepublic.com
Visual Studio Code là một trong những trình soạn thảo code phổ biến và được sử dụng rộng rãi nhất. Nó cũng đi kèm với rất nhiều tính năng miễn phí so với các code editor khác.
Hãy thử tải về các tiện ích mở rộng trên VS Code và bạn sẽ thấy thêm một khía cạnh khác ở các tính năng tuyệt vời này.
8 Extension Visual Studio Code
1. Turbo Console Log
Turbo Console Log là một tiện ích mở rộng xuất sắc cho việc debug.
Tiện ích mở rộng này giúp debug dễ dàng hơn bằng cách tự động hóa quá trình viết log message có ý nghĩa.
Tự động chèn log message có ý nghĩa với hai bước sau:
Chọn biến là chủ đề debug
Nhấn Ctrl + Alt + L
Turbo Console Log. Ảnh: Medium
2. Import cost
Tốc độ là yếu tố quan trọng cho trang web. Nếu trang web hoặc ứng dụng không thể tải nhanh, thì chẳng phải có cũng như không sao.
Tiện ích mở rộng này hiển thị kích cỡ import. Bằng cách này, bạn sẽ biết khối lượng sẽ tải xuống và tìm ra nguyên nhân ứng dụng hoạt động chậm.
Với tiện ích mở rộng này, bạn có thể quyết định xem mình nên viết một function hay import toàn bộ bundle.
Import cost
3. Prettier
Prettier dành cho tất cả mọi dev viết Python, JavaScript hoặc bất kỳ ngôn ngữ lập trình nào khác.
Cái tên nói lên tất cả, tiện ích này làm cho code đẹp hơn lên.
Cá nhân tôi rất tệ trong việc giữ cho các dòng, khoảng cách và tab bằng nhau. Do vậy, code của tôi nhìn rất lộn xộn.
Với Prettier, ngay sau khi nhấn tổ hợp lệnh + S, bạn sẽ chứng kiến điều kỳ diệu xảy ra. Tất cả code sẽ có khoảng cách chính xác và đều tăm tắp, khoảng cách các dòng cũng sẽ thống nhất.
Không ai có thể nhận ra bạn là người lộn xộn như thế nào 😐.
Prettier. Ảnh: Medium
4. Bracket pair colorizer
Đã bao nhiêu lần xảy ra trường hợp khi chỉnh sửa code JavaScript, bạn luôn gặp khó khăn khi tìm dấu đóng mở ngoặc?
Đừng lãng phí thêm thời gian nữa chứ! Dùng tiện ích này, các dấu mở và đóng ngoặc sẽ được tô màu giống nhau và mọi việc sẽ dễ thở hơn hẳn.
Bracket pair colorizer. ẢNh: Medium
5. Live share
Live share là một tiện ích mở rộng tuyệt vời để code cùng bạn bè và team.
Live share cho phép điều khiển từ xa trình soạn thảo VS code, các tệp đã mở. Một người khác có thể thay đổi và lưu code; vì vậy, giờ đây bạn có thể nhận được mọi trợ giúp từ xa.
Một tính năng khác là bạn có thể code real-time, biết ai đang type và type gì. Bên cạnh đó, nó cũng cấp quyền truy cập vào localhost và thiết bị đầu cuối.
Bonus: Bạn còn có thể tải xuống tiện ích mở rộng âm thanh Live share, bổ sung khả năng gọi âm thanh cực đỉnh. Với các dự án làm việc từ xa, đây quả là một extension miễn phí không thể hoàn hảo hơn!
6. Projects
Nếu bạn đang làm nhiều dự án cùng một lúc thì việc chuyển đổi giữa các folder quả rất khó, khi phải điều hướng đến folder cần thiết phải không.
Projects có thể hoạt động như một tab yêu thích của bạn.
Ví dụ: bạn có thể lưu trữ CSS và bootstrap tùy chỉnh trong một folder và sử dụng Projects để điều hướng giữa các folder một cách nhanh chóng.
Projects. Ảnh: Medium
7. Settings Sync
Tiện ích mở rộng này giúp lưu trữ tất cả bản sao lưu cài đặt của bạn trong GitHub. Bằng cách này, bạn có thể có các cài đặt giống nhau cho nhiều thiết bị hoặc các thiết bị mới của mình. Bất kỳ thay đổi nào đều được đồng bộ hóa liền mạch.
Setting Sync cho phép đồng bộ hóa hầu như là mọi thứ bạn tùy chỉnh trên VS Code sang Github, từ việc cài đặt phím tắt cho đến các tiện ích mở rộng VS Code khác.
8. JavaScript (ES6) Code Snippets
VS Code đi kèm với JS IntelliSense tích hợp sẵn, nhưng JS Code Snippets nâng cao trải nghiệm này hơn nữa bằng cách thêm các đoạn JavaScript snippet được tạo sẵn, chứa các đoạn code được sử dụng phổ biến nhất. Hãy nói tạm biệt việc liên tục lặp lại đoạn code! 🙌
Tiện ích mở rộng này hỗ trợ JS, TypeScript, JS React, TS React, HTML và Vue.
JavaScript (ES6) Code Snippets. Ảnh: Medium
Còn extension nào mà bạn thấy hữu ích nữa không nhỉ? Hãy comment cho cộng đồng Gambaru biết nhé!
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
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? Ả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. Ả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. Ả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,và 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. Ả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 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 và 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. Ả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ọ. Ả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é.
Sự khác nhau giữa Junior, Mid-level và Senior developer. Ảnh: Soumil Kumar - Pexels
Ở 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. Ả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ả. Ả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 ạ. Ả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ì? Ả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.
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. Ả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ể. Ả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. Ả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. Ả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. Ả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. Ả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.
Để 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ệ”? Ả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. Ả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
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. Ả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
Đừ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
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
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.
