Xin gửi lời chào tới tất cả các sinh viên và chuyên gia Java. Có lẽ câu chuyện của tôi sẽ là một ví dụ cho một số người về cách làm và cho những người khác - cách không làm. Đó là ngày 19 tháng 10 năm 2021 và hôm nay tôi đã hoàn thành thời gian thử việc (3 tháng) với tư cách là nhà phát triển cấp trung Java trong một công ty lớn. Tôi chưa có kinh nghiệm phát triển Java trước đây. Cho đến ngày 4 tháng 6 năm 2020, tôi chưa biết gì về Java. Khi được tuyển làm Javaist, tôi đã hứa nếu vượt qua thời gian thử việc sẽ viết tiểu sử thành công, bài viết này sẽ chia làm 2 phần logic: Bối cảnh nghề nghiệp (
chương 1-5, không liên quan đến Java), nhưng trong đó bạn có thể có được kiến thức về nghề nghiệp của mình). Trở thành một người theo chủ nghĩa Java (chương 6-9 - học Java, phỏng vấn, kiếm việc làm, trải nghiệm thực tế đầu tiên). <h3>Chương 1. Nhà kinh tế</h3>Để hiểu được mức độ kiến thức mà tôi đến với JavaRush, tôi cần ghi lại tiểu sử về bản thân mình. 2013, tháng 11, 8 giờ sáng. Tôi đang ngồi trong quán cà phê ở Taganka và lặp lại các hướng dẫn SQL. Trong một giờ nữa tôi sẽ có một cuộc phỏng vấn cho vị trí chuyên gia kinh tế hàng đầu ở bộ phận tài chính của ngân hàng. Đây là cuộc phỏng vấn duy nhất mà tôi được mời tham gia và tôi cần phải cống hiến 100%. Vì lợi ích của anh ấy, tôi đã bay từ St. Petersburg và ở cùng người thân trong bếp để không tiêu tốn số tiền tiết kiệm vốn đã ít ỏi của mình. 30 phút trôi qua, những chiếc bánh xèo với giăm bông và phô mai đã được ăn hết và chúng ta cần hướng tới ước mơ ấp ủ của mình. Nhưng mọi thứ đang rung chuyển. Nếu tôi trượt cuộc phỏng vấn thì sao? Được rồi, không phải vậy. Tôi đến ngân hàng, lấy thẻ và đợi người được phỏng vấn trong phòng họp. Thời gian trôi qua rất lâu. Một người đàn ông khoảng 35 tuổi và một người phụ nữ cùng tuổi bước vào. Họ giới thiệu bản thân và yêu cầu bạn kể về bản thân họ: “Yuri, rất hân hạnh.” Tôi 21 tuổi, tôi đang học bán thời gian tại một trường đại học ở St. Petersburg, tôi đã làm nhân viên giao dịch trong một ngân hàng được 3 tháng. Tôi nhận ra rằng đây không phải là điều tôi đã nghiên cứu, tôi bắt đầu xem xét thị trường việc làm và thấy rằng ở Moscow, các nhà kinh tế học yêu cầu SQL. Vì vậy, tôi đã nghiên cứu nó, tham gia các khóa học (Quản trị MS SQL - đó là những gì tôi đã có, đó là những gì tôi đã theo đuổi) và bạn đã gọi cho tôi. Họ nói về công ty, những gì họ làm (hầu hết các từ đều không thể hiểu được), sau đó yêu cầu bạn làm bài kiểm tra. Bài kiểm tra có 3 câu hỏi về SQL: 1. Cho một bảng, lấy ra tất cả các bản ghi có id = 10. 2. Cho hai bảng, nối chúng lại và hiển thị một cột từ mỗi bảng. 3. Nhóm các phòng ban lại và cho biết số lượng nhân viên của từng phòng ban. Thật xấu hổ khi tôi viết những yêu cầu này. Tiếp theo là cuộc thảo luận về những kỳ vọng của tôi đối với công việc. Và họ nói với tôi câu nói kỳ diệu: “Cảm ơn bạn vì cuộc phỏng vấn, chúng tôi sẽ gọi lại cho bạn”. Một tuần trôi qua và họ đề nghị tôi đến làm việc với họ. Euphoria, sốc, vui mừng! Và với số tiền nào: 70 nghìn rúp trong tay! Vâng, tôi sẽ giàu có! Tôi đến Moscow, định cư, thuê một căn phòng ở trung tâm. Những ngày đầu tiên thật hưng phấn. Sau 10 ngày, sự nhận thức bắt đầu: tôi đã đến đâu? Tôi chẳng hiểu gì cả! Tôi phải chuẩn bị các báo cáo quản lý cho toàn ngân hàng hàng tháng. Đương nhiên, đối với tôi, điều đó cũng giống như đối với bạn, bạn đọc thân mến. Tôi coi các thuật ngữ tín dụng liên ngân hàng, hoán đổi, phân bổ chi phí, chi phí, v.v. như những câu thần chú trong tiếng Latinh. Trong quá trình đó, tôi đã phải nắm vững khía cạnh kỹ thuật của vấn đề: MS Access (tất cả báo cáo được thực hiện thông qua VBA), MS SQL (dưới dạng bộ lưu trữ mới, thay vì Access), Oracle (mà ban đầu tôi gọi là Oracle, gây ra sự cuồng loạn giữa các lập trình viên). Và đột nhiên tôi bắt đầu hiểu rằng khía cạnh kỹ thuật đối với tôi thú vị hơn nhiều. Có những nỗ lực nhằm tạo các truy vấn phức tạp (kết quả là cơ sở dữ liệu bị treo trong các tập lệnh của tôi và các quản trị viên tức giận chạy khắp nơi để cố gắng tìm ra ai đã thực hiện việc đó). Nhưng công việc chính là tài chính, điều đó bắt đầu làm tôi khó chịu. Sau một tháng rưỡi, tôi viết đơn từ chức vì tôi không thể đưa ra bất kỳ kết quả nào (và thành thật mà nói, họ không thực sự mong đợi bất kỳ kết quả nào từ tôi). Người đứng đầu bộ phận tài chính xé nó ra và nói: "Đừng bận tâm đến chuyện tào lao." Một tháng sau, tôi lại viết bản tường trình, và người đứng đầu bộ phận, người bị sốc trước sự ngạo mạn như vậy (người sau này trở thành chủ tịch hội đồng quản trị ngân hàng), ký với vẻ hoang mang tột độ: anh chàng 21 tuổi, không có bằng cấp cao hơn. học vấn, họ được trả lương và được ủy thác, nhưng anh ta lại cư xử như vậy. Lý do sa thải còn có hai yếu tố nữa: ông chủ, người mà tôi không thể bình tĩnh phản ứng với sự kiêu ngạo của ông ấy, và chiếc ghế không thoải mái khiến lưng tôi bắt đầu đau. Điều này cực kỳ buồn cười, nhưng đây là động cơ. Khi tôi nghỉ việc, tôi nghĩ rằng bây giờ tôi sẽ cảm thấy thoải mái hơn. Nhưng nó không có ở đó. <h3>Chương 2. 70 cuộc phỏng vấn</h3>Rời khỏi ngân hàng, tôi hít một hơi thật sâu. “Tôi sẽ sắp xếp thế này, mọi người sẽ choáng váng.” Các cuộc phỏng vấn đã được lên lịch, mức lương dành cho họ cao hơn và có vẻ như sẽ không cần phải giải quyết vấn đề báo cáo nữa. Có 4 cuộc phỏng vấn và không ai thuê tôi. 5, 6 cuộc phỏng vấn - điều tương tự. Tôi sống với một cô gái trong một căn phòng thuê, cô ấy đã kiếm được việc làm và có thể trang trải cho khoản thu nhập thiếu hụt của tôi. Nhưng tôi vẫn không biết mình sẽ không có thu nhập trong bao lâu. Tôi đã đi phỏng vấn (vị trí tuyển dụng là nhà phân tích) và họ chủ yếu hỏi về SQL và VBA. Dành cho những ai chưa biết, VBA là ngôn ngữ lập trình trong Excel, Access và các sản phẩm MS Office khác. 10 cuộc phỏng vấn được tổ chức - không có gì. 20, 30 - không có gì. Mọi người đều cảm thấy xấu hổ vì thiếu kinh nghiệm và trình độ học vấn cao hơn (đối với tôi điều này dường như chỉ là chuyện nhỏ). 40 cuộc phỏng vấn và sự tuyệt vọng bắt đầu len lỏi vào. Trong khoảng thời gian phỏng vấn 55-60, tôi bắt đầu nghiên cứu 1C. Cô gái đã trở thành vợ yêu cầu được rời đến St. Petersburg, vì ít nhất cô ấy cũng có nhà riêng ở đó. Và tại cuộc phỏng vấn thứ 70, tôi được mời làm quản trị viên cơ sở dữ liệu 1C (với triển vọng trở thành nhà phát triển 1C) trong một công ty nhỏ ở khu công nghiệp St. Petersburg với mức lương 50.000 rúp. Bây giờ đó là sự phát triển nghề nghiệp! <h3>Chương 3. Sự trở lại của huyền thoại</h3>Nhìn ra cửa sổ chiếc xe buýt nhỏ (vận tải doanh nghiệp) tại khu công nghiệp St. Petersburg xám xịt, đi một giờ bốn mươi mốt chiều, tôi nhận ra rằng mình không thể sống như vậy. Sự quan tâm đến 1C biến mất ngay lần chạm đầu tiên vào hệ thống tự viết. Một kế hoạch là cần thiết. Và anh ấy đã trưởng thành: buổi tối anh ấy học SQL, đồng thời theo dõi trang web việc làm nổi tiếng. Nguyên nhân cuối cùng dẫn đến việc sa thải là tình huống: tổng giám đốc không muốn cho tôi đi nghỉ theo kế hoạch, mặc dù vé đã được mua sẵn. Sau kỳ nghỉ, tôi viết đơn và gửi lại sơ yếu lý lịch của mình cho các vị trí tuyển dụng ở Moscow. Một lần nữa tôi được mời phỏng vấn tại một ngân hàng lớn ở Moscow. Một lần nữa tôi lại đến bếp của người thân và đi phỏng vấn. Khi hr viết địa chỉ, tôi không thể tin vào mắt mình - đây là tòa nhà mà tôi mơ ước được làm việc (vào thời điểm nơi cư trú cuối cùng của tôi ở Moscow, nó mới đang được xây dựng). Vị trí này được gọi là chuyên gia hỗ trợ hệ thống thông tin trưởng. tôi đi đến văn phòng Tôi được chào đón bởi một người đàn ông khoảng 30 tuổi trong chiếc áo khoác và quần jean thời trang. Chúng tôi lên tầng 15, và khi nhìn thấy toàn cảnh thành phố, tôi choáng váng: tất cả các tòa nhà cao tầng kiểu Stalin đều có thể nhìn thấy được. Toàn bộ phong cách của tòa nhà rất hiện đại: trong văn phòng của ông chủ có tủ lạnh chứa rượu, bể cá thời trang, bức tranh vẽ một người phụ nữ khỏa thân theo phong cách đen trắng. Điều này gây ra hiệu ứng "wow". Cuộc trò chuyện với ông chủ không diễn ra như thường lệ: ông ấy nói trong khoảng 40 phút về những gì đang xảy ra ở ngân hàng. Tôi không hiểu gì cả, nhưng gật đầu. Khi tôi hỏi: khi nào bạn sẽ bắt đầu hỏi tôi? Anh ấy không hề chú ý. Một lần nữa, với câu hỏi của tôi “khi nào thì có cuộc phỏng vấn kỹ thuật?”, câu trả lời là “có, dù sao thì chúng tôi cũng sẽ thuê bạn, nếu bạn không thể xử lý được, chúng tôi sẽ sa thải bạn”. Nó được nói với một nụ cười, và tôi nhận ra rằng mọi thứ, giấc mơ đã trở thành hiện thực một lần nữa! <h3>Chương 4. Tìm lại chính mình trong CNTT </h3>Khi đến nơi mới, tôi đã hiểu tại sao họ thuê tôi ngay. Tôi sẽ mô tả chân dung điển hình của một nhân viên bộ phận: tuổi trung bình 55 tuổi, người Muscovite, tốt nghiệp Đại học Tổng hợp Moscow, làm việc tại viện nghiên cứu quốc phòng thời Xô Viết, chuyển sang lĩnh vực ngân hàng vào những năm 90, đã làm việc ở đây được 20 năm. năm, một nửa là nam, một nửa là nữ. Họ hoàn toàn bất hòa với nội thất xung quanh. Chúng tôi đã tham gia vào việc duy trì các chương trình báo cáo cho kế toán. Đương nhiên, tất cả đều nằm trong các tập lệnh VBA và SQL cổ được các nhà phát triển viết vào cuối những năm 90 và đầu những năm 2000. Đó là năm 2015 và tự động hóa thông qua MS Access. Đó là, nó trông cực kỳ nghèo nàn. Nhưng có một sắc thái - họ cung cấp những gì khách hàng (kế toán) muốn. Và chính xác về thời gian và hình thức được yêu cầu. Chỉ có họ mới biết nó hoạt động như thế nào và ngay cả Onotole cũng không thể tưởng tượng được mức độ phức tạp trong quá trình phát triển của họ. Và bất kỳ người quản lý CNTT nào, dù có mong muốn lớn nhất, cũng không thể sa thải họ - kế toán trưởng đã đến gặp hội đồng quản trị ngân hàng và bảo vệ bất kỳ nhân viên nào phục vụ lợi ích của bộ phận kế toán. Người quản lý muốn tôi đóng vai một con ngựa thành Troy: Tôi đã nghiên cứu tất cả sự phát triển của chúng và sau đó di chuyển dữ liệu sang hệ thống mới. Sau đó, những nhân viên cũ có thể bị sa thải và tôi có thể được chuyển sang hệ thống mới. Đầu tiên, tôi đi sâu vào quy trình của họ và xem mã VBA. Dần dần tôi học cách đọc mã VBA. Một năm sau tôi đã biết cách viết mã. Nhiệm vụ điển hình: cung cấp cơ sở dữ liệu, trích xuất dữ liệu từ đó và đưa vào Excel theo một định dạng nhất định. Bây giờ, như Zadornov đã nói, hãy hít một hơi thật sâu: tất cả báo cáo của bộ phận (và đó là 50 báo cáo hàng ngày, 20 báo cáo hàng tháng!) đều được chạy thủ công! Karl, bạn có hiểu rằng mọi người dùng tay thay đổi ngày thành +1 mỗi ngày trong 50 báo cáo không! Họ ngồi, đợi kết quả của một báo cáo trong 1-10 phút và khởi chạy một báo cáo khác! Hơn nữa, các báo cáo hàng ngày phải được tung ra vào một thời điểm nhất định, và Chúa cấm bạn đến muộn! Họ không chỉ lập báo cáo mà còn chạy thủ công các thủ tục trong cơ sở dữ liệu mà không cần sử dụng biến! Nghĩa là, thay vì sử dụng biến @startDate = '2015-01-01', họ sẽ thay đổi cùng một ngày theo cách thủ công ở 20 vị trí! Sau khi xem tất cả những điều này, tôi bắt đầu học Python, và cùng với VBA, SQL và Trình lập lịch tác vụ, tôi đã tự động hóa tất cả những việc này trong hai năm. Không chỉ tự động hóa mà còn tăng tốc nhiều báo cáo: nếu bạn từ bỏ MS Access + VBA để chuyển sang MS SQL + TSQL, bạn có thể đạt được mức tăng năng suất gấp nhiều lần. Hồ sơ của tôi đang tăng tốc độ tạo báo cáo trong
100một lần! Nhưng các đồng nghiệp của tôi vô cùng không hài lòng với sự tự động hóa như vậy nên tôi bị coi là kẻ thù của nhân dân (họ muốn ngồi yên cho đến khi nghỉ hưu). Thời gian trôi qua và quá trình di chuyển dữ liệu đã thành công. Người quản lý đánh giá cao tôi: nếu lúc mới bắt đầu sự nghiệp tôi đến làm việc lúc 8 giờ sáng, thì sau một thời gian tôi có thể đến bất cứ lúc nào cho đến 12 giờ, lương và chức vụ tăng liên tục, trả lương cho công việc vào cuối tuần nhiều hơn hơn gấp đôi số tiền, taxi đến nhà nếu bạn đi làm muộn, liên lạc di động, nói tóm lại - giới thượng lưu! <h3>Chương 5. Chiếc lồng vàng</h3>Đột nhiên, sau 3,5 năm, ban quản lý CNTT mới đến và nói rằng hệ thống mà tôi đã di chuyển dữ liệu sang không còn cần thiết nữa. Nhưng hệ thống cũ sẽ vẫn còn. Người quản lý của tôi đang thăng tiến trong sự nghiệp và mời tôi chuyển sang một bộ phận tiến bộ hơn. Trong cuộc gặp với trưởng bộ phận cấp tiến, tôi hiểu rằng tôi chưa biết đến hệ thống công nghệ của bộ phận này: Oracle, .net, C#, Linux, v.v. + Có ác cảm với sếp tiềm năng. Tôi nói với người quản lý của mình rằng tôi không quan tâm đến bộ phận cấp tiến, và anh ấy đã quên tôi một cách thuận tiện. Và sau đó câu hỏi trở thành: phải làm gì tiếp theo? Thu nhập đã khá rồi, Junior dev sẽ không thuê tôi với mức lương đó. Sau khi suy nghĩ về các kỹ năng của mình, tôi nhận ra rằng mình cần phải học máy. Mọi thứ đều thú vị cho đến lần đầu tiên gặp phải thống kê toán học, điều này chỉ gây ra sự ghê tởm ở viện. Thế là xong, sững sờ suốt sáu tháng! Thời gian trôi qua, và một ngày nọ, khi đang đi dạo, tôi nghĩ về một trang web hiển thị những nhà hàng ngon trên bản đồ Moscow. Bắt đầu học HTML, CSS, JS. Tôi mất 3 tháng học, tôi chưa có đủ kiến thức để tạo một trang web chính thức nhưng có thể thực hành tại nơi làm việc. Một ý tưởng đã ra đời: tạo một cổng thông tin dành cho kế toán viên để họ có thể tải xuống bất kỳ báo cáo nào cho mình bằng một nút bấm. Phải mất 2 tháng để tạo ra cổng và ứng dụng web SPA (Single page application) đã ra đời trong React js với phần phụ trợ Node.js. Các tập lệnh SQL được kéo lại (tôi không biết về các khung như Hibernate), khởi chạy Python và lưu trữ thông tin bổ sung trong MongoDb (ví dụ: về người dùng trang web). Bên ngoài, trang web trông rất đẹp (bootstrap 4, hoạt hình thời trang). Tôi vẫn tự hào về dự án này. Nhưng khi tôi đưa mã của mình cho các nhà phát triển web của ngân hàng xem, họ đã rất ngạc nhiên. KHÔNG PHẢI MỘT LỚP CỦA RIÊNG BẠN! Chỉ có tính năng, chỉ có Hardcore! Họ khen ngợi tôi nhưng nói rằng tôi vẫn cần phải học hỏi nhiều để trở thành một Middle full-stack dev. Tôi đã cố gắng xin việc làm nhà phân tích, nhưng không có lời đề nghị đặc biệt nào. Tôi nghĩ: Tôi không có ở đó, tôi sẽ đăng sơ yếu lý lịch của một nhà phát triển full-stack. Các cuộc gọi đến, nhưng trong các cuộc phỏng vấn, tôi bay như bay khắp Paris: chẳng hạn, tôi không biết HashMap, HashSet là gì và tại sao chúng lại cần thiết. Không có một chút ý tưởng nào về OOP, mô hình lập trình, thuật toán, thử nghiệm, Git. Tôi nhớ lại cảm giác xấu hổ đã bị quên lãng từ lâu vì không biết những điều cơ bản. Đột nhiên có một lời mời làm trưởng phòng phân tích khách hàng tại một công ty tài chính. Một tuần trước khi đất nước đóng cửa vì đại dịch. Tôi xin được việc ở một công ty tài chính, nhưng có một cảm giác kép: một mặt, lương cao thì ấm, mặt khác sẽ có sự phát triển tối thiểu về mặt kỹ thuật. Một tuần trôi qua kể từ khi thiết bị được lắp đặt và công việc từ xa được giới thiệu. Vì những ngày không làm việc không áp dụng cho lĩnh vực tài chính nên chúng tôi vẫn làm việc như bình thường. Ông chủ mới hóa ra là một người rất điên rồ: ông ta đề nghị cạo Facebook, tạo mạng lưới thần kinh của riêng mình để nghiên cứu khách hàng (không có nhân viên khoa học dữ liệu). Nhân viên mới được đề nghị học Python trong một tuần, v.v. Những ngày nghỉ không lương đã trở thành thông lệ. Thật là ngu ngốc khi nghỉ việc: bạn sẽ kiếm được việc làm ở đâu trong thời kỳ đại dịch? Nhưng sự kiên nhẫn đã cạn kiệt sau 2 tháng, khi có thông báo sẽ không có tiền thưởng hàng quý. Sắc thái là khi chúng tôi thống nhất về mức lương, lúc tuyển dụng, hr nói rằng lương được chia thành lương (60%) và thưởng quý (40%), trả luôn. Rõ ràng là chúng tôi đã có sự lựa chọn sai lầm và chúng tôi cần phải bắt đầu tìm kiếm một công việc mới. <h3>Chương 6. Bắt đầu làm chủ Java</h3>Một ngày đẹp trời trong tháng 5, tôi nhận được lời mời phỏng vấn cho vị trí tuyển dụng “Nhà phát triển”. Một công ty trong ngành bảo hiểm cần một người phát triển các sản phẩm bảo hiểm. Cần có kinh nghiệm lập trình nhưng vì đây là sự phát triển “độc nhất vô nhị” của hãng nên không cần ngôn ngữ cụ thể. Git, v.v. cũng cần thiết. Tôi đã lên lịch phỏng vấn sau hai ngày và tôi đã nghiên cứu những kiến thức cơ bản về Git trong thời gian rảnh rỗi. Trong cuộc phỏng vấn, tôi được hỏi về Python, JS, Git, SQL. Tôi đã trả lời mọi thứ ngoại trừ khái niệm “quá tải phương thức” và tôi được mời làm việc sau 2 tuần. Hóa ra công ty đã mua hệ thống này từ lâu. được viết bằng Java (trước và sau), nhờ đó bạn có thể tạo các quy trình kinh doanh mà không cần biết ngôn ngữ lập trình (chính xác hơn là sử dụng ngôn ngữ lập trình Jelly tích hợp). Nghe có vẻ hay nhưng thực tế mọi thứ đã bị bóp méo. Lạc đề trữ tình: bất kỳ công nghệ nào cũng có thời đại và quy mô riêng. Thực hiện tất cả các báo cáo trong năm 2000 chỉ bằng Excel thật tuyệt. Làm điều tương tự vào năm 2021 là không tốt lắm. Trang web của công ty bằng HTML thuần túy rất thú vị vào năm 1999, nhưng vào năm 2021 thì không. Vì vậy, công nghệ mà công ty sử dụng tại thời điểm thành lập (2005) rất tuyệt vời - Java chịu trách nhiệm về cả phần máy chủ và phần máy khách (cái gọi là các trang Java servlet). Hơn nữa, nếu bạn tạo một quy trình kinh doanh mới (có giao diện người dùng riêng), thì quy trình đó sẽ được lưu trữ bên trong cơ sở dữ liệu chứ không phải trong mã trong tệp. Để hiểu điều này bất tiện như thế nào, hãy tưởng tượng rằng bạn viết mã Java trong ý tưởng Intellij, lưu nó vào Cơ sở dữ liệu, sau đó. khi bạn muốn chạy mã, nhân chương trình sẽ đi tới cơ sở dữ liệu và đọc mã của bạn từ đó. Theo đó, bạn không thể gỡ lỗi hoàn toàn ứng dụng của mình. Gợi ý số 1: Khi bạn muốn gửi mã tới testbench, bạn cần tạo mặt khác, sẽ có sự phát triển tối thiểu về mặt kỹ thuật. Một tuần trôi qua kể từ khi thiết bị được lắp đặt và công việc từ xa được giới thiệu. Vì những ngày không làm việc không áp dụng cho lĩnh vực tài chính nên chúng tôi vẫn làm việc như bình thường. Ông chủ mới hóa ra là một người rất điên rồ: ông ta đề nghị cạo Facebook, tạo mạng lưới thần kinh của riêng mình để nghiên cứu khách hàng (không có nhân viên khoa học dữ liệu). Nhân viên mới được đề nghị học Python trong một tuần, v.v. Những ngày nghỉ không lương đã trở thành thông lệ. Thật là ngu ngốc khi nghỉ việc: bạn sẽ kiếm được việc làm ở đâu trong thời kỳ đại dịch? Nhưng sự kiên nhẫn đã cạn kiệt sau 2 tháng, khi có thông báo sẽ không có tiền thưởng hàng quý. Sắc thái là khi chúng tôi thống nhất về mức lương, lúc tuyển dụng, hr nói rằng lương được chia thành lương (60%) và thưởng quý (40%), trả luôn. Rõ ràng là chúng tôi đã có sự lựa chọn sai lầm và chúng tôi cần phải bắt đầu tìm kiếm một công việc mới. <h3>Chương 6. Bắt đầu làm chủ Java</h3>Một ngày đẹp trời trong tháng 5, tôi nhận được lời mời phỏng vấn cho vị trí tuyển dụng “Nhà phát triển”. Một công ty trong ngành bảo hiểm cần một người phát triển các sản phẩm bảo hiểm. Cần có kinh nghiệm lập trình nhưng vì đây là sự phát triển “độc nhất vô nhị” của hãng nên không cần ngôn ngữ cụ thể. Git, v.v. cũng cần thiết. Tôi đã lên lịch phỏng vấn sau hai ngày và tôi đã nghiên cứu những kiến thức cơ bản về Git trong thời gian rảnh rỗi. Trong cuộc phỏng vấn, tôi được hỏi về Python, JS, Git, SQL. Tôi đã trả lời mọi thứ ngoại trừ khái niệm “quá tải phương thức” và tôi được mời làm việc sau 2 tuần. Hóa ra công ty đã mua hệ thống này từ lâu. được viết bằng Java (trước và sau), nhờ đó bạn có thể tạo các quy trình kinh doanh mà không cần biết ngôn ngữ lập trình (chính xác hơn là sử dụng ngôn ngữ lập trình Jelly tích hợp). Nghe có vẻ hay nhưng thực tế mọi thứ đã bị bóp méo. Lạc đề trữ tình: bất kỳ công nghệ nào cũng có thời đại và quy mô riêng. Thực hiện tất cả các báo cáo trong năm 2000 chỉ bằng Excel thật tuyệt. Làm điều tương tự vào năm 2021 là không tốt lắm. Trang web của công ty bằng HTML thuần túy rất thú vị vào năm 1999, nhưng vào năm 2021 thì không. Vì vậy, công nghệ mà công ty sử dụng tại thời điểm thành lập (2005) rất tuyệt vời - Java chịu trách nhiệm về cả phần máy chủ và phần máy khách (cái gọi là các trang Java servlet). Hơn nữa, nếu bạn tạo một quy trình kinh doanh mới (có giao diện người dùng riêng), thì quy trình đó sẽ được lưu trữ bên trong cơ sở dữ liệu chứ không phải trong mã trong tệp. Để hiểu điều này bất tiện như thế nào, hãy tưởng tượng rằng bạn viết mã Java trong ý tưởng Intellij, lưu nó vào Cơ sở dữ liệu, sau đó. khi bạn muốn chạy mã, nhân chương trình sẽ đi tới cơ sở dữ liệu và đọc mã của bạn từ đó. Theo đó, bạn không thể gỡ lỗi hoàn toàn ứng dụng của mình. Gợi ý số 1: Khi bạn muốn gửi mã tới testbench, bạn cần tạo mặt khác, sẽ có sự phát triển tối thiểu về mặt kỹ thuật. Một tuần trôi qua kể từ khi thiết bị được lắp đặt và công việc từ xa được giới thiệu. Vì những ngày không làm việc không áp dụng cho lĩnh vực tài chính nên chúng tôi vẫn làm việc như bình thường. Ông chủ mới hóa ra là một người rất điên rồ: ông ta đề nghị cạo Facebook, tạo mạng lưới thần kinh của riêng mình để nghiên cứu khách hàng (không có nhân viên khoa học dữ liệu). Nhân viên mới được đề nghị học Python trong một tuần, v.v. Những ngày nghỉ không lương đã trở thành thông lệ. Thật là ngu ngốc khi nghỉ việc: bạn sẽ kiếm được việc làm ở đâu trong thời kỳ đại dịch? Nhưng sự kiên nhẫn đã cạn kiệt sau 2 tháng, khi có thông báo sẽ không có tiền thưởng hàng quý. Sắc thái là khi chúng tôi thống nhất về mức lương, lúc tuyển dụng, hr nói rằng lương được chia thành lương (60%) và thưởng quý (40%), trả luôn. Rõ ràng là chúng tôi đã có sự lựa chọn sai lầm và chúng tôi cần phải bắt đầu tìm kiếm một công việc mới. <h3>Chương 6. Bắt đầu làm chủ Java</h3>Một ngày đẹp trời trong tháng 5, tôi nhận được lời mời phỏng vấn cho vị trí tuyển dụng “Nhà phát triển”. Một công ty trong ngành bảo hiểm cần một người phát triển các sản phẩm bảo hiểm. Cần có kinh nghiệm lập trình nhưng vì đây là sự phát triển “độc nhất vô nhị” của hãng nên không cần ngôn ngữ cụ thể. Git, v.v. cũng cần thiết. Tôi đã lên lịch phỏng vấn sau hai ngày và tôi đã nghiên cứu những kiến thức cơ bản về Git trong thời gian rảnh rỗi. Trong cuộc phỏng vấn, tôi được hỏi về Python, JS, Git, SQL. Tôi đã trả lời mọi thứ ngoại trừ khái niệm “quá tải phương thức” và tôi được mời làm việc sau 2 tuần. Hóa ra công ty đã mua hệ thống này từ lâu. được viết bằng Java (trước và sau), nhờ đó bạn có thể tạo các quy trình kinh doanh mà không cần biết ngôn ngữ lập trình (chính xác hơn là sử dụng ngôn ngữ lập trình Jelly tích hợp). Nghe có vẻ hay nhưng thực tế mọi thứ đã bị bóp méo. Lạc đề trữ tình: bất kỳ công nghệ nào cũng có thời đại và quy mô riêng. Thực hiện tất cả các báo cáo trong năm 2000 chỉ bằng Excel thật tuyệt. Làm điều tương tự vào năm 2021 là không tốt lắm. Trang web của công ty bằng HTML thuần túy rất thú vị vào năm 1999, nhưng vào năm 2021 thì không. Vì vậy, công nghệ mà công ty sử dụng tại thời điểm thành lập (2005) rất tuyệt vời - Java chịu trách nhiệm về cả phần máy chủ và phần máy khách (cái gọi là các trang Java servlet). Hơn nữa, nếu bạn tạo một quy trình kinh doanh mới (có giao diện người dùng riêng), thì quy trình đó sẽ được lưu trữ bên trong cơ sở dữ liệu chứ không phải trong mã trong tệp. Để hiểu điều này bất tiện như thế nào, hãy tưởng tượng rằng bạn viết mã Java trong ý tưởng Intellij, lưu nó vào Cơ sở dữ liệu, sau đó. khi bạn muốn chạy mã, nhân chương trình sẽ đi tới cơ sở dữ liệu và đọc mã của bạn từ đó. Theo đó, bạn không thể gỡ lỗi hoàn toàn ứng dụng của mình. Gợi ý số 1: Khi bạn muốn gửi mã tới testbench, bạn cần tạo tạo mạng lưới thần kinh của riêng bạn để nghiên cứu khách hàng (không có nhân viên khoa học dữ liệu). Nhân viên mới được đề nghị học Python trong một tuần, v.v. Những ngày nghỉ không lương đã trở thành thông lệ. Thật là ngu ngốc khi nghỉ việc: bạn sẽ kiếm được việc làm ở đâu trong thời kỳ đại dịch? Nhưng sự kiên nhẫn đã cạn kiệt sau 2 tháng, khi có thông báo sẽ không có tiền thưởng hàng quý. Sắc thái là khi chúng tôi thống nhất về mức lương, lúc tuyển dụng, hr nói rằng lương được chia thành lương (60%) và thưởng quý (40%), trả luôn. Rõ ràng là chúng tôi đã có sự lựa chọn sai lầm và chúng tôi cần phải bắt đầu tìm kiếm một công việc mới. <h3>Chương 6. Bắt đầu làm chủ Java</h3>Một ngày đẹp trời trong tháng 5, tôi nhận được lời mời phỏng vấn cho vị trí tuyển dụng “Nhà phát triển”. Một công ty trong ngành bảo hiểm cần một người phát triển các sản phẩm bảo hiểm. Cần có kinh nghiệm lập trình nhưng vì đây là sự phát triển “độc nhất vô nhị” của hãng nên không cần ngôn ngữ cụ thể. Git, v.v. cũng cần thiết. Tôi đã lên lịch phỏng vấn sau hai ngày và tôi đã nghiên cứu những kiến thức cơ bản về Git trong thời gian rảnh rỗi. Trong cuộc phỏng vấn, tôi được hỏi về Python, JS, Git, SQL. Tôi đã trả lời mọi thứ ngoại trừ khái niệm “quá tải phương thức” và tôi được mời làm việc sau 2 tuần. Hóa ra công ty đã mua hệ thống này từ lâu. được viết bằng Java (trước và sau), nhờ đó bạn có thể tạo các quy trình kinh doanh mà không cần biết ngôn ngữ lập trình (chính xác hơn là sử dụng ngôn ngữ lập trình Jelly tích hợp). Nghe có vẻ hay nhưng thực tế mọi thứ đã bị bóp méo. Lạc đề trữ tình: bất kỳ công nghệ nào cũng có thời đại và quy mô riêng. Thực hiện tất cả các báo cáo trong năm 2000 chỉ bằng Excel thật tuyệt. Làm điều tương tự vào năm 2021 là không tốt lắm. Trang web của công ty bằng HTML thuần túy rất thú vị vào năm 1999, nhưng vào năm 2021 thì không. Vì vậy, công nghệ mà công ty sử dụng tại thời điểm thành lập (2005) rất tuyệt vời - Java chịu trách nhiệm về cả phần máy chủ và phần máy khách (cái gọi là các trang Java servlet). Hơn nữa, nếu bạn tạo một quy trình kinh doanh mới (có giao diện người dùng riêng), thì quy trình đó sẽ được lưu trữ bên trong cơ sở dữ liệu chứ không phải trong mã trong tệp. Để hiểu điều này bất tiện như thế nào, hãy tưởng tượng rằng bạn viết mã Java trong ý tưởng Intellij, lưu nó vào Cơ sở dữ liệu, sau đó. khi bạn muốn chạy mã, nhân chương trình sẽ đi tới cơ sở dữ liệu và đọc mã của bạn từ đó. Theo đó, bạn không thể gỡ lỗi hoàn toàn ứng dụng của mình. Gợi ý số 1: Khi bạn muốn gửi mã tới testbench, bạn cần tạo tạo mạng lưới thần kinh của riêng bạn để nghiên cứu khách hàng (không có nhân viên khoa học dữ liệu). Nhân viên mới được đề nghị học Python trong một tuần, v.v. Những ngày nghỉ không lương đã trở thành thông lệ. Thật là ngu ngốc khi nghỉ việc: bạn sẽ kiếm được việc làm ở đâu trong thời kỳ đại dịch? Nhưng sự kiên nhẫn đã cạn kiệt sau 2 tháng, khi có thông báo sẽ không có tiền thưởng hàng quý. Sắc thái là khi chúng tôi thống nhất về mức lương, lúc tuyển dụng, hr nói rằng lương được chia thành lương (60%) và thưởng quý (40%), trả luôn. Rõ ràng là chúng tôi đã có sự lựa chọn sai lầm và chúng tôi cần phải bắt đầu tìm kiếm một công việc mới. <h3>Chương 6. Bắt đầu làm chủ Java</h3>Một ngày đẹp trời trong tháng 5, tôi nhận được lời mời phỏng vấn cho vị trí tuyển dụng “Nhà phát triển”. Một công ty trong ngành bảo hiểm cần một người phát triển các sản phẩm bảo hiểm. Cần có kinh nghiệm lập trình nhưng vì đây là sự phát triển “độc nhất vô nhị” của hãng nên không cần ngôn ngữ cụ thể. Git, v.v. cũng cần thiết. Tôi đã lên lịch phỏng vấn sau hai ngày và tôi đã nghiên cứu những kiến thức cơ bản về Git trong thời gian rảnh rỗi. Trong cuộc phỏng vấn, tôi được hỏi về Python, JS, Git, SQL. Tôi đã trả lời mọi thứ ngoại trừ khái niệm “quá tải phương thức” và tôi được mời làm việc sau 2 tuần. Hóa ra công ty đã mua hệ thống này từ lâu. được viết bằng Java (trước và sau), nhờ đó bạn có thể tạo các quy trình kinh doanh mà không cần biết ngôn ngữ lập trình (chính xác hơn là sử dụng ngôn ngữ lập trình Jelly tích hợp). Nghe có vẻ hay nhưng thực tế mọi thứ đã bị bóp méo. Lạc đề trữ tình: bất kỳ công nghệ nào cũng có thời đại và quy mô riêng. Thực hiện tất cả các báo cáo trong năm 2000 chỉ bằng Excel thật tuyệt. Làm điều tương tự vào năm 2021 là không tốt lắm. Trang web của công ty bằng HTML thuần túy rất thú vị vào năm 1999, nhưng vào năm 2021 thì không. Vì vậy, công nghệ mà công ty sử dụng tại thời điểm thành lập (2005) rất tuyệt vời - Java chịu trách nhiệm về cả phần máy chủ và phần máy khách (cái gọi là các trang Java servlet). Hơn nữa, nếu bạn tạo một quy trình kinh doanh mới (có giao diện người dùng riêng), thì quy trình đó sẽ được lưu trữ bên trong cơ sở dữ liệu chứ không phải trong mã trong tệp. Để hiểu điều này bất tiện như thế nào, hãy tưởng tượng rằng bạn viết mã Java trong ý tưởng Intellij, lưu nó vào Cơ sở dữ liệu, sau đó. khi bạn muốn chạy mã, nhân chương trình sẽ đi tới cơ sở dữ liệu và đọc mã của bạn từ đó. Theo đó, bạn không thể gỡ lỗi hoàn toàn ứng dụng của mình. Gợi ý số 1: Khi bạn muốn gửi mã tới testbench, bạn cần tạo <h3>Chương 6. Bắt đầu làm chủ Java</h3>Một ngày đẹp trời trong tháng 5, tôi nhận được lời mời phỏng vấn cho vị trí tuyển dụng “Nhà phát triển”. Một công ty trong ngành bảo hiểm cần một người phát triển các sản phẩm bảo hiểm. Cần có kinh nghiệm lập trình nhưng vì đây là sự phát triển “độc nhất vô nhị” của hãng nên không cần ngôn ngữ cụ thể. Git, v.v. cũng cần thiết. Tôi đã lên lịch phỏng vấn sau hai ngày và tôi đã nghiên cứu những kiến thức cơ bản về Git trong thời gian rảnh rỗi. Trong cuộc phỏng vấn, tôi được hỏi về Python, JS, Git, SQL. Tôi đã trả lời mọi thứ ngoại trừ khái niệm “quá tải phương thức” và tôi được mời làm việc sau 2 tuần. Hóa ra công ty đã mua hệ thống này từ lâu. được viết bằng Java (trước và sau), nhờ đó bạn có thể tạo các quy trình kinh doanh mà không cần biết ngôn ngữ lập trình (chính xác hơn là sử dụng ngôn ngữ lập trình Jelly tích hợp). Nghe có vẻ hay nhưng thực tế mọi thứ đã bị bóp méo. Lạc đề trữ tình: bất kỳ công nghệ nào cũng có thời đại và quy mô riêng. Thực hiện tất cả các báo cáo trong năm 2000 chỉ bằng Excel thật tuyệt. Làm điều tương tự vào năm 2021 là không tốt lắm. Trang web của công ty bằng HTML thuần túy rất thú vị vào năm 1999, nhưng vào năm 2021 thì không. Vì vậy, công nghệ mà công ty sử dụng tại thời điểm thành lập (2005) rất tuyệt vời - Java chịu trách nhiệm về cả phần máy chủ và phần máy khách (cái gọi là các trang Java servlet). Hơn nữa, nếu bạn tạo một quy trình kinh doanh mới (có giao diện người dùng riêng), thì quy trình đó sẽ được lưu trữ bên trong cơ sở dữ liệu chứ không phải trong mã trong tệp. Để hiểu điều này bất tiện như thế nào, hãy tưởng tượng rằng bạn viết mã Java trong ý tưởng Intellij, lưu nó vào Cơ sở dữ liệu, sau đó. khi bạn muốn chạy mã, nhân chương trình sẽ đi tới cơ sở dữ liệu và đọc mã của bạn từ đó. Theo đó, bạn không thể gỡ lỗi hoàn toàn ứng dụng của mình. Gợi ý số 1: Khi bạn muốn gửi mã tới testbench, bạn cần tạo <h3>Chương 6. Bắt đầu làm chủ Java</h3>Một ngày đẹp trời trong tháng 5, tôi nhận được lời mời phỏng vấn cho vị trí tuyển dụng “Nhà phát triển”. Một công ty trong ngành bảo hiểm cần một người phát triển các sản phẩm bảo hiểm. Cần có kinh nghiệm lập trình nhưng vì đây là sự phát triển “độc nhất vô nhị” của hãng nên không cần ngôn ngữ cụ thể. Git, v.v. cũng cần thiết. Tôi đã lên lịch phỏng vấn sau hai ngày và tôi đã nghiên cứu những kiến thức cơ bản về Git trong thời gian rảnh rỗi. Trong cuộc phỏng vấn, tôi được hỏi về Python, JS, Git, SQL. Tôi đã trả lời mọi thứ ngoại trừ khái niệm “quá tải phương thức” và tôi được mời làm việc sau 2 tuần. Hóa ra công ty đã mua hệ thống này từ lâu. được viết bằng Java (trước và sau), nhờ đó bạn có thể tạo các quy trình kinh doanh mà không cần biết ngôn ngữ lập trình (chính xác hơn là sử dụng ngôn ngữ lập trình Jelly tích hợp). Nghe có vẻ hay nhưng thực tế mọi thứ đã bị bóp méo. Lạc đề trữ tình: bất kỳ công nghệ nào cũng có thời đại và quy mô riêng. Thực hiện tất cả các báo cáo trong năm 2000 chỉ bằng Excel thật tuyệt. Làm điều tương tự vào năm 2021 là không tốt lắm. Trang web của công ty bằng HTML thuần túy rất thú vị vào năm 1999, nhưng vào năm 2021 thì không. Vì vậy, công nghệ mà công ty sử dụng tại thời điểm thành lập (2005) rất tuyệt vời - Java chịu trách nhiệm về cả phần máy chủ và phần máy khách (cái gọi là các trang Java servlet). Hơn nữa, nếu bạn tạo một quy trình kinh doanh mới (có giao diện người dùng riêng), thì quy trình đó sẽ được lưu trữ bên trong cơ sở dữ liệu chứ không phải trong mã trong tệp. Để hiểu điều này bất tiện như thế nào, hãy tưởng tượng rằng bạn viết mã Java trong ý tưởng Intellij, lưu nó vào Cơ sở dữ liệu, sau đó. khi bạn muốn chạy mã, nhân chương trình sẽ đi tới cơ sở dữ liệu và đọc mã của bạn từ đó. Theo đó, bạn không thể gỡ lỗi hoàn toàn ứng dụng của mình. Gợi ý số 1: Khi bạn muốn gửi mã tới testbench, bạn cần tạo Trang web của công ty bằng HTML thuần túy rất thú vị vào năm 1999, nhưng vào năm 2021 thì không. Vì vậy, công nghệ mà công ty sử dụng tại thời điểm thành lập (2005) rất tuyệt vời - Java chịu trách nhiệm về cả phần máy chủ và phần máy khách (cái gọi là các trang Java servlet). Hơn nữa, nếu bạn tạo một quy trình kinh doanh mới (có giao diện người dùng riêng), thì quy trình đó sẽ được lưu trữ bên trong cơ sở dữ liệu chứ không phải trong mã trong tệp. Để hiểu điều này bất tiện như thế nào, hãy tưởng tượng rằng bạn viết mã Java trong ý tưởng Intellij, lưu nó vào Cơ sở dữ liệu, sau đó. khi bạn muốn chạy mã, nhân chương trình sẽ đi tới cơ sở dữ liệu và đọc mã của bạn từ đó. Theo đó, bạn không thể gỡ lỗi hoàn toàn ứng dụng của mình. Gợi ý số 1: Khi bạn muốn gửi mã tới testbench, bạn cần tạo Trang web của công ty bằng HTML thuần túy rất thú vị vào năm 1999, nhưng vào năm 2021 thì không. Vì vậy, công nghệ mà công ty sử dụng tại thời điểm thành lập (2005) rất tuyệt vời - Java chịu trách nhiệm về cả phần máy chủ và phần máy khách (cái gọi là các trang Java servlet). Hơn nữa, nếu bạn tạo một quy trình kinh doanh mới (có giao diện người dùng riêng), thì quy trình đó sẽ được lưu trữ bên trong cơ sở dữ liệu chứ không phải trong mã trong tệp. Để hiểu điều này bất tiện như thế nào, hãy tưởng tượng rằng bạn viết mã Java trong ý tưởng Intellij, lưu nó vào Cơ sở dữ liệu, sau đó. khi bạn muốn chạy mã, nhân chương trình sẽ đi tới cơ sở dữ liệu và đọc mã của bạn từ đó. Theo đó, bạn không thể gỡ lỗi hoàn toàn ứng dụng của mình. Gợi ý số 1: Khi bạn muốn gửi mã tới testbench, bạn cần tạo
SQL скрипт, sẽ chứa mã của bạn. Khó chịu nhưng có thể chịu đựng được? Zest #2: Cơ sở dữ liệu bao gồm hơn 200 bảng có kết nối với nhau. Điều này có nghĩa là bạn cần biết bảng nào cần đưa mã vào và thực thể nào cần được tạo trong các bảng khác. Đầu ra là một tập lệnh SQL có độ dài ~ 1000 dòng. Điều này thực sự kinh tởm. Hãy coi chừng di sản. Nói tóm lại, nhận ra rằng tất cả đều bằng Java, tôi đã truy cập JavaRush (cuối cùng chúng tôi đã tìm được chủ đề của trang web!). Tháng 6-tháng 7 năm 2020. 10 cấp độ đầu tiên đã bị đóng nhanh chóng (có thể một tháng), vì về cơ bản không có gì mới. Sau đó tốc độ chậm lại. Tháng 7-tháng 10 năm 2020. Cấp 10-20 đóng cửa. Tháng 10 đến tháng 3 năm 2021. Cấp 20-30 đóng cửa. Bây giờ cuộc vui bắt đầu: vào tháng 3 năm 2021, tôi bắt đầu xem xét các vị trí tuyển dụng ở Java và nhận ra rằng có rất nhiều từ lạ ở đó. Một số loại Spring, SpringBoot, Hibernate, JUnit. Mua các khóa học video trên một trang web nổi tiếng, tôi mới chạm vào Spring và nghĩ rằng giờ mình đã biết và có thể làm được mọi thứ. Sau đó, tôi tình cờ biết đến khóa học TopJava của Grigory Kislin. Trên trang web của anh ấy, bạn có thể thử hoàn thành một bài kiểm tra và nếu thành công, bạn có thể tham gia khóa học. Trong khóa học này, bạn tạo một ứng dụng web hoàn chỉnh và thậm chí xuất bản nó trên Internet. Với số tiền này, họ sẽ đưa ra đánh giá cho bạn (đánh giá mã của một lập trình viên có kinh nghiệm hơn), đưa ra phản hồi và cho bạn lời khuyên trong trường hợp có vấn đề. Tôi làm bài tập về nhà số 3 và bỏ cuộc. Lý do rất đơn giản: họ đòi hỏi bạn rất nhiều nhưng lại không cho bạn kiến thức gì cả. Các yêu cầu về bài tập về nhà rất khó hiểu. Thông tin được trình bày cực kỳ không nhất quán. Theo ý kiến chủ quan của tôi, khóa học này cần thiết cho những nhà phát triển khá có kinh nghiệm đến từ các ngôn ngữ tương tự khác. Bởi vì trong khóa học của anh ấy thực tế không có lời giải thích nào về các công nghệ mà anh ấy yêu cầu sử dụng. Bạn cũng cần biết rõ về Git (mọi thứ đều được gửi đến kho lưu trữ cá nhân của bạn). Vào cuối tháng 4 năm 2021, tôi sẽ đăng một bản lý lịch cho một nhà phát triển Java (với mức lương mong muốn ở mức trung cấp trở lên), trong đó tôi chỉ ra rằng ở công việc cuối cùng của mình, tôi đã lập trình bằng Java (tôi đã nói dối). Cùng ngày, ngân hàng nhận được đơn ứng tuyển vào vị trí nhà phát triển Java. <h3>Chương 7. Phỏng vấn Java và trau dồi kỹ năng</h3>Vậy kế hoạch là gì? Tôi cần phải có một mức lương tốt, vì tôi đã quen với việc sống bằng thu nhập đáng kể + các khoản vay. Vì vậy, những vị trí cấp dưới không phù hợp với tôi. Bạn cần có được vị trí ở giữa. Nhưng ai sẽ thuê tôi mà không có kinh nghiệm? Quyết định đến một cách tự nhiên: hồ sơ việc làm của tôi cho biết tôi đã làm nhà phát triển trong một năm và thêm 4 năm nữa với tư cách là chuyên gia trong bộ phận CNTT ở vị trí trước đây. Vì vậy, tôi sẽ nói rằng tôi đã phát triển Java được một năm. Và nếu họ hỏi về các sản phẩm mới, tôi sẽ nói rằng Java (7) cũ đã ở đó và không hỗ trợ bất cứ thứ gì. Trước cuộc phỏng vấn (từ xa) đầu tiên, tôi rất lo lắng. Tôi không có kinh nghiệm, kiến thức rất ít và lại đòi rất nhiều tiền. Tôi nghĩ: không quan tâm, trải nghiệm tiêu cực cũng là trải nghiệm. Tôi liên hệ qua Skype và sẽ được hai trưởng bộ phận phỏng vấn. Điều đó càng khiến tôi sợ hãi hơn. Các câu hỏi bắt đầu: OOP, thiết bị HashMap, luồng, cấu trúc dữ liệu, Spring, Hibernate, AOP là gì. Và nếu trước Sping ít nhiều có thể chấp nhận được thì ở Spring nó hoàn toàn sụp đổ. Mọi người hỏi tôi: bạn đã phát triển như thế nào trong Spring nếu bạn không thực sự biết về nó? Tôi: Tôi đã sao chép, dán nó, nó hoạt động và cảm ơn vì điều đó. Câu trả lời này làm họ thích thú. Sau đó, họ hỏi về SQL, trong đó tôi giống như vịt gặp nước. Tiếp theo là Git và một câu hỏi về rebase, Cherry-pick (mà tôi cũng không biết) và kết thúc về JS, vì nó đã được liệt kê trong sơ yếu lý lịch của tôi. Ở đó cũng thất bại hoàn toàn vì họ hỏi về OOP JS. Dựa trên kết quả của cuộc phỏng vấn, rõ ràng là kiến thức của tôi không tốt và do đó tôi sẽ không đủ điều kiện cho vị trí tuyển dụng này. Vào buổi tối, HR viết rằng ứng cử viên của tôi đã được chấp thuận và họ sẵn sàng gọi cho tôi. Tôi thực sự đã bị nghẹn khi ăn một chiếc burger ở McDonald's. Tôi rất vui nhưng sau 3 ngày HR báo rằng họ đã chọn được ứng viên khác. Lần đầu tiên trong trải nghiệm của tôi, một lời đề nghị đã bị rút lại. Sau cuộc phỏng vấn đầu tiên bằng Java, tôi đã đẩy mạnh trò chơi của mình: Tôi tham gia một khóa học (và hoàn thành nó hoàn toàn!) về Git từ Colt Steele trên một trang web nổi tiếng về bán các khóa học video. Điều này đã thay đổi nhận thức của tôi về Git. Tiếp theo, tôi tham gia một khóa học (tuyệt vời) từ Zaur Tregulov về Spring+Hibernate. Sơ đồ đào tạo: Mình xem như trong video, mình làm tương tự trên máy tính, nhưng mình đặt tên các biến và lớp khác nhau để không sao chép một cách ngu ngốc mã của người khác. Tôi tải tất cả công việc của mình lên Github (qua đó thực hành Git). Lúc đó là giữa tháng Năm và các cuộc gọi từ giờ bắt đầu. Chúng tôi bắt đầu lên lịch phỏng vấn từng người một. Nhiều lời mời đã bị hủy vì những lý do sau: HR không đọc mô tả sơ yếu lý lịch của tôi và mời tôi vào vị trí cấp cao. Cũng cần đề cập đến một đẳng cấp nhân sự riêng: những người nhầm lẫn Java với JavaScript. Đó là lý do tại sao tôi viết nhà phát triển Middle Java trong tiêu đề sơ yếu lý lịch của mình. <h3>Chương 8. Danh sách các câu hỏi điển hình và cách thức phỏng vấn</h3>Tôi bắt đầu đi phỏng vấn và dần dần hình thành một nhóm câu hỏi cơ bản ở giữa. Yêu cầu: 0. OOP - định nghĩa, nói về từng nguyên lý của OOP (+đưa ví dụ thực tế). 1. Bằng và mã băm - hợp đồng (mối quan hệ) giữa chúng là gì? 2. HashMap - cách hiểu đối tượng sẽ đi vào nhóm nào, xung đột là gì, dữ liệu được lưu trữ bên trong HashMap theo cấu trúc dữ liệu nào, kích thước tiêu chuẩn, số lượng nhóm tăng lên như thế nào. 3. Luồng - những loại hoạt động nào, sự khác biệt giữa chúng là gì, cho ví dụ về từng loại hoạt động. 4. Nhóm chuỗi, Nhóm số nguyên - nó là gì? 5. Heap, stack - nó là gì, có gì khác nhau? 6. Sự khác biệt giữa Runnable, Thread, Future. 7. Tính dễ bay hơi, tính nguyên tử. 8. Solid, Kiss, Dry - định nghĩa, ví dụ từ thực tế cuộc sống. 9. Công cụ sửa đổi quyền truy cập trong Java. 10. Sự khác biệt giữa lớp trừu tượng và giao diện là gì. Giao diện có thể riêng tư? 11. Giao diện chức năng. 12. Liệt kê tất cả các phương thức của Object và cho biết lý do tại sao chúng cần thiết. Đặc điểm của phương pháp nhân bản. 13. Serialization và deserialization là gì. 14. Thử bắt bằng tài nguyên - mô tả nó là gì, cho nó biết bằng giao diện Có thể đóng. 15. Sự khác biệt giữa Final, Final, Finalize? 16. Quá tải, Ghi đè phương thức là sự khác biệt. 17. Tại sao String được đặt thành bất biến, hãy cho chúng tôi biết về StringBuilder và StringBuffer. 18. Độ phức tạp thời gian O(1), độ phức tạp bộ nhớ là gì. 19. Cấu trúc dữ liệu: nói về map, set, queue, deque, list và cách triển khai chúng trong Java (treeMap, hashSet, hashMap, arrayList, linkedList, PriorityQueue, BlockQueue), mô tả độ phức tạp (tệ nhất, trung bình, tốt nhất) của việc chèn, tìm kiếm, loại bỏ một phần tử trong mỗi cấu trúc. 20. Các kiểu dữ liệu nguyên thủy trong Java. Tại sao mỗi người trong số họ lại cần thiết? 21. Các loại lỗi. Các ngoại lệ được kiểm tra và không được kiểm tra. 22. JVM, JRE, JDK là gì? 23. Bạn đã làm việc với những nhà sưu tập nào? Maven - Xây dựng vòng đời. 24. Spring - Định nghĩa Ioc, Di, Vòng đời Bean, Ngữ cảnh, Chú thích @Bean, @Configuration, @Autowired, @Advice, @Aspect, @Service, @Repository. 25. Generics - định nghĩa giới hạn dưới và giới hạn trên là gì? 26. Các mẫu lập trình - ít nhất là Singleton (sẵn sàng cho biết lý do tại sao điều này đôi khi là một mẫu phản đối) + Builder, Adaptor, Factory, Decorator, Proxt. Mong muốn: 26. Thử nghiệm - các loại thử nghiệm mà thư viện (JUnit) đã làm việc với. Mock, Stab, Spy là gì? 27. Spring boot - tại sao cần thiết, sẵn sàng tạo ứng dụng SpringBoot trực tuyến. 28. Hibernate - tại sao cần thiết, Thực thể, cột tham gia, tải lười biếng và háo hức, cấp độ bộ nhớ đệm (cứng). 29. Nghỉ xuân - tại sao cần, cách tạo @post, @get endpoint. Làm cách nào để đọc thông số/nội dung yêu cầu? Làm cách nào để gửi ở định dạng json? 30. Cấu trúc dữ liệu - cây, kiểu của chúng. 31. Thuật toán - các kiểu sắp xếp. Ngoài Java, họ có thể hỏi: 1. (Bắt buộc!) Git - tại sao cần, các thao tác hợp nhất, rebase, Cherry-pick, đẩy, kéo, cam kết, ghi nhật ký, kiểm tra, phân nhánh, đặt lại, hoàn nguyên, làm mới. 2.SQL - khả năng viết truy vấn: nối hai bảng thành một (nối trong, nối trái). 3. Cơ sở dữ liệu - 3 biểu mẫu, chỉ mục thông thường (tại sao cần, loại), khóa chính, khóa ngoại Một cuộc phỏng vấn từ xa thông thường diễn ra như thế nào: hr gửi một liên kết để thu phóng (Skype, Google Meet). Đến một thời điểm nhất định bạn kết nối và có từ 1 đến 3 người ở đó (chuyên gia kỹ thuật, sếp, nhân sự). Trong trường hợp đặc biệt cứng đầu, lên tới 8 người. Đầu tiên bạn kể về bản thân, sau đó là phần kỹ thuật, sau đó là câu chuyện về vị trí tuyển dụng và lời tạm biệt (họ nói khi nào họ sẽ liên lạc với bạn hoặc các bước tiếp theo sẽ như thế nào). Trong lúc tạm biệt, bạn có thể yêu cầu phản hồi về kiến thức. Tôi hỏi: “Trong khi tôi trả lời, bạn có thể cho tôi biết tai bạn bị đau ở đâu không?” Nhiều người đáp lại, nhưng hãy chuẩn bị tinh thần để bị từ chối. Trong cuộc phỏng vấn, họ đánh giá: 1. Khả năng bày tỏ suy nghĩ và kiến thức về tiếng Nga của bạn (Tôi biết một trường hợp ứng viên bị từ chối do hiểu biết kém về tiếng Nga). 2. Kinh nghiệm trước đây (họ có thể hỏi tỉ mỉ bạn đã làm gì ở công việc gần đây nhất). 3. Phản ứng thích đáng khi áp lực đè lên bạn (có một cuộc phỏng vấn khi mọi người bắt đầu nói chuyện một cách thiếu tôn trọng: phớt lờ câu trả lời của tôi, cố gắng thuyết phục họ, v.v. Tôi kết thúc cuộc phỏng vấn 15 phút sau khi bắt đầu và họ: đó là một cuộc phỏng vấn căng thẳng!) 4. Trình độ hiểu biết của bạn. Tôi sẽ đi vào chi tiết hơn ở đây. Biết định nghĩa của một chủ đề chỉ bằng 10% những gì bạn mong đợi. Cần phải hiểu cách thức hoạt động của nó (ít nhất là ở cấp cao nhất). Sẵn sàng giải thích tại thời điểm phát triển nào bạn sẽ chọn giải pháp này hoặc giải pháp kia. Điều này quan trọng hơn nhiều so với tính chính xác trong định nghĩa của bạn. Tôi sẽ phân tích luận điểm này bằng hai ví dụ. Ví dụ đầu tiên: trong một cuộc phỏng vấn, tôi được hỏi về HashMap và tôi đưa ra định nghĩa: “đây là cấu trúc dữ liệu lưu trữ các gói khóa và giá trị”. Sau đó người phỏng vấn hỏi: sự khác biệt so với TreeMap là gì? Trả lời: Sự khác biệt là HashMap băm khóa và do băm nên truy cập nhanh. Người phỏng vấn liền yêu cầu cho chúng tôi biết cấu trúc bên trong của HashMap, đồng thời hỏi về hashCode và Equals. Và nó sẽ đi sâu hơn cho đến khi bạn hài lòng với câu trả lời hoặc bạn dừng lại. Tôi học cách trả lời chính xác về HashMap chỉ sau 2 tháng phỏng vấn và một khóa học về cấu trúc dữ liệu trên hexlet. Ví dụ thứ hai: khái niệm RẮN. Họ yêu cầu tôi đưa ra một định nghĩa mà tôi đã thuộc lòng. Nhưng ngay khi đưa ra những ví dụ thực tế, vấn đề bắt đầu xảy ra.
Внимание!Nếu bạn không biết thì đừng bịa ra mà hãy nói thế này: Tôi không biết chủ đề này, nhưng tôi có thể cho rằng nó hoạt động như thế này. Nhiều chuyên gia kỹ thuật tức giận khi một người nói tà giáo như thể anh ta hiểu chủ đề. 5. Mức độ nhiệt tình của bạn trong quá trình thảo luận công việc. Bạn phải quan tâm và đặt câu hỏi về vị trí tuyển dụng (không chỉ là những câu hỏi bịa đặt). 6. Đôi khi sự hài hước (chỉ về chủ đề) và những sở thích chung giúp bạn giao tiếp. Hãy thoải mái nói về sở thích của bạn; có lẽ người được phỏng vấn cũng yêu thích Dota/bóng đá/fantasy. Và đây là một điểm cộng cho bạn khi là ứng viên. Tôi biết những trường hợp cộng đồng lợi ích nhắm mắt làm ngơ trước việc người phỏng vấn được đào tạo kỹ thuật kém (Bạn là người bình thường, chúng tôi sẽ đào tạo bạn). <h3>Chương 9. Có việc làm, lửa rửa tội</h3>Các cuộc phỏng vấn diễn ra từ cuối tháng 4 đến giữa tháng 7. Những cuộc phỏng vấn đầu tiên thật đáng xấu hổ, nhưng dần dần tình hình được cải thiện đến mức có thể chấp nhận được. Nghiên cứu những câu hỏi thường gặp và phản hồi khiến bản thân cảm thấy. 25 cuộc phỏng vấn đầu tiên đã không thành công. Sau đó, những giây phút tuyệt vọng bắt đầu. Cảm giác: điều gì sẽ xảy ra nếu họ không thuê tôi với mức lương đó? Đột nhiên mọi việc bắt đầu xảy ra: trong vòng một tuần, ba công ty đã gửi đề xuất. Tôi đã chọn một công ty có thông tin cụ thể mà tôi biết, ngoài ra còn có mức lương tốt và cơ hội làm việc từ xa. Trong cuộc phỏng vấn, tôi đã được hỏi khoảng 30 câu hỏi về Java core và Spring, 97% trong số đó tôi đã trả lời đúng. Sau đó tôi đã liên lạc với cấp trên và sau 1,5 tuần tôi đã nhận được việc làm với họ. Trước hết, khi bắt đầu bất kỳ công việc nào, bạn bắt đầu có quyền truy cập vào tất cả các hệ thống cần thiết và cài đặt các công cụ bạn cần. Phải mất một tuần rưỡi, tôi được giao nhiệm vụ đầu tiên: thay đổi văn bản tĩnh trong lớp học. Khi mở dự án, tôi cảm thấy buồn nôn: có rất nhiều mô-đun trong một dự án, nhiều lớp học, bài kiểm tra, v.v. Tại thời điểm này, tôi đã bị lạc lối, nhưng một nhà phát triển thứ hai đã giúp tôi và giúp tôi bắt kịp tốc độ. Lỗi đã được sửa trong 10 phút, được xuất bản trong Git, yêu cầu kéo đã được thực hiện (yêu cầu hợp nhất hai nhánh nơi các nhà phát triển khác kiểm tra mã của bạn), sau đó hợp nhất vào nhánh chính. Hóa ra mọi thứ không quá khó khăn. Cho đến nhiệm vụ chính thức đầu tiên... Tại thời điểm lập kế hoạch cho các nhiệm vụ trong hai tuần tới, họ nói với tôi: bạn sẽ thực hiện tích hợp với một hệ thống khác nằm trên OpenShift. Đây là lúc mọi thứ trở nên thực sự đáng sợ: OpenShift là một tập hợp toàn bộ các công nghệ: Docker, Kubernetes, Linux, v.v. Mồ hôi lạnh chảy dọc lưng tôi: à, tôi làm Jawist. Ngay sau cuộc họp, tôi gọi cho nhà phát triển, người này đã trấn an tôi: các bộ điều hợp cho hệ thống này đã được viết và chỉ cần nhập một số lớp nhất định vào dự án của tôi là đủ, sau đó tôi có thể sử dụng tích hợp một cách an toàn. Mọi chuyện lại vui vẻ cho đến khi nhà phát triển đưa ra một cách tích hợp điển hình: Tôi thấy hơn 20 lớp được tạo ra để tích hợp tương tự. Hơn nữa, các chú thích chưa từng thấy trước đây @Value, @Builder, @NoArgsConstructor, @Getter, đã được chú ý @ Sl4f - hóa ra là dự án Lombook (đọc trên Internet). Khi nhà phát triển giải thích cho tôi cách thực hiện, tôi đã cố gắng viết ra các kết nối của tất cả các lớp và không có gì đọng lại trong đầu tôi. Khoảnh khắc đáng xấu hổ nhất là thiếu kiến thức về Intellij Idea: cách tìm kiếm một dự án trên toàn cầu, tái cấu trúc mã, v.v. Khi nhận nhiệm vụ, tôi đã hiểu tại sao cần phải có OOP: với một lượng code lớn như vậy thì cần phải chia thành các lớp; các phương thức không được sử dụng bên ngoài lớp phải được khai báo là riêng tư để không vô tình chạy chúng trong lớp khác, v.v. Sau khi viết phần tích hợp của mình bằng cách tương tự với một phần tích hợp khác, tôi đã biết về sự tồn tại của CheckStyle - một plugin đặc biệt kiểm tra kiểu mã của bạn và bạn sẽ không thể biên dịch dự án của mình cho đến khi bạn sửa lỗi (ví dụ: khoảng trắng thừa, tên biến có chữ in hoa, tên biến quá ngắn). Sau khi đánh bại CheckStyle, tôi đã gửi mã của mình để các nhà phát triển cấp cao xem xét và sửa lỗi trong vòng một tuần. Nói chung, tôi rất may mắn khi trong nhóm của mình có mối quan hệ tốt với nhà phát triển thứ hai, người đã giải thích rất nhiều điều. Một tháng sau khi thiết bị, tích hợp đầu tiên của tôi đã được triển khai trên kệ Tích hợp-Chức năng (hoạt động của tất cả các ứng dụng cùng nhau đã được kiểm tra) và mọi thứ đều hoạt động ở đó! Chiến thắng! Nhiệm vụ tiếp theo là tạo một lớp cho phép ẩn dữ liệu bằng khóa trong json. Ví dụ: có json {text:"JavaRush"} -> đang xử lý -> {text:"****Rush"}. Có hai điều phức tạp ở đây: có thể có {text:{mytext:"JavaRush"}} lồng nhau và điều khó chịu hơn là việc lồng nhau bên trong mảng: {text: [ {mytext: "JavaRush"}, {mytext: "JavaRush "} ] } (tất nhiên là bạn cần ẩn toàn bộ text.mytext). Giải quyết vấn đề này hóa ra khá khó khăn, nhưng tôi đã làm được! Ở đây, nhà phát triển thứ hai nói: hãy bao quát quá trình phát triển này bằng các thử nghiệm. Trong mắt có sự hoang mang. Đây là cách tôi làm quen với thư viện JUnit trong chiến đấu. Bản chất của kiểm thử đơn vị: bạn có dữ liệu đầu vào, chuyển nó vào một phương thức và so sánh dữ liệu nhận được với kết quả chính xác (tạo một biến có kết quả chính xác). Tôi đã viết 11 trường hợp cho thư viện của mình, trong đó tôi đã kiểm tra rằng ứng dụng không gặp sự cố với NullPointException và nó ẩn dữ liệu một cách chính xác với bất kỳ kiểu lồng nào. Sau khi hoàn thành nhiệm vụ này, tôi đã nhận được một tích hợp mới, điểm đặc biệt của nó là: Tôi phải xuất Spring Bean từ thư viện bên ngoài. Tại thời điểm này, tôi đã trở thành khách hàng thường xuyên của trang web Stack OverFlow. Có lần ngay cả một nhà phát triển chính thức của Spring cũng phản hồi. Sau khi triển khai tích hợp này, thời gian dùng thử của tôi đã kết thúc. Sếp chúc mừng tôi đã vượt qua thời gian thử việc và tôi bắt đầu viết bài này. Tổng cộng mất 8 giờ để viết bài này) Cảm ơn bạn đã quan tâm, tôi hy vọng bài viết này hữu ích. Tôi đã cố gắng viết ra mối liên hệ của tất cả các lớp, nhưng chẳng có gì đọng lại trong đầu tôi cả. Khoảnh khắc đáng xấu hổ nhất là thiếu kiến thức về Intellij Idea: cách tìm kiếm một dự án trên toàn cầu, tái cấu trúc mã, v.v. Khi nhận nhiệm vụ, tôi đã hiểu tại sao cần phải có OOP: với một lượng code lớn như vậy thì cần phải chia thành các lớp; các phương thức không được sử dụng bên ngoài lớp phải được khai báo là riêng tư để không vô tình chạy chúng trong lớp khác, v.v. Sau khi viết phần tích hợp của mình bằng cách tương tự với một phần tích hợp khác, tôi đã biết về sự tồn tại của CheckStyle - một plugin đặc biệt kiểm tra kiểu mã của bạn và bạn sẽ không thể biên dịch dự án của mình cho đến khi bạn sửa lỗi (ví dụ: khoảng trắng thừa, tên biến có chữ in hoa, tên biến quá ngắn). Sau khi đánh bại CheckStyle, tôi đã gửi mã của mình để các nhà phát triển cấp cao xem xét và sửa lỗi trong vòng một tuần. Nói chung, tôi rất may mắn khi trong nhóm của mình có mối quan hệ tốt với nhà phát triển thứ hai, người đã giải thích rất nhiều điều. Một tháng sau khi thiết bị, tích hợp đầu tiên của tôi đã được triển khai trên kệ Tích hợp-Chức năng (hoạt động của tất cả các ứng dụng cùng nhau đã được kiểm tra) và mọi thứ đều hoạt động ở đó! Chiến thắng! Nhiệm vụ tiếp theo là tạo một lớp cho phép ẩn dữ liệu bằng khóa trong json. Ví dụ: có json {text:"JavaRush"} -> đang xử lý -> {text:"****Rush"}. Có hai điều phức tạp ở đây: có thể có {text:{mytext:"JavaRush"}} lồng nhau và điều khó chịu hơn là việc lồng nhau bên trong mảng: {text: [ {mytext: "JavaRush"}, {mytext: "JavaRush "} ] } (tất nhiên là bạn cần ẩn toàn bộ text.mytext). Giải quyết vấn đề này hóa ra khá khó khăn, nhưng tôi đã làm được! Ở đây, nhà phát triển thứ hai nói: hãy bao quát quá trình phát triển này bằng các thử nghiệm. Trong mắt có sự hoang mang. Đây là cách tôi làm quen với thư viện JUnit trong chiến đấu. Bản chất của kiểm thử đơn vị: bạn có dữ liệu đầu vào, chuyển nó vào một phương thức và so sánh dữ liệu nhận được với kết quả chính xác (tạo một biến có kết quả chính xác). Tôi đã viết 11 trường hợp cho thư viện của mình, trong đó tôi đã kiểm tra rằng ứng dụng không gặp sự cố với NullPointException và nó ẩn dữ liệu một cách chính xác với bất kỳ kiểu lồng nào. Sau khi hoàn thành nhiệm vụ này, tôi đã nhận được một tích hợp mới, điểm đặc biệt của nó là: Tôi phải xuất Spring Bean từ thư viện bên ngoài. Tại thời điểm này, tôi đã trở thành khách hàng thường xuyên của trang web Stack OverFlow. Có lần ngay cả một nhà phát triển chính thức của Spring cũng phản hồi. Sau khi triển khai tích hợp này, thời gian dùng thử của tôi đã kết thúc. Sếp chúc mừng tôi đã vượt qua thời gian thử việc và tôi bắt đầu viết bài này. Tổng cộng mất 8 giờ để viết bài này) Cảm ơn bạn đã quan tâm, tôi hy vọng bài viết này hữu ích. Tôi đã cố gắng viết ra mối liên hệ của tất cả các lớp, nhưng chẳng có gì đọng lại trong đầu tôi cả. Khoảnh khắc đáng xấu hổ nhất là thiếu kiến thức về Intellij Idea: cách tìm kiếm một dự án trên toàn cầu, tái cấu trúc mã, v.v. Khi nhận nhiệm vụ, tôi đã hiểu tại sao cần phải có OOP: với một lượng code lớn như vậy thì cần phải chia thành các lớp; các phương thức không được sử dụng bên ngoài lớp phải được khai báo là riêng tư để không vô tình chạy chúng trong lớp khác, v.v. Sau khi viết phần tích hợp của mình bằng cách tương tự với một phần tích hợp khác, tôi đã biết về sự tồn tại của CheckStyle - một plugin đặc biệt kiểm tra kiểu mã của bạn và bạn sẽ không thể biên dịch dự án của mình cho đến khi bạn sửa lỗi (ví dụ: khoảng trắng thừa, tên biến có chữ in hoa, tên biến quá ngắn). Sau khi đánh bại CheckStyle, tôi đã gửi mã của mình để các nhà phát triển cấp cao xem xét và sửa lỗi trong vòng một tuần. Nói chung, tôi rất may mắn khi trong nhóm của mình có mối quan hệ tốt với nhà phát triển thứ hai, người đã giải thích rất nhiều điều. Một tháng sau khi thiết bị, tích hợp đầu tiên của tôi đã được triển khai trên kệ Tích hợp-Chức năng (hoạt động của tất cả các ứng dụng cùng nhau đã được kiểm tra) và mọi thứ đều hoạt động ở đó! Chiến thắng! Nhiệm vụ tiếp theo là tạo một lớp cho phép ẩn dữ liệu bằng khóa trong json. Ví dụ: có json {text:"JavaRush"} -> đang xử lý -> {text:"****Rush"}. Có hai điều phức tạp ở đây: có thể có {text:{mytext:"JavaRush"}} lồng nhau và điều khó chịu hơn là việc lồng nhau bên trong mảng: {text: [ {mytext: "JavaRush"}, {mytext: "JavaRush "} ] } (tất nhiên là bạn cần ẩn toàn bộ text.mytext). Giải quyết vấn đề này hóa ra khá khó khăn, nhưng tôi đã làm được! Ở đây, nhà phát triển thứ hai nói: hãy bao quát quá trình phát triển này bằng các thử nghiệm. Trong mắt có sự hoang mang. Đây là cách tôi làm quen với thư viện JUnit trong chiến đấu. Bản chất của kiểm thử đơn vị: bạn có dữ liệu đầu vào, chuyển nó vào một phương thức và so sánh dữ liệu nhận được với kết quả chính xác (tạo một biến có kết quả chính xác). Tôi đã viết 11 trường hợp cho thư viện của mình, trong đó tôi đã kiểm tra rằng ứng dụng không gặp sự cố với NullPointException và nó ẩn dữ liệu một cách chính xác với bất kỳ kiểu lồng nào. Sau khi hoàn thành nhiệm vụ này, tôi đã nhận được một tích hợp mới, điểm đặc biệt của nó là: Tôi phải xuất Spring Bean từ thư viện bên ngoài. Tại thời điểm này, tôi đã trở thành khách hàng thường xuyên của trang web Stack OverFlow. Có lần ngay cả một nhà phát triển chính thức của Spring cũng phản hồi. Sau khi triển khai tích hợp này, thời gian dùng thử của tôi đã kết thúc. Sếp chúc mừng tôi đã vượt qua thời gian thử việc và tôi bắt đầu viết bài này. Tổng cộng mất 8 giờ để viết bài này) Cảm ơn bạn đã quan tâm, tôi hy vọng bài viết này hữu ích. Đối với số lượng mã lớn như vậy, bạn cần chia nó thành các lớp; các phương thức không được sử dụng bên ngoài lớp phải được khai báo là riêng tư để không vô tình chạy chúng trong lớp khác, v.v. Sau khi viết phần tích hợp của mình bằng cách tương tự với một phần tích hợp khác, tôi đã biết về sự tồn tại của CheckStyle - một plugin đặc biệt kiểm tra kiểu mã của bạn và bạn sẽ không thể biên dịch dự án của mình cho đến khi bạn sửa lỗi (ví dụ: khoảng trắng thừa, tên biến có chữ in hoa, tên biến quá ngắn). Sau khi đánh bại CheckStyle, tôi đã gửi mã của mình để các nhà phát triển cấp cao xem xét và sửa lỗi trong vòng một tuần. Nói chung, tôi rất may mắn khi trong nhóm của mình có mối quan hệ tốt với nhà phát triển thứ hai, người đã giải thích rất nhiều điều. Một tháng sau khi thiết bị, tích hợp đầu tiên của tôi đã được triển khai trên kệ Tích hợp-Chức năng (hoạt động của tất cả các ứng dụng cùng nhau đã được kiểm tra) và mọi thứ đều hoạt động ở đó! Chiến thắng! Nhiệm vụ tiếp theo là tạo một lớp cho phép ẩn dữ liệu bằng khóa trong json. Ví dụ: có json {text:"JavaRush"} -> đang xử lý -> {text:"****Rush"}. Có hai điều phức tạp ở đây: có thể có {text:{mytext:"JavaRush"}} lồng nhau và điều khó chịu hơn là việc lồng nhau bên trong mảng: {text: [ {mytext: "JavaRush"}, {mytext: "JavaRush "} ] } (tất nhiên là bạn cần ẩn toàn bộ text.mytext). Giải quyết vấn đề này hóa ra khá khó khăn, nhưng tôi đã làm được! Ở đây, nhà phát triển thứ hai nói: hãy bao quát quá trình phát triển này bằng các thử nghiệm. Trong mắt có sự hoang mang. Đây là cách tôi làm quen với thư viện JUnit trong chiến đấu. Bản chất của kiểm thử đơn vị: bạn có dữ liệu đầu vào, chuyển nó vào một phương thức và so sánh dữ liệu nhận được với kết quả chính xác (tạo một biến có kết quả chính xác). Tôi đã viết 11 trường hợp cho thư viện của mình, trong đó tôi đã kiểm tra rằng ứng dụng không gặp sự cố với NullPointException và nó ẩn dữ liệu một cách chính xác với bất kỳ kiểu lồng nào. Sau khi hoàn thành nhiệm vụ này, tôi đã nhận được một tích hợp mới, điểm đặc biệt của nó là: Tôi phải xuất Spring Bean từ thư viện bên ngoài. Tại thời điểm này, tôi đã trở thành khách hàng thường xuyên của trang web Stack OverFlow. Có lần ngay cả một nhà phát triển chính thức của Spring cũng phản hồi. Sau khi triển khai tích hợp này, thời gian dùng thử của tôi đã kết thúc. Sếp chúc mừng tôi đã vượt qua thời gian thử việc và tôi bắt đầu viết bài này. Tổng cộng mất 8 giờ để viết bài này) Cảm ơn bạn đã quan tâm, tôi hy vọng bài viết này hữu ích. Đối với số lượng mã lớn như vậy, bạn cần chia nó thành các lớp; các phương thức không được sử dụng bên ngoài lớp phải được khai báo là riêng tư để không vô tình chạy chúng trong lớp khác, v.v. Sau khi viết phần tích hợp của mình bằng cách tương tự với một phần tích hợp khác, tôi đã biết về sự tồn tại của CheckStyle - một plugin đặc biệt kiểm tra kiểu mã của bạn và bạn sẽ không thể biên dịch dự án của mình cho đến khi bạn sửa lỗi (ví dụ: khoảng trắng thừa, tên biến có chữ in hoa, tên biến quá ngắn). Sau khi đánh bại CheckStyle, tôi đã gửi mã của mình để các nhà phát triển cấp cao xem xét và sửa lỗi trong vòng một tuần. Nói chung, tôi rất may mắn khi trong nhóm của mình có mối quan hệ tốt với nhà phát triển thứ hai, người đã giải thích rất nhiều điều. Một tháng sau khi thiết bị, tích hợp đầu tiên của tôi đã được triển khai trên kệ Tích hợp-Chức năng (hoạt động của tất cả các ứng dụng cùng nhau đã được kiểm tra) và mọi thứ đều hoạt động ở đó! Chiến thắng! Nhiệm vụ tiếp theo là tạo một lớp cho phép ẩn dữ liệu bằng khóa trong json. Ví dụ: có json {text:"JavaRush"} -> đang xử lý -> {text:"****Rush"}. Có hai điều phức tạp ở đây: có thể có {text:{mytext:"JavaRush"}} lồng nhau và điều khó chịu hơn là việc lồng nhau bên trong mảng: {text: [ {mytext: "JavaRush"}, {mytext: "JavaRush "} ] } (tất nhiên là bạn cần ẩn toàn bộ text.mytext). Giải quyết vấn đề này hóa ra khá khó khăn, nhưng tôi đã làm được! Ở đây, nhà phát triển thứ hai nói: hãy bao quát quá trình phát triển này bằng các thử nghiệm. Trong mắt có sự hoang mang. Đây là cách tôi làm quen với thư viện JUnit trong chiến đấu. Bản chất của kiểm thử đơn vị: bạn có dữ liệu đầu vào, chuyển nó vào một phương thức và so sánh dữ liệu nhận được với kết quả chính xác (tạo một biến có kết quả chính xác). Tôi đã viết 11 trường hợp cho thư viện của mình, trong đó tôi đã kiểm tra rằng ứng dụng không gặp sự cố với NullPointException và nó ẩn dữ liệu một cách chính xác với bất kỳ kiểu lồng nào. Sau khi hoàn thành nhiệm vụ này, tôi đã nhận được một tích hợp mới, điểm đặc biệt của nó là: Tôi phải xuất Spring Bean từ thư viện bên ngoài. Tại thời điểm này, tôi đã trở thành khách hàng thường xuyên của trang web Stack OverFlow. Có lần ngay cả một nhà phát triển chính thức của Spring cũng phản hồi. Sau khi triển khai tích hợp này, thời gian dùng thử của tôi đã kết thúc. Sếp chúc mừng tôi đã vượt qua thời gian thử việc và tôi bắt đầu viết bài này. Tổng cộng mất 8 giờ để viết bài này) Cảm ơn bạn đã quan tâm, tôi hy vọng bài viết này hữu ích. tên biến quá ngắn). Sau khi đánh bại CheckStyle, tôi đã gửi mã của mình để các nhà phát triển cấp cao xem xét và sửa lỗi trong vòng một tuần. Nói chung, tôi rất may mắn khi trong nhóm của mình có mối quan hệ tốt với nhà phát triển thứ hai, người đã giải thích rất nhiều điều. Một tháng sau khi thiết bị, tích hợp đầu tiên của tôi đã được triển khai trên kệ Tích hợp-Chức năng (hoạt động của tất cả các ứng dụng cùng nhau đã được kiểm tra) và mọi thứ đều hoạt động ở đó! Chiến thắng! Nhiệm vụ tiếp theo là tạo một lớp cho phép ẩn dữ liệu bằng khóa trong json. Ví dụ: có json {text:"JavaRush"} -> đang xử lý -> {text:"****Rush"}. Có hai điều phức tạp ở đây: có thể có {text:{mytext:"JavaRush"}} lồng nhau và điều khó chịu hơn là việc lồng nhau bên trong mảng: {text: [ {mytext: "JavaRush"}, {mytext: "JavaRush "} ] } (tất nhiên là bạn cần ẩn toàn bộ text.mytext). Giải quyết vấn đề này hóa ra khá khó khăn, nhưng tôi đã làm được! Ở đây, nhà phát triển thứ hai nói: hãy bao quát quá trình phát triển này bằng các thử nghiệm. Trong mắt có sự hoang mang. Đây là cách tôi làm quen với thư viện JUnit trong chiến đấu. Bản chất của kiểm thử đơn vị: bạn có dữ liệu đầu vào, chuyển nó vào một phương thức và so sánh dữ liệu nhận được với kết quả chính xác (tạo một biến có kết quả chính xác). Tôi đã viết 11 trường hợp cho thư viện của mình, trong đó tôi đã kiểm tra rằng ứng dụng không gặp sự cố với NullPointException và nó ẩn dữ liệu một cách chính xác với bất kỳ kiểu lồng nào. Sau khi hoàn thành nhiệm vụ này, tôi đã nhận được một tích hợp mới, điểm đặc biệt của nó là: Tôi phải xuất Spring Bean từ thư viện bên ngoài. Tại thời điểm này, tôi đã trở thành khách hàng thường xuyên của trang web Stack OverFlow. Có lần ngay cả một nhà phát triển chính thức của Spring cũng phản hồi. Sau khi triển khai tích hợp này, thời gian dùng thử của tôi đã kết thúc. Sếp chúc mừng tôi đã vượt qua thời gian thử việc và tôi bắt đầu viết bài này. Tổng cộng mất 8 giờ để viết bài này) Cảm ơn bạn đã quan tâm, tôi hy vọng bài viết này hữu ích. tên biến quá ngắn). Sau khi đánh bại CheckStyle, tôi đã gửi mã của mình để các nhà phát triển cấp cao xem xét và sửa lỗi trong vòng một tuần. Nói chung, tôi rất may mắn khi trong nhóm của mình có mối quan hệ tốt với nhà phát triển thứ hai, người đã giải thích rất nhiều điều. Một tháng sau khi thiết bị, tích hợp đầu tiên của tôi đã được triển khai trên kệ Tích hợp-Chức năng (hoạt động của tất cả các ứng dụng cùng nhau đã được kiểm tra) và mọi thứ đều hoạt động ở đó! Chiến thắng! Nhiệm vụ tiếp theo là tạo một lớp cho phép ẩn dữ liệu bằng khóa trong json. Ví dụ: có json {text:"JavaRush"} -> đang xử lý -> {text:"****Rush"}. Có hai điều phức tạp ở đây: có thể có {text:{mytext:"JavaRush"}} lồng nhau và điều khó chịu hơn là việc lồng nhau bên trong mảng: {text: [ {mytext: "JavaRush"}, {mytext: "JavaRush "} ] } (tất nhiên là bạn cần ẩn toàn bộ text.mytext). Giải quyết vấn đề này hóa ra khá khó khăn, nhưng tôi đã làm được! Ở đây, nhà phát triển thứ hai nói: hãy bao quát quá trình phát triển này bằng các thử nghiệm. Trong mắt có sự hoang mang. Đây là cách tôi làm quen với thư viện JUnit trong chiến đấu. Bản chất của kiểm thử đơn vị: bạn có dữ liệu đầu vào, chuyển nó vào một phương thức và so sánh dữ liệu nhận được với kết quả chính xác (tạo một biến có kết quả chính xác). Tôi đã viết 11 trường hợp cho thư viện của mình, trong đó tôi đã kiểm tra rằng ứng dụng không gặp sự cố với NullPointException và nó ẩn dữ liệu một cách chính xác với bất kỳ kiểu lồng nào. Sau khi hoàn thành nhiệm vụ này, tôi đã nhận được một tích hợp mới, điểm đặc biệt của nó là: Tôi phải xuất Spring Bean từ thư viện bên ngoài. Tại thời điểm này, tôi đã trở thành khách hàng thường xuyên của trang web Stack OverFlow. Có lần ngay cả một nhà phát triển chính thức của Spring cũng phản hồi. Sau khi triển khai tích hợp này, thời gian dùng thử của tôi đã kết thúc. Sếp chúc mừng tôi đã vượt qua thời gian thử việc và tôi bắt đầu viết bài này. Tổng cộng mất 8 giờ để viết bài này) Cảm ơn bạn đã quan tâm, tôi hy vọng bài viết này hữu ích. Giải quyết vấn đề này hóa ra khá khó khăn, nhưng tôi đã làm được! Ở đây, nhà phát triển thứ hai nói: hãy bao quát quá trình phát triển này bằng các thử nghiệm. Trong mắt có sự hoang mang. Đây là cách tôi làm quen với thư viện JUnit trong chiến đấu. Bản chất của kiểm thử đơn vị: bạn có dữ liệu đầu vào, chuyển nó vào một phương thức và so sánh dữ liệu nhận được với kết quả chính xác (tạo một biến có kết quả chính xác). Tôi đã viết 11 trường hợp cho thư viện của mình, trong đó tôi đã kiểm tra rằng ứng dụng không gặp sự cố với NullPointException và nó ẩn dữ liệu một cách chính xác với bất kỳ kiểu lồng nào. Sau khi hoàn thành nhiệm vụ này, tôi đã nhận được một tích hợp mới, điểm đặc biệt của nó là: Tôi phải xuất Spring Bean từ thư viện bên ngoài. Tại thời điểm này, tôi đã trở thành khách hàng thường xuyên của trang web Stack OverFlow. Có lần ngay cả một nhà phát triển chính thức của Spring cũng phản hồi. Sau khi triển khai tích hợp này, thời gian dùng thử của tôi đã kết thúc. Sếp chúc mừng tôi đã vượt qua thời gian thử việc và tôi bắt đầu viết bài này. Tổng cộng mất 8 giờ để viết bài này) Cảm ơn bạn đã quan tâm, tôi hy vọng bài viết này hữu ích. Giải quyết vấn đề này hóa ra khá khó khăn, nhưng tôi đã làm được! Ở đây, nhà phát triển thứ hai nói: hãy bao quát quá trình phát triển này bằng các thử nghiệm. Trong mắt có sự hoang mang. Đây là cách tôi làm quen với thư viện JUnit trong chiến đấu. Bản chất của kiểm thử đơn vị: bạn có dữ liệu đầu vào, chuyển nó vào một phương thức và so sánh dữ liệu nhận được với kết quả chính xác (tạo một biến có kết quả chính xác). Tôi đã viết 11 trường hợp cho thư viện của mình, trong đó tôi đã kiểm tra rằng ứng dụng không gặp sự cố với NullPointException và nó ẩn dữ liệu một cách chính xác với bất kỳ kiểu lồng nào. Sau khi hoàn thành nhiệm vụ này, tôi đã nhận được một tích hợp mới, điểm đặc biệt của nó là: Tôi phải xuất Spring Bean từ thư viện bên ngoài. Tại thời điểm này, tôi đã trở thành khách hàng thường xuyên của trang web Stack OverFlow. Có lần ngay cả một nhà phát triển chính thức của Spring cũng phản hồi. Sau khi triển khai tích hợp này, thời gian dùng thử của tôi đã kết thúc. Sếp chúc mừng tôi đã vượt qua thời gian thử việc và tôi bắt đầu viết bài này. Tổng cộng mất 8 giờ để viết bài này) Cảm ơn bạn đã quan tâm, tôi hy vọng bài viết này hữu ích.
GO TO FULL VERSION