Trung tâm này có đầy đủ các dự báo và lời khuyên về những việc cần làm trong năm tới - nên học ngôn ngữ nào, nên tập trung vào lĩnh vực nào, những việc cần làm với sức khỏe của bạn. Nghe có vẻ đầy cảm hứng! Nhưng đồng tiền nào cũng có hai mặt, và chúng ta vấp ngã không chỉ ở những điều mới mẻ mà phần lớn là ở những việc chúng ta làm hàng ngày. “Tại sao không ai cảnh báo tôi!” chúng ta cáu kỉnh kêu lên, thường quay lại với chính mình. Hãy tự mình chữa cháy - chúng tôi đã tổng hợp cho bạn danh sách những điều KHÔNG nên làm trong năm 2020 (và có thể là luôn luôn như vậy).
Nhưng họ không hỏi về trọng lực
Chúng tôi thực sự muốn sắp xếp các khuyến nghị phản đối theo thứ tự, từ quan trọng nhất đến ít quan trọng nhất. Nhưng chúng quá phổ biến, tương đương và quen thuộc với hầu hết mọi người nên chúng tôi sẽ viết ngẫu nhiên. Vâng, hãy kiểm tra danh sách?
Không cần phải đến IT nếu mọi thứ đều ổn
Đừng học một công nghệ mới để thay đổi nghề nghiệp hoặc bắt đầu lại. Thời gian của chúng ta thật tuyệt vời vì bạn có thể học tập, thay đổi công việc, thay đổi hoàn toàn lĩnh vực của mình - v.v., thậm chí cho đến khi nghỉ hưu. Đó là một điều mát mẻ, quyến rũ. Nhưng nếu bạn trên 28-30 tuổi, bạn không nên từ bỏ mọi thứ để vào CNTT hoặc chuyển sang một hệ thống mới (ví dụ: bạn viết các hệ thống có tải trọng cao bằng Java và đột nhiên quyết định chuyển sang mạng thần kinh bằng Python). Lý do rất đơn giản: nó sẽ không dễ dàng với bạn. Thứ nhất, có sự cạnh tranh cao từ các chuyên gia đã “ngồi” trong nhóm này kể từ khi bắt đầu sự nghiệp, thứ hai, bạn sẽ phải trở lại làm cấp dưới với mức lương thấp, và thứ ba, bạn sẽ gặp khó khăn về mặt đạo đức. trở thành cấp dưới của cấp thấp nhất trong hệ thống phân cấp. Vì vậy, nếu bạn muốn chuyển sang hướng khác, hãy cố gắng làm nó phù hợp với công việc và nhiệm vụ hiện tại của bạn, hoặc phát triển kiến thức mới như một sở thích, hãy bắt đầu một dự án thú cưng để khi đến với công việc mới, bạn sẽ không còn là thiếu niên nữa.
Thay đổi hết ngăn xếp này đến ngăn xếp khác chỉ là lãng phí thời gian
Đừng vội vàng giữa các ngăn xếp công nghệ cho sự phát triển của bạn. Nếu bạn đang viết một dự án bằng một ngôn ngữ, sử dụng một framework và thư viện nhất định, bạn không nên ném mọi thứ vào địa ngục và viết lại nó bằng Dart chỉ vì bạn thấy nó thú vị. Hãy đặt ra quy tắc là tìm ra lý do biện minh cho việc thay đổi công nghệ - không chỉ ở cấp độ “Tôi muốn hoặc tôi không thể”, mà còn ở cấp độ tài chính và kỹ thuật.
Không cần phải giữ vững lập trường và biến thành đồng
Bám sát một ngôn ngữ hoặc công nghệ và không học những điều mới cũng giống như việc thay đổi hệ thống của bạn theo mọi công nghệ mới. Hãy nhớ nghiên cứu các thư viện và framework mới, đừng cố chấp khi biết rằng mọi thứ đều được phát minh tốt hơn trước bạn và được hoàn thành độc quyền bởi bạn. Các bản cập nhật liên tục xuất hiện cho hầu hết mọi ngôn ngữ, điều này đôi khi có thể cải thiện đáng kể dự án của bạn. Đừng lười theo dõi tính năng động của ngăn xếp của bạn và ngay khi bạn tìm thấy thứ gì đó thú vị và hữu ích, hãy thoải mái kéo nó vào dự án!
Cái đầu của bạn tốt, luôn tốt
Đừng nghĩ trong đầu người khác, cái đầu của bạn thì tốt hơn. Than ôi, một số nhà phát triển ngồi đợi cho đến khi họ nhận được nhiệm vụ viết mã từ lỗi trước đó đến cuối mà không cố gắng đóng góp điều gì đó của riêng họ cho dự án, phát triển một chức năng mới, thử nghiệm nó và đề xuất nó để đưa vào sản xuất. Tại sao phải bận tâm khi có một trưởng nhóm hoặc người quản lý công ty sẽ tự mình quyết định mọi việc? Nếu bạn nhận ra chính mình, thì chúng tôi có tin xấu: một vị trí thụ động sẽ không giúp ích gì cho sự nghiệp cũng như sự phát triển của bạn. Bạn có cơ hội thử sức mình với tư cách là một kỹ sư phát triển chứ không phải lập trình viên, trong một dự án chiến đấu thực sự và hiểu mình phải đi đâu, điều gì còn thiếu, nhưng bạn thích dành thời gian của mình cho việc khác và làm chính xác “từ đây” đến bây giờ.” Những người như vậy tồn tại ngày càng tệ hơn trong CNTT hiện đại, bước ra từ hoạt hình bị treo.
Người dùng là những người khủng khiếp
Đừng đánh giá quá cao người dùng phần mềm của bạn: nếu bạn không viết cho các lập trình viên, hãy mong đợi chương trình sẽ gặp phải sự hiểu lầm không thể hiểu được. Trong vài ngày hoặc tuần đầu tiên, người dùng sẽ ghét phần mềm của bạn vì “phần mềm cũ không quá ngu ngốc”. Để tránh điều này, hãy tạo tài liệu và hướng dẫn tuyệt vời. Khi cài đặt hoặc mua, hãy gợi ý rõ ràng rằng nên đọc hướng dẫn sử dụng trước khi bắt đầu làm việc với chương trình chứ không phải sau khi cơ sở dữ liệu gặp sự cố, mất mật khẩu và tự kiểm soát.
Bạn cũng không nên đánh giá thấp người dùng: họ tinh ranh hơn, thông minh hơn và tò mò hơn bạn nghĩ. Nếu bạn cho rằng lỗi có định dạng thay đổi và ngoại lệ khi nhấn Enter lần thứ 138 trong khoảng thời gian một giây sẽ không bật lên thì bạn đã nhầm - chúng sẽ bật lên và ảnh hưởng đến hoạt động của ứng dụng của bạn theo cách kỳ lạ nhất. Áp dụng quy tắc của người nghiệp dư: anh ta là người đối phó với thử nghiệm tốt nhất. Nhưng vì lý do nào đó, người dùng không thích tìm ra lỗi trong quá trình sản xuất - chúng không có sự đoàn kết trong CNTT. Nói chung, bạn càng tự tin vào phần mềm của mình thì càng tốt. Rốt cuộc, tốt hơn là nên trì hoãn việc phát hành một số tính năng hơn là thêm chúng vào một ứng dụng đang hoạt động và đột nhiên biến nó thành thô.
Hãy ngừng tìm kiếm trên Google!
Đừng chỉ tìm đến Google nữa. Chúng tôi thậm chí sẽ không tranh luận - trong lĩnh vực phát triển, bạn có thể tìm thấy rất nhiều thứ bằng cách yêu cầu trực tiếp tới công cụ tìm kiếm. Bạn càng tìm kiếm thông tin sâu hơn, bạn sẽ nhận được càng nhiều dữ liệu “bên cạnh” và bạn sẽ học được nhiều hơn, bởi vì bạn sẽ học được điều gì đó mới không liên quan đến yêu cầu của bạn, nhưng có thể sẽ cần thiết trong tương lai. Tham khảo đầy đủ các tài liệu, sách, bài viết,… Ngôn ngữ và thư viện có thông số kỹ thuật, cộng đồng, cách thực hiện và do đó bạn có được cách đáng tin cậy nhất để phát triển kỹ năng lập trình viên - chỉ cần đọc tài liệu và không tìm kiếm các giải pháp và đoạn mã cục bộ của người khác. Điều gì sẽ xảy ra nếu giải pháp của bạn tối ưu hơn, nhanh hơn và mát hơn?
Tin tưởng, nhưng xác minh
Không sử dụng các thư viện và khung do nhà phát triển bên thứ ba tạo mà không kiểm tra mã và điều chỉnh mã cho phù hợp với mục đích của bạn. Bạn không có lý do gì để tin tưởng vô điều kiện tác giả mã này, người mà bạn hoàn toàn không biết. Đúng vậy, các phần tử độc hại có chủ ý khác nhau trong mã của bên thứ ba không quá phổ biến và bạn không nên hoang tưởng, nhưng việc sao chép một cách mù quáng các phần phần mềm làm sẵn vào dự án của bạn có thể dẫn đến những hậu quả khó lường. Do đó, hãy nhớ đọc và phân tích mã trước khi sử dụng và kiểm tra sau khi triển khai mã.
Hãy sao lưu!
Dừng việc không tạo bản sao lưu hoặc giữ chúng trên cùng máy chủ của bên thứ ba nơi dự án của bạn được lưu trữ. Bạn có nghĩ đây là lời khuyên vô lý và vô ích không? Nhưng hơn 700 người tham gia trò chuyện trên Telegram, những người gần đây đang rơi vào tình huống khó chịu với việc một trung tâm dữ liệu nổi tiếng đóng cửa, đã không nghĩ như vậy - có tất cả mọi thứ ở đó: từ các dự án thú cưng đến các trang web lớn của chính phủ. cơ quan có thẩm quyền và cơ sở dữ liệu thanh toán và 1C của công ty. Một phần quan trọng là không có bản sao lưu hoặc có bản sao lưu ở cùng một nơi. Vì vậy, hãy phân phối rủi ro và lưu trữ bản sao lưu ít nhất trên máy chủ lưu trữ chính, trên một số VDS đáng tin cậy và trên máy chủ cục bộ của bạn. Về lâu dài nó sẽ rẻ hơn nhiều.
Đừng tự mình làm tổn hại đến dự án
Đừng làm những gì bạn muốn trong một dự án công việc mà hãy làm những gì khách hàng cần. Đúng, thật thú vị và tuyệt vời khi tạo mạng lưới thần kinh của riêng bạn, đào tạo và triển khai nó trong phần mềm của bạn, nhưng nếu khách hàng của bạn cần một trình quản lý liên hệ đơn giản thì đây sẽ là một điều quá mức cần thiết. Xem cách dự án hoạt động, đọc tài liệu, đọc các đánh giá và yêu cầu từ khách hàng, đồng thời triển khai những gì sẽ tăng thêm giá trị kinh doanh cho dự án. Nếu bạn muốn tạo ra thứ gì đó khoa học hoặc cực kỳ phức tạp, hãy bắt đầu với dự án của riêng bạn.
Không phải một mật mã mà là một bó dây thần kinh
Đừng viết mã không thể đọc được và không có giấy tờ. Chúng ta đã quen với thủ thuật này: nhà phát triển viết mã theo ý mình, cố tình gây nhầm lẫn một chút để không đồng nghiệp nào hiểu được những gì anh ta viết - đây là một kiểu trả thù phòng ngừa trước khi điều gì đó xảy ra. Tuy nhiên, bạn đang gặp rủi ro không chỉ với công ty (công ty trả tiền cho công việc của bạn), mà còn cả chính bạn: rất có thể bản thân bạn sẽ không nhớ những gì mình muốn nói với sự bối rối vô ý này. Điều này cũng tương tự với mã không có giấy tờ: dựa vào logic đặt tên biến và hàm cũng như trí nhớ tốt, sau một vài năm, bạn có thể không nhớ tại sao mình chọn vòng lặp, phương thức, mẫu cụ thể đó, v.v. Ghi lại mã của bạn và cấu trúc tốt của nó là một dịch vụ tuyệt vời cho đồng nghiệp, chủ nhân của bạn và trên hết là cho chính bạn.
Giữ cho nó đơn giản ngu ngốc
Giữ mã, giải pháp và dự án của bạn đơn giản. Không cần phải rào chắn trong một cấu trúc phức tạp và tạo ra các thực thể không có ý nghĩa đặc biệt. Mã của bạn càng phức tạp thì bạn càng trở thành con tin của nó - bạn sẽ càng khó duy trì và phát triển nó. Tất nhiên, nguyên tắc KISS nổi tiếng (“Keep it simple, ngu ngốc”) không phải lúc nào cũng phù hợp, nhưng nó được tạo ra vì một lý do: sự đơn giản và tinh tế của mã là chìa khóa để ứng dụng và tái sử dụng thành công.
Tự bảo vệ mình
Đừng bỏ qua sự an toàn - vào năm 2020, đó thực sự là tội phạm. Ngay cả khi công ty, nhà phát triển của bạn và bạn không phải là mối quan tâm của những kẻ tấn công, bạn vẫn có thể bị ảnh hưởng bởi các vấn đề liên quan đến việc thất bại một số phân đoạn mạng, nhà cung cấp dịch vụ lưu trữ, tấn công vào trung tâm dữ liệu, đánh cắp mật khẩu email và hành vi không an toàn của nhân viên có thể đánh cắp dữ liệu của công ty, đánh cắp khách hàng hoặc mã chương trình của toàn bộ dự án. Nếu nó nằm trong khả năng và lĩnh vực chuyên môn của bạn, hãy cố gắng bảo vệ những dự án bạn đang thực hiện. Thôi, hãy tự mình quan sát việc bảo mật thông tin, nó chưa bao giờ làm phiền ai cả.
Đừng nhổ xuống giếng
Đừng gây rối với chủ nhân của bạn. Ngày nay, thông tin liên lạc đã đạt đến mức, chẳng hạn, tất cả nhân viên nhân sự trong thành phố đều biết nhau khi vắng mặt và có thể trao đổi bất kỳ thông tin nào trong các cuộc trò chuyện và nhóm kín (cả hai đều để giúp tìm việc làm và viết “Vasily Ivanov, kiến trúc sư hệ thống, giết hết mọi thứ trước khi rời khỏi tài khoản, xóa bản sao lưu và tắt mạng, khôi phục mất 3 ngày. Đừng thuê anh ta." Do đó, hành vi của bạn sẽ chỉ chống lại bạn - và đôi khi ngay cả việc chuyển đến thành phố hoặc thủ đô khác cũng không giúp ích được gì. Ngay cả khi bạn ra đi với mối hận thù, không có cách trả thù nào tốt hơn việc trở thành một nhân viên hữu ích và ngầu của đối thủ cạnh tranh :) Và quan trọng nhất là hoàn toàn không bị trừng phạt.
Bạn cũng không nên làm điều đó. Nhưng, như kinh nghiệm cho thấy, chúng tôi sẽ không dừng lại
Nói chung, các bạn ơi, hãy đọc lời khuyên nhưng hãy làm những gì bạn cho là tốt nhất - suy cho cùng, những khám phá thực sự được thực hiện khi chúng ta nghi ngờ những sự thật đã được khám phá. Chúc mừng năm mới, chúc các dự án của bạn thành công, chúc sự nghiệp của bạn thú vị, cầu mong đồng nghiệp và người quản lý của bạn phù hợp và cầu mong cuộc sống của bạn nói chung thành công. Nói chung là Tết và mã mới đây!
Với tình yêu,
Nhóm Studio phát triển của RegionSoft
Trong năm mới, chúng tôi sẽ tiếp tục làm việc cho bạn và phát triển hệ thống CRM dành cho máy tính để bàn mạnh mẽ và một hệ thống vé và bàn trợ giúp đơn giản và thuận tiện .
Nguồn: www.habr.com