CV .NET
Understand the JavaScript Function
- https://javascriptweblog.wordpress.com/2010/07/06/function-declarations-vs-function-expressions/
- https://dmitripavlutin.com/6-ways-to-declare-javascript-functions/
- Hiểu được kiến thức nền tảng của lập trình
- Object Oriented programming (Lập trình hướng đối tượng)
- Data Structure (Cấu trúc dữ liệu)
- Algorithm (Thuật toán)
- Học cách sử dụng các công cụ một cách hiệu quả
- Stackoverflow: https://stackoverflow.com/ (Where Developers Learn, Share, & Build Careers)
- Quora: https://www.quora.com/ (Questions & Answers)
- Khan Academy: https://www.khanacademy.org/ (Free Online Courses, Lessons & Practice)
- Codeconquest: http://www.codeconquest.com/
- Codecademy: https://www.codecademy.com/ (Learn to code interactively, for free)
- Freecodecamp: https://www.freecodecamp.org/ (Learn to code for free)
- Stackify: https://stackify.com/ (The Dev Tool for Diagnosing App Performance Issues)
Chân dung một lập trình viên hoàn hảo?
Tinh thần ở đây là gì? Sức khỏe tốt, một tinh thần thoải mái, không thể thiếu sự cởi mở, tinh thần dám lắng nghe.
Thái độ ở đây là gì? Là sự tôn trọng, tôn trọng những người làm việc chung, và biết nhìn nhận cái sai của mình - đó cũng là cách tôn trọng chính cá nhân bạn.
Trách nhiệm của Developer là gì? Hãy nghĩ sản phẩm mình đang code như là chương trình phẫu thuật cho chính trái tim của mình, sản phẩm mình viết ra như mạng sống của chính mình thì mình sẽ thấy sợ, sẽ có trách nhiệm với những gì mình làm ra.
Câu chuyện của những người tài năng
https://www.topitworks.com/blogs/category/talent-story/
- Một sản phẩm đáp ứng được tất cả yêu cầu và thoả thuận ban đầu với khách hàng.
- Khi đến tay end-user, họ cảm thấy hài lòng khi sử dụng và đánh giá tốt, cùng những comment tích cực
Bổ xung thêm một số công nghệ cho hình phía dưới:
- HTML, JS, CSS
- Python Cheat Sheet
- MySQL Cheat Sheet
- ASP.NET WebForm
- ASP.NET Core
- OWASP Top 10 (Open Web Application Security Project)
- Tools để kiểm tra phát hiện ra top 10 rủi ro anh ninh của ứng dụng web:
- BurpSuite
- Acunetix
- Sqlmap
- Netsparker
- IdentityServer4
- OAuth2 & OpenID Connect
- Cloud computing: Azure, AWS
- Bootstrap 4
- Angular 5
- Dapper (Using Dapper in C#)
- Entity Framework Core
- ElasticSearch
- Amazon Elasticsearch Service
- Elasticsearch cluster using Azure
- Cache with Redis
Is Redis just a cache?
No, Redis is much more than a cache.
Like a Cache, Redis stores key=value pairs. But unlike a cache, Redis lets you operate on the values. There are 5 data types in Redis - Strings, Sets, Hash, Lists and Sorted Sets. Each data type exposes various operations.
The best way to understand Redis is to model an application without thinking about how you are going to store it in a database.
Lets say we want to build StackOverflow.com. To keep it simple, we need Questions, Answers, Tags and Users.
Những câu chuyện về nghề lập trình
Lập trình viên sau tuổi 40
https://techtalk.vn/lap-trinh-vien-sau-tuoi-40.html
https://techtalk.vn/lap-trinh-vien-sau-tuoi-40-2.html
Nghề lập trình cần tự học 10 năm
Lập trình viên chuyên nghiệp
https://techmaster.vn/posts/7646/lap-trinh-vien-chuyen-nghiep
https://techmaster.vn/posts/7669/lap-trinh-vien-chuyen-nghiep-2
Nếu bạn phải đoán điều lập trình viên ghét nhất là gì, bạn sẽ trả lời sao?
Trên Quora, câu hỏi này đã thu hút 90 replies và gần 450k lượt xem. Rõ ràng vấn đề này khá thu hút được sự quan tâm của mọi người. Điều khiến tôi ngạc nhiên là một số vấn đề mà các lập trình viên phàn nàn lại có thể tránh được khá dễ dàng.
Trong bài viết này, tôi muốn giới thiệu với các bạn các best practices trong quản lý dự án được thực hiện tại công ty tôi, giúp chúng tôi duy trì một quy trình làm việc phù hợp và giữ cho nhân viên của mình luôn có động lực làm việc.
Tôi nghĩ rằng sẽ rất thú vị khi hỏi các dev tôi làm việc cùng tại Apptension về những cái họ không thích, để tôi có thể so sánh quan điểm của họ với các câu trả lời trên Quora.
Những sai lầm cần tránh khi làm việc với các lập trình
Tại Apptension chúng tôi cố gắng duy trì một không gian làm việc vui vẻ và năng suất, điều nãy đã được đưa vào chiến lược xây dựng thương hiệu của mình.
Vì vậy, tôi đã hỏi đồng nghiệp của tôi một câu hỏi này: Lập trình viên ghét gì?
Đây là những gì họ nói với tôi.
1. Requirement không ra gì
Đôi khi đó là những lỗ hổng trong yêu cầu, dự án không xác định hoặc trao đổi không rõ ràng giữa khách hàng, PM (project manager) và dev đến phần mềm còn nhiều thiếu sót.
Nếu khách hàng hoặc người quản lý không nắm rõ về sản phẩm của họ, họ không nên mong đợi người khác có thể đọc vị họ và thực hiện những việc họ chưa hề đề cập đến.
Công việc của người quản lý là tổng hợp yêu cầu tài liệu của dự án một cách hoàn chỉnh nhất, để dev không cần phải đoán già đoán non hoặc tự đi hỏi về các yêu cầu đặc tả.
2. Những công việc lặp đi lặp lại
Làm một việc lần này qua lần khác không chỉ gây nhàm chán, nó còn có thể khiến con người ta mệt mỏi.
Vấn đề này có thể xảy ra khi một người chỉ làm một dự án trong một thời gian dài. Nó cũng có thể xảy ra khi một tính năng mà khách hàng cứ đổi ý đòi sửa hoài.
Dù lí do là gì đi nữa, nếu dev cảm thấy kiệt sức bởi các yêu cầu lặp đi lặp lại, đó có lẽ là lúc người quản lý nên nói chuyện với họ.
Nếu có thể, hãy điều chuyển nhân viên đó sang dự án khác. Đôi khi một sự thay đổi đơn giản ở công việc mà một người đang đảm nhiệm có thể làm công việc thú vị hơn nhiều và khiến cho người đó giữ lửa trong công việc. Tại Apptension, chúng tôi sử dụng Officevibe để khảo sát nhân viên một cách ẩn danh, để xem mức độ hài lòng của nhân viên trong công việc.
3. Technical debt (Nợ kỹ thuật)
Technical debt là hệ quả của việc dùng giải pháp đơn giản mà không suy nghĩ về khả năng mở rộng của dự án trong tương lai.
Nói cách khác: đó là kết quả của việc lựa chọn cách giải quyết vấn đề không hẳn là tốt nhất mà chỉ vì nó có thể được thực hiện nhanh chóng và dễ dàng.
Lý do các dev ghét Technical debt rất đơn giản: Cũng giống như nợ nần tài chính, một lúc nào đó bạn sẽ phải “trả nợ”, mà trong phát triển phần mềm có nghĩa là giải quyết cùng một vấn đề một lần nữa.
Để trả nợ, các dev thường cần viết lại code để hoàn thành “công việc còn dang dở”. Nó cũng gây ra việc trễ deadline, vì rất khó để ước tính được lượng việc cần làm để trả xong nợ.
Giải pháp: đừng làm gì đó chỉ bởi vì nó có vẻ dễ dàng. Hãy suy nghĩ về các giải pháp tốt nhất có thể và triển khai nó chỉ 1 lần thôi.
4. Không đủ hoặc quá nhiều nhiệm vụ
Không trọng dụng nhân viên có thể làm giảm động lực làm việc của họ, trong khi giao quá nhiều việc lại khiến họ mệt mỏi, kiệt quệ.
Một công ty tốt có thể hạn chế cả hai tình trang trên bằng cách phân bổ nhân lực một cách phù hợp. Các công cụ như teamdeck có thể giúp quản lý, duy trì nguồn tài nguyên (nhân lực) phù hợp giữa các dự án và giám sát việc sử dụng tài nguyên của nhóm.
5. Sự gián đoạn
Phải mất có thể tận 45 phút để một lập trình viên có thể vào guồng, ở trạng thái tập trung sâu sắc nhất, đảm bảo năng suất lớn nhất. Tuy nhiên bị sao lãng lại nhanh hơn nhiều. Đôi khi chỉ một câu hỏi được hỏi trực tiếp hoặc từ những trình chat như Slack khiến lập trình viên đánh mất trạng thái tập trung cực độ.
Một cách khác khiến việc tập trung gián đoạn là context switching (chuyển đổi ngữ cảnh). Điều này có thể xảy ra khi một dev đang phải đảm nhiệm nhiều dự án khác nhau trong ngày.
Việc công ty điều chuyển nhân viên có thể gây lãng phí thời gian hoặc làm dự án bị chậm trễ vì nhân viên cần thời gian để chuyển từ dự án này sang dự án khác .
Trong khi quản lý dự án, cố gắng lên kế hoạch chi tiết và tránh làm gián đoạn các lập trình viên khi họ đang làm việc.
Đối với những gián đoạn nhỏ, hãy thực hiện “quy tắc tai nghe”. Có nghĩa là nếu một nhà phát triển đang đeo tai nghe thì đừng làm phiền họ. Các vấn đề quan trọng liên quan đến dự án cố gắng giải quyết trong cuộc họp scrum – đó là tác dụng của buổi họp đó.
Việc này sẽ giúp công việc của lập trình viên ít căng thẳng và hiệu quả hơn.
6. Các cuộc họp không cần thiết
Không phải tất cả cuộc họp là cần thiết. Và chắc chắn lập trình viên không cần lúc nào cũng phải có mặt trong phần lớn các cuộc họp đó.
Tuy nhiên, có những cuộc họp đòi hỏi phải có sự góp mặt của các lập trình viên như sprint planning, các buổi đánh giá dự án hay retrospectives. Ở đây họ có thể trả lời các câu hỏi kỹ thuật hoặc để cùng thảo luận về quá trình phát triển.
Lên kế hoạch họp hành, quyết định xem các dev có cần tham dự hay không. Nếu không, họ có thể dành thời gian đó hiệu quả hơn cho dự án.
7. QAs kém
Đảm bảo rằng code có chất lượng là điều quan trọng. Và hầu hết các nhà phát triển đều hiểu được vai trò của QA.
Nhưng điều mà lập trình viên ghét, là những tester trình độ kém, những người làm gián đoạn công việc của họ thay vì giúp cải thiện code với các báo cáo có ý nghĩa.
Các QA kém đặc biệt gây phiền hà và làm gián đoạn công việc khi họ ưu tiên các vấn đề sai, tập trung vào các lỗi nhỏ thay vì các vấn đề chính hoặc khi họ bỏ qua các thông tin quan trọng trong các báo cáo lỗi.
Mặt khác, QA giỏi có thể đảm bảo chất lượng của phần mềm và giúp các dev trong công việc của họ, thay vì làm gián đoạn nó.
Khi tuyển dụng thành viên của nhóm đảm bảo chất lượng (QA), hãy lựa chọn sáng suốt bởi vì nó sẽ không chỉ mang lại chất lượng tuyệt vời cho phần mềm, mà còn làm cho mối quan hệ giữa họ và các dev ít đau thương hơn.
8. Lộ trình không rõ ràng
Đối với mỗi tính năng trong phát triển phần mềm cần phải có một thời gian hoàn thành rõ ràng.
Các mốc quan trọng giúp xác định khi nào một tính năng nhất định phải được hoàn thành, và khi nào khách hàng kì vọng dev triển khai sản phẩm.
Một lộ trình không rõ ràng hoặc thiếu sót làm cho nhóm khó khăn hơn trong việc đánh giá độ ưu tiên của các tính năng trong dự án và bàn giao tính năng đúng hẹn.
Một lý do khác để lên lộ trình làm việc tốt hơn là việc làm việc theo team của dev đòi hỏi phải đồng bộ công việc của nhiều người để bàn giao một tính năng nhất định.
Khi chạy dự án cần phân tích từng giai đoạn của nó, bao gồm các cuộc họp scrum, hạn bàn giao tính năng, và hạn bàn giao sản phẩm. Sau đó đánh dấu những mốc đó vào lịch của dev.
9. Không tính đến các sự kiện trong sprint planning
Quản lý dự án phù hợp giúp các nhà phát triển tập trung vào đúng việc đúng thời điểm.
Tính các sự kiện như Sprint Review, Retrospective, Planning và Daily Standups trong lịch của dev đảm bảo luồng dự án hợp lí.
Nếu không làm điều đó, mỗi lần gọi đi họp sẽ là một lần làm gián đoạn lập trình viên, và bạn đã biết rằng nó sẽ gây phiền nhiễu và gián đoạn công việc của họ.
10. Ước tính công việc theo giờ
Ước tính công việc theo giờ hay được xem như là “đọc lá chè” (một cách để dự đoán tương lai).
Vì các lập trình viên khác nhau cần lượng thời gian khác nhau cho cùng một công việc, thật khó để đặt mốc hoàn thành chính xác.
Tuy nhiên, vẫn còn nhiều nhà quản lý yêu cầu ước tính thời gian cho công việc và coi chúng như là thời hạn hoàn thành công việc.
Mặc dù việc một công ty ước tính một dự án sẽ mất bao lâu là quan trọng, nó cần được thực hiện dựa trên các dự án tương tự gần đây và luôn hiểu rằng nó không có nghĩa là dự án mới sẽ cần chính xác số giờ đó.
Để nâng cao khả năng ước tính của mình, bạn có thể xem xét point của các story (nhiệm vụ phải làm). Đó là một khái niệm Scrum được sử dụng để ước lượng công sức hoàn thành một story. Story point bao gồm cả số lượng công việc và tính phức tạp của nó.
Nếu một công ty theo dõi story points, họ có thể dự đoán tốt hơn các dự án dựa trên các story tương tự từ trước.
Kết luận
Nắm rõ những điều khiến lập trình viên khó chịu, bạn có thể giữ cho nhân viên của mình động lực làm việc và tập trung vào những thứ cần thiết
Tránh những điều trên trong công ty có thể giúp tạo ra một nơi làm việc hạnh phúc hơn cho nhóm của bạn.
Và như nghiên cứu cho thấy, nhân viên hạnh phúc có năng suất lên đến 12% so với người không hạnh phúc.
Có điều gì bạn muốn thêm vào danh sách này không? Hãy comment và chia sẻ nhé.
(Theo Hackernoon)
