Gặp khó khăn khi nâng cao kỹ năng lập trình của bạn? Hãy thử làm chủ hai tư duy này

Khi một nhà phát triển tiếp cận một vấn đề, họ thường có một mục tiêu rõ ràng. Sửa lỗi này, tạo thành phần đó, tái cấu trúc cài đặt này. Theo bản chất, chúng ta rất hướng đến mục tiêu. Chúng ta có một mục tiêu mà chúng ta cần đạt được, và chúng ta phải thử tất cả các kỹ thuật mà chúng ta đã học để đạt được mục tiêu đó. Nhưng điều gì ít được thảo luận hơn là tư duy của một nhà phát triển: cách chúng ta nghĩ, thay vì nghĩ gì, để giải quyết một vấn đề lập trình.

Tôi muốn chia sẻ một số ý kiến về hai tư duy cụ thể mà tôi nhận ra mình luân phiên giữa suốt phần lớn sự nghiệp của mình. Nhưng đây là phần buồn cười... Tôi hiếm khi nhận ra khi nào mình chuyển đổi giữa chúng. Nhìn lại, nếu tôi nhận ra mô hình này, tôi có thể đã tiết kiệm được hàng giờ nghĩ về các giải pháp hoàn hảo cho vấn đề.

Để bạn hiểu rõ hơn về các giai đoạn khác nhau của phát triển phần mềm, tôi sẽ kể một chút về dự án mà tôi đã đang làm. Sau đó, chúng ta sẽ xem xét kỹ hơn hai tư duy của lập trình viên. Cuối cùng, tôi sẽ đưa ra một số gợi ý về cách sử dụng hai phương pháp và cách thức để hồi hướng hơn trong quá trình.

Hành trình gần đây của tôi

Hiện tại, đội của tôi đang ở một điểm thú vị trong hành trình dài của chúng tôi. Từ tháng 6 năm 2019, chúng tôi đã di chuyển ứng dụng đặt món ăn của Just Eat Takeaway.com lên một ngăn xếp hiện đại với Next.js, React và Redux Saga. Trong suốt năm qua, đội của chúng tôi đã phát triển đến mức nó trở nên hữu ích để chia thành các đội nhỏ với một bộ trách nhiệm chuyên sâu hơn.

Chúng tôi bắt đầu bằng cách xây dựng trang menu & thanh toán của trang web. Điều này bao gồm các phần tiêu đề, bao gồm tìm kiếm địa điểm và đăng nhập tài khoản, cũng như menu, giỏ hàng và cơ chế đặt hàng.

Trong vòng 1,5 năm tiếp theo, tôi chuyển từ nhóm chịu trách nhiệm về trải nghiệm menu & thanh toán đến trang danh sách nhà hàng, nơi người dùng chọn nhà hàng muốn đặt món. Thách thức chính của chúng tôi cho trang này là triển khai các bộ lọc và cơ chế sắp xếp khác nhau. Sau khi hoàn thành trang danh sách nhà hàng, tôi chuyển sang nhóm xử lý phát triển các thành phần chung của toàn bộ trang web (tiêu đề, chân trang, đăng nhập tài khoản, vv).

Mỗi nhóm chịu trách nhiệm xây dựng trang từ đầu. Trong giai đoạn này, tôi chủ yếu ở trong những gì tôi bắt đầu gọi là tư duy kiến trúc sư.

Khi ứng dụng bắt đầu hoàn thành, chúng tôi không xây dựng nhiều tính năng và cơ chế mới nữa, và các quy ước chủ yếu đã ổn định. Thay vào đó, chúng tôi đang theo những gì đã có sẵn. Chúng tôi thảo luận và đồng ý tuân theo các quy ước mã hóa mà chúng tôi đã thiết lập cùng nhau. Bạn có thể coi đó như là xây dựng trên nền tảng đã có. Đây là tư duy khác, điều mà tôi gọi là tư duy điều chỉnh viên.

Hai Tư duy

Sau một thời gian dài thảo luận, tôi cảm thấy nhãn nhất cho hai tư duy này là kiến trúc sư và điều chỉnh viên. Không tư duy nào tốt hơn tư duy kia. Cả hai tư duy hoạt động cùng nhau như yin và yang. Cả hai tư duy đều được sử dụng bởi các nhà phát triển ở mọi cấp độ kinh nghiệm. Bí quyết là chú ý khi nào là thời điểm tốt nhất để ở trong một tư duy hơn tư duy kia.

Hãy bắt đầu thôi.

Con Đường của Kiến Trúc Sư

Khi xây dựng một ứng dụng từ đầu, chúng ta có thể giả định những điều sau:

• Nếu cần triển khai một tính năng mới, không có mã nguồn hiện tại mà bạn có thể tái sử dụng. Bạn sẽ phải viết mã từ đầu.
• Quyết định về kiến trúc sẽ mang lại nhiều ảnh hưởng. Bạn sẽ giới thiệu những quy ước mới.
• Bạn có một số linh hoạt để giới thiệu gói, plugin hoặc phần mềm mà cơ sở hạ tầng của ứng dụng của bạn sẽ phụ thuộc vào.

Trong tư duy kiến trúc sư, bạn sẽ không tìm kiếm mã nguồn trong ứng dụng của mình vì sẽ không có. Việc ở trong tư duy kiến trúc sư có nghĩa là biết rằng con đường trước mặt bạn sẽ liên quan đến việc khám phá ý tưởng mới và thiết kế một giải pháp hiện tại chưa tồn tại.

Đây là lúc chúng ta bắt đầu sử dụng bút sáp trắng và tới bảng trắng. Bạn sẽ cân nhắc quyết định về một cách triển khai có thể so sánh với cách triển khai khác. Điều này có nghĩa là suy nghĩ về tương lai của phần mềm — chọn một phương thức ngay bây giờ có thể được tham khảo cho đến một ngày nó trở nên phổ biến khắp nơi trong ứng dụng của bạn và ngày càng khó thay thế.

Cách của Bộ Chuyển Đổi

Tư duy chuyển đổi xuất hiện khi bạn làm việc trên một ứng dụng đã phát triển hơn. Quy ước mã nguồn đã được thiết lập, tài liệu đã được viết và viết lại, và bạn chia sẻ một tiêu chuẩn chất lượng nhất định giữa các thành viên trong nhóm.

Khi chuyển từ việc cần xây dựng một cái gì đó mới sang việc mở rộng những gì đã có, chúng ta bắt đầu với tư duy chuyển đổi. Điều này cho phép chúng ta giữ quy ước cho các mô hình cụ thể trong đầu. Chúng có thể nhỏ như ưu tiên Boolean(foo) hơn !!foo hoặc đặt tên các tạo ra hành động redux theo quá khứ như orderSubmitted, preferenceSaved, v.v.

Trong tư duy này, chúng ta tập trung hơn vào việc sử dụng những gì đã có, thay vì xây dựng một cái gì đó hoàn toàn mới hoặc theo một cách tiếp cận mới. Chúng ta đang tuân thủ các mô hình đã được đặt ra bởi các nhà phát triển trước đó.

Điều này đều dựa vào giả định là bạn và nhóm của bạn đã suy nghĩ một cách chiến lược về cách xây dựng ứng dụng của mình. Những quyết định kiến trúc tốt đã được đưa ra để cho phép phần mềm của bạn mở rộng và mở rộng. Một phần của việc theo mô hình chuyển đổi bao gồm xác định xem một triển khai hiện tại có nên được tái sử dụng hay không hay liệu cần một giải pháp tốt hơn và có thể tái sử dụng hơn hay không.

Hãy tưởng tượng bạn tham gia một dự án lớn đã hoạt động được 2 năm trở lên. Trong quá trình xây dựng ứng dụng, nhóm đang thêm vào các mô hình, schema, hợp đồng, hằng số, tiện ích, bộ chọn, v.v. để triển khai các chức năng. Những chức năng đa dạng này sẽ phụ thuộc và được sử dụng trong toàn bộ ứng dụng. Với tư duy chuyển đổi, bạn có thể giả định rằng bạn nên tuân thủ các quy ước đã được đặt ra cho bạn. Điều này đưa bạn vào tư duy chuyển đổi.

Có một tư duy tốt hơn tư duy kia không?

Bạn có thể nhanh chóng nghĩ rằng chúng ta muốn thường xuyên áp dụng tư duy kiến trúc, nhưng điều này không phải là đúng. Để xây dựng một phần mềm một cách hiệu quả, một nhà phát triển phải liên tục chuyển đổi giữa hai tư duy tùy thuộc vào công việc cụ thể.

Đặt một nhà phát triển mới vào tư duy kiến trúc có thể là một phương pháp hiệu quả để tìm cách làm một điều gì đó tốt hơn, có thể là trong quá trình phát triển hoặc trong mã nguồn chính nó. Ngược lại, một nhà phát triển cấp cao được giao nhiệm vụ làm việc trên mã nguồn hiện tại cũng có thể giúp nhận ra các xu hướng trong cách ứng dụng được xây dựng.

Chuyển đổi giữa hai tư duy

Không có cách tiếp cận nào tốt hơn cách tiếp cận khác. Trên thực tế, với tư duy kiến trúc và tư duy chuyển đổi, chúng ta cần nắm vững cả hai phương pháp. Dĩ nhiên, một nhà phát triển mới sẽ có thể thường xuyên ở trong tư duy chuyển đổi khi học cách làm việc với mã nguồn và cách mở rộng những gì đã có. Nhưng nhà phát triển cấp cao có thể hưởng lợi lớn từ việc nắm vững tư duy này. Một nhà phát triển không nhận ra họ có thể tái sử dụng một triển khai trước đó sẽ phải làm việc gấp đôi — trước hết là việc viết triển khai của họ một cách không cần thiết và sau đó khi một đồng nghiệp chỉ ra rằng logic này đã tồn tại trong ứng dụng và họ phải loại bỏ những gì họ đã viết.

Hãy giả sử bạn đã nhận nhiệm vụ khôi phục các ưu tiên người dùng từ cookie hoặc bộ nhớ cục bộ sau khi làm mới trang. Giả sử bạn không biết nhiều về chủ đề này và ứng dụng đã khá phát triển. Một nhà phát triển thông minh sẽ đầu tiên nghiên cứu xem có các cơ chế nào đã tồn tại và có thể tái sử dụng được hay không. Bạn hỏi một số đồng nghiệp có thể biết và sau đó kiểm tra mã nguồn và thử nghiệm chuỗi sự kiện cho luồng cụ thể. Đây là những bước chúng ta thực hiện khi chúng ta ở trong tư duy chuyển đổi.

Giả sử một tình huống khác nữa: bạn cần yêu cầu một số dữ liệu người dùng cụ thể từ một API riêng biệt. Bạn nhận thấy không có yêu cầu GET nào được thực hiện đối với API này, đồng thời đòi hỏi xác thực, cả hai đều chưa được triển khai. Bây giờ bạn phải xem xét làm thế nào để mở rộng logic hiện tại hoặc liệu bạn có cần triển khai những cơ chế này từ đầu hay không. Đây là lúc chúng ta chuyển sang tư duy kiến trúc. Sau đó, chúng ta phải bắt đầu suy nghĩ về các bước kiến trúc để tạo ra một cái gì đó mới, thay vì chỉ đơn giản là sử dụng và cải thiện những gì đã có.

Những mẹo

Bây giờ khi chúng ta đã hiểu về hai tư duy và mối quan hệ giữa chúng, tôi có một số mẹo về cách sử dụng kiến thức của chúng ta một cách tốt nhất.

Hãy chú ý đến cách bạn suy nghĩ khi làm việc trên một nhiệm vụ

Rất nhiều lần chúng ta tập trung vào việc tìm kiếm một giải pháp mà chúng ta không dừng lại để xem xét cách chúng ta tiế approach vấn đề. Cần thực hành để thoái ra một chút và nghĩ: “Tôi có tiếp cận vấn đề đúng cách không? Tôi đã kiểm tra mã nguồn để tìm một triển khai tương tự có thể tái sử dụng chưa? Hay tôi chỉ đang lập trình tự động?” Việc đặt những câu hỏi như vậy cho bản thân sẽ giúp bạn phản ánh về cách tiếp cận của mình - điều mà tôi khuyến khích mọi người nên làm, không chỉ riêng các nhà phát triển.

Nếu bạn nhận ra mình đã mắc sai lầm vì không ở trong tư duy đúng, đừng lo lắng

Sự cảm hứng cho bài viết này đến từ việc tôi đã bị mắc kẹt trong tư duy kiểu kết nối trong một hoặc hai ngày. Tôi tiếp tục tìm kiếm một cách giải quyết vấn đề từ trước đó. Tôi cố gắng nhìn nhận các triển khai trước đó từ các góc độ khác nhau, nhưng tôi không thể đạt được một giải pháp thoải mái. Tôi bắt đầu đau đầu về thời gian mà tôi đã mất, cách tôi không thể khiến ứng dụng hoạt động theo cách mà tôi muốn; tôi bắt đầu đánh giá mức tiến triển mà tôi đã đạt được.

Sau đó, một ý nghĩa sáng ? đèn bật lên trong đầu tôi. Tôi đang cố gắng mở rộng điều hiện có trong mã nguồn. Chỉ sau nhiều lần thử nghiệm và sai lầm, tôi nhận ra rằng tôi đã tiếp cận vấn đề từ tư duy sai. Tôi cần tiếp cận vấn đề từ tư duy kiến trúc. Tôi đã thực hiện nghiên cứu và thử nghiệm, và xác định rằng giải pháp không tồn tại trong mã nguồn. Tôi sẽ phải xây dựng nó từ đầu.

Sự nhận thức muộn này thường xuyên xảy ra hơn bạn nghĩ. Đừng tự mình trách nhiệm nếu bạn mất một khoảng thời gian để kết nối như tôi đã làm. Điều này là một phần quan trọng của việc phát triển như một nhà phát triển. Quan trọng nhất là bạn ghi chú những khoảnh khắc này trong sự nghiệp của mình và học từ chúng.

Tự suy ngẫm về quy trình của bạn

Khi tôi bắt đầu làm việc tại JET, một đồng nghiệp chia sẻ cách tiếp cận hàng ngày và hàng tuần của anh ấy để hoàn thành công việc. Anh ấy nói rằng anh ấy có một “cuộc đứng dậy cá nhân” mỗi sáng khi kiểm tra danh sách Công việc cần làm và quyết định ưu tiên. Cuối tuần, anh ấy dành vài giờ để suy ngẫm về tuần trước đó, trả lời các câu hỏi như:

• Có điều gì tốt? Có điều gì không tốt?
• Các hoạt động nào đang mang lại năng lượng và hoạt động nào đang tốn năng lượng từ bạn?
• Bạn có duy trì các thói quen tốt không? Bạn có phát triển các thói quen xấu không? Làm thế nào bạn có thể sửa chúng?
• Bạn có nhận thức nào trong suốt tuần mà bạn muốn tập trung vào tuần tiếp theo không?

Việc đặt những loại câu hỏi này và tự chủ động suy ngẫm về quy trình làm việc của bạn có thể thay đổi trò chơi. Điều này sẽ giúp bạn nhận thức hơn về cách bạn làm việc và trải qua ngày của mình thay vì tự động thực hiện công việc mà không nghĩ nhiều về tại sao bạn làm điều đó hoặc liệu có cách tốt hơn không.

Tôi đánh giá cao cách những khái niệm này được phản ánh trong scrum. Là một người thực hành scrum và agile, bạn sẽ tham gia vào các buổi lễ như Retrospectives, nơi đội sẽ phản ánh về sprint trước và đặt các câu hỏi tương tự như những câu hỏi nêu trên. Dành thời gian để suy ngẫm về cách bạn cảm thấy về ngày/tuần/sprint trước đó là một chiến thuật tài tình để nhìn nhận trung thực về cách bạn hoặc đội của bạn làm việc.

Kết luận

Đôi khi cảm giác như bạn được kỳ vọng biết tất cả những câu trả lời về mã nguồn của bạn. Chúng ta rơi vào mô hình tư duy này nơi chúng ta cần làm việc càng nhanh càng tốt, so sánh với đồng nghiệp, và quên đi thời gian để suy ngẫm về những gì chúng ta đang thực sự làm. Làm việc theo cách này sẽ tạo ra căng thẳng và có thể dẫn đến burnout.

Đó là lý do tại sao nghĩ về cách bạn nghĩ quan trọng. Khi bạn đang lên kế hoạch cách tiếp cận một nhiệm vụ lập trình, hãy tự hỏi “Tư duy nào tôi cần ở hiện tại? Phương pháp nào có thể dẫn tôi đến một giải pháp chất lượng cao nhất?”

Phát triển phần mềm luôn là về thử nghiệm và sai lầm. Luôn đòi hỏi tinh thần và thể chất. Chúng ta cần chăm sóc tâm trí và cơ thể nếu muốn làm việc hiệu quả cả trong công việc và cuộc sống hàng ngày. Dành thời gian để rút lui và suy ngẫm về cách — thay vì về điều gì — bạn nghĩ sẽ dẫn bạn đến những nhận thức đầy sáng tạo về quy trình của chính bạn.

Bài viết này được xuất bản ban đầu trên blog trung bình của Just Eat Takeaway-Tech. Bạn có thể đọc nó tại đây.

Với hơn 580,000 nhà hàng kết nối, Just Eat Takeaway.com là một thị trường giao hàng thức ăn trực tuyến hàng đầu mang đến cho người tiêu dùng nhiều sự lựa chọn. Tham gia cùng người sáng lập và CEO, Jitse Groen, tại TNW2021 để có cuộc trò chuyện sôi nổi về cách hệ sinh thái công nghệ của Hà Lan đã phát triển, những bài học học được, và điều gì sẽ đến tiếp theo cho khổng lồ giao hàng thức ăn.