HTML, CSS, JavaScript, Python, PHP, C ++, Dart - có rất nhiều ngôn ngữ lập trình trên mạng và bạn thậm chí có thể hoàn toàn thông thạo một số ngôn ngữ đó! Nhưng khi chúng ta đặt mục tiêu viết mã ngày càng nhiều và tốt hơn, cách chúng ta viết và giao tiếp bằng ngôn ngữ hàng ngày ngày càng trở nên quan trọng hơn… và thậm chí có thể bị bỏ qua.
Cách chúng ta viết về và xung quanh mã được cho là quan trọng như chính mã. Và mặc dù bạn rơi vào đâu trên dòng đó, tất cả chúng ta đều có thể đồng ý rằng lời nói của chúng ta có khả năng vừa trợ giúp vừa làm tổn hại đến hiệu quả của mã.
Trong bài viết này, tôi muốn phác thảo cách hai lĩnh vực có vẻ khác biệt này - lập trình và viết - có thể kết hợp với nhau và đưa các kỹ năng của nhà phát triển của chúng ta lên một tầm cao mới.
Chờ đã, viết kỹ thuật? Vâng, đó chính xác là những gì tôi muốn nói. Tôi thực sự tin rằng tất cả chúng ta đều là nhà văn theo nghĩa này hay cách khác. Và tôi ở đây để cung cấp cho bạn một tài liệu sơ lược với các mẹo viết, lời khuyên và ví dụ về cách nó có thể khiến bạn vừa là nhà phát triển vừa là người giao tiếp tốt hơn.
Mục lục
Viết kỹ thuật ở khắp mọi nơi
Năm ngoái, nhóm đứng sau ứng dụng khách Mac Git phổ biến, Tower, đã thăm dò ý kiến của hơn 4,000 nhà phát triển và nhận thấy rằng gần 50% trong số họ đã dành từ 3-6 giờ mỗi ngày để viết mã.
Và vâng, đó là một cuộc khảo sát thăm dò một nhóm khá thích hợp, nhưng tôi tưởng tượng nhiều người trong chúng ta rơi vào đâu đó trong phạm vi đó. Dù thế nào đi nữa, một nhà phát triển sẽ không viết mã 24/7, bởi vì như cuộc thăm dò ý kiến này cho thấy, chúng tôi đang dành nhiều thời gian để làm những việc khác.
Điều đó có thể bao gồm:
- demo một tính năng mới,
- ghi lại tính năng mới đó,
- cập nhật phiếu công việc liên quan đến tính năng mới đó, hoặc
- công việc tồn đọng để hỗ trợ tính năng mới đó.
Tất nhiên, luôn có thời gian để nghỉ ngơi trong phòng tắm và Wordle cũng vậy.
Dù sao, hầu hết những điều chúng tôi thường làm liên quan đến giao tiếp với những người như nhóm của bạn, đồng nghiệp, khách hàng, người dùng và các nhà phát triển khác.
Vì vậy, chúng tôi dành rất nhiều thời gian để giao tiếp với con người thông qua từ ngoài giao tiếp mà chúng tôi có với máy tính thông qua mã. Lời nói là ngôn ngữ viết. Và nếu chúng ta viết lời tốt hơn, chúng ta sẽ giao tiếp tốt hơn. Khi chúng ta giao tiếp tốt hơn, chúng ta có nhiều khả năng đạt được những gì chúng ta muốn.
Đó là Viết kỹ thuật 101.
Và nó thậm chí không kết thúc ở đây .. Một số lập trình viên cũng thích tạo ra các sản phẩm của riêng họ, có nghĩa là họ cần phải biến tiếp thị trở thành một phần công việc của họ. Kỹ thuật viết cũng đóng một vai trò rất lớn trong đó. Vì vậy, vâng. Tôi nghĩ rằng khá công bằng khi nói rằng viết kỹ thuật là thực sự mọi nơi.
Ngữ pháp tốt là gì?
Với rất nhiều ngôn ngữ lập trình hiện có, điều cuối cùng chúng tôi muốn là học một ngôn ngữ khác.
Ngữ pháp là một phần không thể thiếu của tiếng Anh, và nó mở ra toàn bộ tiềm năng của giao tiếp. Nó làm cho chúng ta trở nên chính thức, chuyên nghiệp và mạch lạc hơn.
Hãy để tôi cung cấp cho bạn một bản tóm tắt nhanh về ngôn ngữ.
Cú pháp tiếng Anh
Cũng giống như các ngôn ngữ lập trình, tiếng Anh có một cú pháp được xác định rõ ràng và nó bắt đầu bằng các từ.
Các từ là nền tảng của tiếng Anh, và chúng được chia thành tám nhóm:
Danh từ
Đây có thể là tên người, động vật, địa điểm, khái niệm và đồ vật.
Ví dụ:
CSS là một trong những ngôn ngữ cốt lõi của phát triển front-end.
Động từ
Động từ truyền đạt hành động. Ngay cả “là” cũng có thể được coi là một hành động.
Ví dụ:
Biên giới mã số vào buổi sáng và câu trả lời email vào buổi chiều.
Tính từ
Tính từ là cách chúng ta mô tả danh từ. Chúng giống như meta bổ sung thêm chi tiết cho một câu để vẽ nên một bức tranh sống động.
Ví dụ:
- CSS là một thanh lịch và thơ mộng ngôn ngữ.
- HTML cho bảng là phức tạp và cồng kềnh.
- Mô hình Hộp là quan trọng để hiểu CSS.
Giới từ
Giới từ tạo ra mối quan hệ giữa một danh từ và các từ khác, thường chỉ hướng, thời gian, địa điểm và không gian.
Ví dụ:
- Bạn đã cam kết công việc của bạn đến repo?
- đâu là cách tiếp cận lí tưởng nhất cho thành phần này?
- Chúng tôi đã thực hiện các cuộc phỏng vấn với người dùng thực.
Trạng từ
Đôi khi các hành động cần cụ thể hơn, vì vậy chúng tôi sử dụng các trạng từ như “chạy Rychle”Và“ biên dịch từ từ. ” Chúng thường kết thúc bằng “-ly”.
Ví dụ:
- Đây là dễ dàng ý tưởng tốt nhất của tất cả chúng.
- Chip đã đợi kiên nhẫn cho phản hồi của Dale.
- Nhóm đã làm việc siêng năng trên dự án.
Các liên kết
Liên từ kết nối các cụm từ trong một câu. Hãy nhớ bài hát kinh điển này từ chương trình Trường học Rocks?
Ví dụ:
- CSS để tạo kiểu trong khi HTML là để đánh dấu.
- Có, tôi viết mã, nhưng Tôi cũng làm việc về thiết kế.
- Điều đó sửa lỗi. Chưa nó đã giới thiệu một cái mới.
Chuyển tiếp
Các đoạn văn được tạo thành từ các câu được kết nối với nhau bằng cách sử dụng chuyển tiếp.
Ví dụ:
- Có nhiều ngôn ngữ lập trình. Tuy nhiên, chỉ một số ít được sử dụng trong ngành công nghiệp web.
- Tên, sao chép thư mục.
- Tôi thích cách tiếp cận này nhưng Mặt khác, Tôi biết một cái khác.
Đại từ
Khi các danh từ trở nên lặp lại, chúng ta thay thế chúng bằng các đại từ như: “he”, “it” và “that”.
Ví dụ:
- CSS là một ngôn ngữ biểu định kiểu. Chúng tôi sử dụng it để tạo kiểu cho các trang web.
- Tony thích viết mã và he thực hành mỗi ngày.
- Khách hàng của chúng tôi am hiểu công nghệ vì họ biết mã.
Hãy nghĩ về những điều này như UI các thành phần: chúng là các mảnh mô-đun bạn có thể di chuyển xung quanh để xây dựng một câu hoàn chỉnh và chắc chắn, giống như cách bạn có thể ghép lại với nhau một câu hoàn chỉnh và mạnh mẽ UI. Tất cả các thành phần có cần phải luôn ở đó không? Chắc chắn là không rồi! Lắp ráp một câu với các phần bạn cần để hoàn thành trải nghiệm, giống như bạn làm với một giao diện.
Giọng nói và âm điệu
Từ vựng, dấu câu, cấu trúc câu và lựa chọn từ. Đây là tất cả các thành phần của tiếng Anh. Chúng tôi sử dụng chúng để chia sẻ ý tưởng, giao tiếp với bạn bè và gia đình cũng như gửi email cho đồng nghiệp của chúng tôi.
Nhưng điều quan trọng là phải xem xét âm thanh trong số các tin nhắn của chúng tôi. Thật ngạc nhiên khi một dấu chấm than có thể thay đổi hoàn toàn giọng điệu của một tin nhắn:
- Tôi thích lập trình.
- I Lượt thích lập trình! :)
Rất dễ nhầm lẫn giữa giọng nói với âm điệu và ngược lại.
Giọng nói là những gì liên quan đến việc lựa chọn từ của chúng ta, điều này phụ thuộc vào ngữ cảnh. Ví dụ: một hướng dẫn cho người mới bắt đầu có nhiều khả năng sử dụng tiếng lóng và ngôn ngữ không chính thức để truyền đạt một giọng nói thân thiện, trong khi tài liệu hướng dẫn có thể được viết một cách trang trọng, nghiêm túc và chuyên nghiệp nhằm cố gắng đi thẳng vào vấn đề.
Cùng một thông điệp, được viết bằng hai giọng khác nhau:
- Vui vẻ: “Mở rộng mạng xã hội của bạn và cập nhật những gì đang thịnh hành hiện nay.”
- Nghiêm túc: “Tìm việc làm trên một trong những ứng dụng mạng xã hội và thị trường việc làm trực tuyến lớn nhất.”
Không có gì lạ nếu bạn vô tình viết những tin nhắn có vẻ như trịch thượng, xúc phạm và không chuyên nghiệp. Đây là đâu giai điệu đến chơi. Đọc to tin nhắn của bạn, kêu gọi người khác đọc chúng cho bạn và thử nghiệm với dấu câu và cấu trúc câu của bạn. Đó là cách bạn trau dồi giọng điệu của mình.
Đây là một cách khác để nghĩ về nó: giọng nói của bạn không bao giờ thay đổi, nhưng giọng điệu của bạn thì có. Giọng nói của bạn giống với con người của bạn, trong khi giọng điệu là cách bạn phản ứng trong một tình huống nhất định.
Giọng chủ động và bị động
Một câu luôn chứa một diễn viên, một động từ và một mục tiêu. Thứ tự mà những điều này đến xác định xem câu được viết ở giọng chủ động hay bị động.
Diễn viên về nhất trong một giọng nói tích cực. Ví dụ: “CSS vẽ nền”.
Các câu sử dụng một giọng chủ động sẽ đơn giản hơn các câu đối của chúng. Chúng rõ ràng hơn, ngắn hơn và dễ hiểu hơn - hoàn hảo cho một giọng nói chuyên nghiệp hơn đi thẳng vào vấn đề.
Với một giọng nói thụ động, diễn viên đứng sau cùng. (Xem tôi đã làm gì ở đó?) Điều đó có nghĩa là tác nhân của chúng ta - CSS trong trường hợp này - ở cuối như sau: “Nền được vẽ bởi CSS.”
Người đọc thường chuyển giọng nói thụ động sang giọng nói chủ động trong đầu, dẫn đến mất nhiều thời gian xử lý hơn. Nếu bạn đã từng nghe nói rằng viết bằng giọng chủ động sẽ tốt hơn, thì đây thường là lý do tại sao. Các nhà văn công nghệ thường thích giọng nói chủ động, với rất ít trường hợp ngoại lệ, chẳng hạn như trích dẫn nghiên cứu: “Người ta đã gợi ý rằng…”
Nhưng điều đó không có nghĩa là bạn phải luôn cố gắng để có được một tiếng nói tích cực. Chuyển từ câu này sang câu kia - thậm chí trong cùng một đoạn văn - có thể làm cho nội dung của bạn trôi chảy hơn từ câu này sang câu khác nếu được sử dụng một cách hiệu quả.
Tránh sai lầm
Ngữ pháp là tất cả về cấu trúc và tính đúng đắn của ngôn ngữ, và không có gì tốt hơn để đạt được điều đó ngoài việc đọc lại tài liệu của bạn một cách nhanh chóng. Điều rất quan trọng là loại bỏ các bài viết của bạn mắc lỗi chính tả, các vấn đề ngữ pháp và sự không hoàn hảo về ngữ nghĩa.
Ở phần cuối của bài viết này, tôi sẽ chỉ cho bạn những công cụ vô giá mà các chuyên gia sử dụng để tránh viết sai. Rõ ràng, có những công cụ kiểm tra chính tả được tích hợp sẵn trong mọi thứ ngày nay; các trình soạn thảo mã của chúng tôi thậm chí còn có các plugin kiểm tra lỗi chính tả và viết chữ để giúp ngăn ngừa sai lầm.
Nhưng nếu bạn đang tìm kiếm một công cụ toàn diện cho ngữ pháp, Grammarly là một trong những công cụ được sử dụng rộng rãi nhất. Tôi không nhận được lại quả cho điều đó hay bất cứ điều gì. Nó chỉ là một công cụ thực sự tuyệt vời mà nhiều biên tập viên và nhà văn sử dụng để viết nội dung rõ ràng và rõ ràng - tương tự như cách bạn có thể sử dụng Emmet, eslint hoặc bất kỳ trình liên kết nào khác để viết mã rõ ràng và sạch sẽ.
Viết bình luận mã
Những thứ chúng tôi viết cho các nhà phát triển khác có thể có tác động lớn đến chất lượng tổng thể công việc của chúng tôi, cho dù đó là những gì chúng tôi viết trong mã, cách chúng tôi giải thích mã hoặc cách chúng tôi đưa ra phản hồi về một đoạn mã.
Thật thú vị khi mọi ngôn ngữ lập trình đều đi kèm với một bộ tính năng tiêu chuẩn để viết bình luận. Họ nên giải thích mã đang làm gì. Bởi vậy, ý tôi không phải là những nhận xét mơ hồ như thế này:
red *= 1.2 // Multiply `red` by 1.2 and re-assign itThay vào đó, hãy sử dụng các nhận xét cung cấp thêm thông tin:
red *= 1.2 // Apply a 'reddish' effect to the imageĐó là tất cả về ngữ cảnh. "Tôi đang xây dựng loại chương trình nào?" chính xác là loại câu hỏi bạn nên tự hỏi chính mình.
Nhận xét sẽ thêm giá trị
Trước khi chúng ta xem xét điều gì tạo nên một nhận xét mã "tốt", đây là hai ví dụ về nhận xét lười biếng:
const age = 32 // Initialize `age` to 32filter: blur(32px); /* Create a blur effect with a 32px radius */Hãy nhớ rằng mục đích của một bình luận là để tăng giá trị cho một đoạn mã, không phải để lặp lại nó. Nếu bạn không thể làm điều đó, tốt hơn hết bạn nên để nguyên mã. Điều làm cho những ví dụ này trở nên “lười biếng” là chúng chỉ đơn thuần là trình bày lại những gì mã rõ ràng đang làm. Trong trường hợp này, các nhận xét là thừa vì chúng cho chúng ta biết những gì chúng ta đã biết - chúng không tăng thêm giá trị!
Nhận xét phải phản ánh mã hiện tại
Ý kiến lạc hậu không phải là điều hiếm thấy ở các dự án lớn; tôi dám nói vào hầu hết dự án.
Hãy tưởng tượng David, một lập trình viên và một anh chàng tuyệt vời để đi chơi cùng. David muốn sắp xếp một danh sách các chuỗi theo thứ tự bảng chữ cái từ A đến Z, vì vậy anh ấy thực hiện điều hiển nhiên trong JavaScript:
cities = sortWords(cities) // sort cities from A to ZSau đó, David nhận ra rằng sort AdWords () thực sự sắp xếp danh sách từ Z đến A. Đó không phải là vấn đề, vì anh ấy có thể đảo ngược đầu ra một cách đơn giản:
cities = sortWords(cities) // sort cities from A to Z
cities = reverse(cities)Thật không may, David đã không cập nhật bình luận mã của mình.
Bây giờ hãy tưởng tượng rằng tôi đã không kể cho bạn câu chuyện này, và tất cả những gì bạn thấy là đoạn mã ở trên. Bạn sẽ tự nhiên nghĩ rằng sau khi chạy dòng mã thứ hai đó, `thành phố` sẽ được sắp xếp từ Z đến A! Toàn bộ sự thất bại nhầm lẫn này là do một bình luận cũ.
Mặc dù đây có thể là một ví dụ phóng đại, nhưng điều tương tự có thể (và thường xảy ra) nếu bạn đang chạy đua với thời hạn gần kề. Rất may, điều này có thể được ngăn chặn bằng cách tuân theo một quy tắc đơn giản… thay đổi nhận xét của bạn cùng lúc bạn thay đổi mã.
Đó là một quy tắc đơn giản sẽ giúp bạn và nhóm của bạn tiết kiệm được rất nhiều nợ kỹ thuật.
Bây giờ chúng ta đã biết các nhận xét viết kém trông như thế nào, hãy cùng xem một số ví dụ điển hình.
Nhận xét phải giải thích mã đơn tự động
Đôi khi, tự nhiên cách làm không đúng. Các lập trình viên có thể phải "phá vỡ" các tiêu chuẩn một chút, nhưng khi họ làm như vậy, bạn nên để lại một chút bình luận giải thích cơ sở lý luận của họ:
function addSetEntry(set, value) {
/* Don't return `set.add` because it's not chainable in IE 11. */
set.add(value);
return set;
}Điều đó hữu ích, phải không? Nếu bạn chịu trách nhiệm xem xét mã này, bạn có thể đã bị cám dỗ để sửa nó mà không có nhận xét đó giải thích những gì đang xảy ra.
Nhận xét có thể xác định các nhiệm vụ trong tương lai
Một điều hữu ích khác đối với nhận xét là thừa nhận rằng còn nhiều việc phải làm.
// TODO: use a more efficient algorithm
linearSort(ids)Bằng cách này, bạn có thể tập trung vào luồng của mình. Và vào một ngày sau đó, bạn (hoặc người khác) có thể quay lại và sửa chữa nó.
Nhận xét có thể liên kết lại nguồn
Vì vậy, bạn vừa tìm thấy giải pháp cho vấn đề của mình trên StackOverflow. Sau khi sao chép-dán mã đó, đôi khi tốt hơn là giữ một liên kết đến câu trả lời đã giúp bạn để bạn có thể quay lại để tham khảo trong tương lai.
// Adds handling for legacy browsers
// https://stackoverflow.com/a/XXXXXXXĐiều này rất quan trọng vì các giải pháp có thể thay đổi. Luôn luôn tốt để biết mã của bạn đến từ đâu trong trường hợp nó bị hỏng.
Viết yêu cầu kéo
Yêu cầu kéo (PRs) là một khía cạnh cơ bản của bất kỳ dự án nào. Họ là trung tâm của các bài đánh giá mã. Và đánh giá mã có thể nhanh chóng trở thành một nút thắt cổ chai trong hiệu suất của nhóm của bạn nếu không có từ ngữ tốt.
Tốt PR mô tả tóm tắt gì thay đổi đang được thực hiện và tại sao nó đang được tạo ra. Các dự án lớn có mẫu yêu cầu kéo, như mẫu này được điều chỉnh từ ví dụ thực tế:
## Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request.
## Types of changes
What types of changes does your code introduce to Appium?
- [ ] Bugfix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- ...
## Checklist
- [ ] I have read the CONTRIBUTING doc
- [ ] I have signed the CLA
- [ ] Lint and unit tests pass locally with my changes
## Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc…Tránh mơ hồ PR trò chơi
Vui lòng tránh các tiêu đề trông như thế này:
- Sửa bản dựng.
- Sửa lỗi.
- Thêm bản vá.
Những thứ này thậm chí không nỗ lực để mô tả bản dựng, lỗi hoặc bản vá mà chúng tôi đang xử lý. Một chút chi tiết bổ sung về phần nào của bản dựng đã được sửa, lỗi nào đã được sửa hoặc bản vá nào được thêm vào có thể giúp bạn thiết lập giao tiếp và cộng tác tốt hơn với đồng nghiệp của mình. Nó thiết lập và thu hút mọi người trên cùng một trang.
PR tiêu đề theo truyền thống được viết bằng thì mệnh lệnh. Chúng là một bản tóm tắt một dòng của toàn bộ PRvà họ nên mô tả gì đang được thực hiện bởi PR.
Dưới đây là một số ví dụ điển hình:
- Hỗ trợ các thuộc tính srcset tùy chỉnh trong NgOptimizedImage
- Định cấu hình hình ảnh mặc định thành 75% chất lượng hình ảnh
- Thêm các bộ chọn rõ ràng cho tất cả các ControlValueAccessor được tích hợp sẵn
Tránh lâu PRs
Một cái lớn PR có nghĩa là một mô tả khổng lồ, và không ai muốn xem lại hàng trăm hoặc hàng nghìn dòng mã, đôi khi chỉ để kết thúc việc loại bỏ toàn bộ!
Thay vào đó, bạn có thể:
- giao tiếp với nhóm của bạn thông qua Các vấn đề,
- lên kế hoạch,
- chia nhỏ vấn đề thành nhiều phần nhỏ hơn, hoặc
- làm việc trên từng phần riêng biệt với của riêng nó PR.
Bây giờ nó không sạch hơn nhiều sao?
Cung cấp thông tin chi tiết trong PR thân hình
Không giống như các PR tiêu đề, cơ thể là các nơi cho tất cả các chi tiết, bao gồm:
- Tại sao vậy PR đang được thực hiện?
- Tại sao đây là cách tiếp cận tốt nhất?
- Bất kỳ thiếu sót nào đối với cách tiếp cận và ý tưởng để giải quyết chúng nếu có thể
- Lỗi hoặc số vé, kết quả điểm chuẩn, v.v.
Báo cáo lỗi
Báo cáo lỗi là một trong những khía cạnh quan trọng nhất của bất kỳ dự án nào. Và tất cả các dự án tuyệt vời đều được xây dựng dựa trên phản hồi của người dùng. Thông thường, ngay cả sau vô số thử nghiệm, chính người dùng là người tìm ra nhiều lỗi nhất. Người dùng cũng là những người theo chủ nghĩa lý tưởng tuyệt vời, và đôi khi họ có những ý tưởng về tính năng; hãy lắng nghe họ!
Đối với các dự án kỹ thuật, tất cả những thứ này được thực hiện bằng cách báo cáo các vấn đề. Một nhà phát triển khác có thể dễ dàng tìm thấy và phản hồi một vấn đề được viết tốt.
Ví dụ, hầu hết các dự án lớn đều có một mẫu:
<!-- Modified from angular-translate/angular-translate -->
### Subject of the issue
Describe your issue here.
### Your environment
* version of angular-translate
* version of angular
* which browser and its version
### Steps to reproduce
Tell us how to reproduce this issue.
### Expected behavior
Tell us what should happen.
### Actual behavior
Tell us what happens instead.Thu thập ảnh chụp màn hình
Nắm bắt vấn đề bằng cách sử dụng tiện ích chụp ảnh màn hình của hệ thống.
Nếu đó là ảnh chụp màn hình của một CLI hãy đảm bảo rằng văn bản rõ ràng. Nếu đó là một UI chương trình, đảm bảo rằng ảnh chụp màn hình chụp đúng các yếu tố và trạng thái.
Bạn có thể cần phải nắm bắt một tương tác thực tế để chứng minh vấn đề. Nếu đúng như vậy, hãy cố gắng ghi ảnh GIF bằng công cụ quay phim màn hình.
Làm thế nào để tái tạo vấn đề
Các lập trình viên giải quyết một lỗi dễ dàng hơn nhiều khi nó xuất hiện trên máy tính của họ. Đó là lý do tại sao một cam kết tốt nên đi kèm với các bước để tái tạo chính xác vấn đề.
Dưới đây là một ví dụ:
Update: you can actually reproduce this error with objects:
```html
<div *ngFor="let value of objs; let i = index">
<input [ngModel]="objs[i].v" (ngModelChange)="setObj(i, $event)" />
</div>
```
```js
export class OneComponent {
obj = {v: '0'};
objs = [this.obj, this.obj, this.obj, this.obj];
setObj(i: number, value: string) {
this.objs[i] = {v: value};
}
}
```
The bug is reproducible as long as the trackBy function returns the same value for any two entries in the array. So weird behavior can occur with any duplicate values.
Đề xuất nguyên nhân
Bạn là người đã bắt được lỗi, vì vậy có thể bạn có thể đề xuất một số nguyên nhân tiềm ẩn cho việc tại sao nó ở đó. Có thể lỗi chỉ xảy ra sau khi bạn gặp một sự kiện nào đó, hoặc có thể nó chỉ xảy ra trên thiết bị di động.
Việc khám phá cơ sở mã cũng không gây hại gì và có thể xác định nguyên nhân gây ra sự cố. Sau đó, Vấn đề của bạn sẽ được đóng nhanh hơn nhiều và bạn có khả năng được chỉ định cho việc liên quan PR.
Giao tiếp với khách hàng
Bạn có thể làm việc với tư cách là một freelancer đơn lẻ, hoặc có thể bạn là nhà phát triển chính trong một nhóm nhỏ. Trong cả hai trường hợp, giả sử bạn chịu trách nhiệm giao tiếp với khách hàng trong một dự án.
Bây giờ, định kiến của các lập trình viên là chúng ta là những người giao tiếp kém. Chúng tôi đã được biết là sử dụng biệt ngữ kỹ thuật quá mức, nói cho người khác biết điều gì được và không được, và thậm chí có thái độ phòng thủ khi ai đó đặt câu hỏi về cách tiếp cận của chúng tôi.
Vì vậy, làm thế nào để chúng ta giảm thiểu định kiến đó? Hỏi khách hàng xem họ muốn gì và luôn lắng nghe phản hồi của họ. Đây là cách để làm điều đó.
Đặt câu hỏi đúng
Bắt đầu bằng cách đảm bảo rằng bạn và khách hàng đang ở trên cùng một trang:
- đối tượng mục tiêu của bạn là ai?
- Mục tiêu của trang web là gì?
- Đối thủ cạnh tranh gần nhất của bạn là ai và họ đang làm gì đúng?
Đặt câu hỏi cũng là một cách tốt để viết một cách tích cực, đặc biệt là trong các tình huống khi bạn không đồng ý với phản hồi hoặc quyết định của khách hàng. Đặt câu hỏi buộc người đó phải ủng hộ những tuyên bố của họ thay vì bạn tấn công họ bằng cách bảo vệ lập trường của chính bạn:
- Bạn có đồng ý với điều đó ngay cả khi nó đi kèm với một chi phí hiệu suất bổ sung?
- Việc di chuyển thành phần có giúp chúng ta hoàn thành mục tiêu tốt hơn không?
- Tuyệt vời, ai chịu trách nhiệm duy trì điều đó sau khi ra mắt?
- Bạn có biết độ tương phản giữa hai màu đó có vượt qua tiêu chuẩn WCAG AA không?
Các câu hỏi ngây thơ hơn rất nhiều và thúc đẩy sự tò mò hơn là thù địch.
Bán mình
Nếu bạn đang chào hàng với một khách hàng tiềm năng, bạn sẽ cần thuyết phục họ thuê bạn. Tại sao khách hàng nên chọn bạn? Điều quan trọng là phải xác định những điều sau:
- Bạn là ai
- Điêu bạn lam
- Tại sao bạn phù hợp với công việc
- Liên kết đến công việc có liên quan mà bạn đã làm
Và một khi bạn nhận được công việc và cần phải viết hợp đồng, hãy nhớ rằng không có nội dung nào đáng sợ hơn một loạt các bản hợp đồng. Mặc dù nó được viết cho các dự án thiết kế, Kẻ giết người thuê có thể là một điểm khởi đầu tốt đẹp để viết một cái gì đó thân thiện hơn nhiều.
Sự chú ý của bạn đến từng chi tiết có thể là sự khác biệt giữa bạn và một nhà phát triển khác đang cố gắng giành được cùng một dự án. Theo kinh nghiệm của tôi, khách hàng sẽ dễ dàng thuê một nhân viên phát triển mà họ nghĩ rằng họ sẽ thích làm việc hơn so với người có kỹ thuật hoặc kinh nghiệm nhất đối với công việc.
Viết kính hiển vi
Kính hiển vi là nghệ thuật viết thân thiện với người dùng UI thông báo, chẳng hạn như lỗi. Tôi cá là đã có lúc bạn với tư cách là một nhà phát triển phải viết các thông báo lỗi vì chúng đã được đặt trên tất cả các cách để khởi chạy.
Đó có thể là lý do tại sao đôi khi chúng tôi gặp các lỗi như thế này:
Error: Unexpected input (Code 693)Lỗi là điều cuối cùng bạn muốn người dùng của mình giải quyết. Nhưng chúng vẫn xảy ra, và chúng ta không thể làm gì được. Dưới đây là một số mẹo để cải thiện kỹ năng soi kính hiển vi của bạn.
Tránh biệt ngữ kỹ thuật
Hầu hết mọi người không biết máy chủ là gì, trong khi 100% lập trình viên đều biết. Đó là lý do tại sao không có gì lạ khi thấy các thuật ngữ không phổ biến được viết trong một thông báo lỗi, như API hoặc "thực thi hết thời gian chờ".
Trừ khi bạn đang giao dịch với khách hàng kỹ thuật hoặc cơ sở người dùng, có khả năng là hầu hết người dùng của bạn không tham gia khóa học khoa học máy tính và không biết Internet hoạt động như thế nào và tại sao một thứ cụ thể không hoạt động. Do đó, lỗi.
Do đó, một thông báo lỗi tốt không nên giải thích tại sao đã xảy ra lỗi, bởi vì những giải thích như vậy có thể yêu cầu sử dụng các thuật ngữ kỹ thuật đáng sợ. Đó là lý do tại sao điều rất quan trọng là tránh sử dụng biệt ngữ kỹ thuật.
Đừng bao giờ đổ lỗi cho người dùng
Hãy tưởng tượng điều này: Tôi đang cố gắng đăng nhập vào nền tảng của bạn. Vì vậy, tôi mở trình duyệt của mình, truy cập trang web của bạn và nhập thông tin chi tiết của tôi. Sau đó, tôi được thông báo: "Email / mật khẩu của bạn không chính xác."
Mặc dù có vẻ kịch tính khi nghĩ rằng tin nhắn này là thù địch, nhưng trong tiềm thức nó khiến tôi cảm thấy mình thật ngu ngốc. Microcopy nói rằng không bao giờ được phép đổ lỗi cho người dùng. Hãy thử thay đổi thư của bạn thành một thứ gì đó ít đầu ngón tay hơn, như ví dụ này được phỏng theo thông tin đăng nhập của Mailchimp: “Xin lỗi, sự kết hợp email-mật khẩu đó không đúng. Chúng tôi có thể giúp bạn khôi phục tài khoản của mình ”.
Tôi cũng muốn nói thêm tầm quan trọng của việc tránh TẤT CẢ CHỮ HOA và dấu chấm than! Chắc chắn, chúng có thể được sử dụng để truyền đạt sự phấn khích, nhưng trong kính hiển vi, chúng tạo ra cảm giác thù địch đối với người dùng.
Đừng làm người dùng choáng ngợp
Sử dụng sự hài hước trong kính hiển vi của bạn là một ý kiến hay! Nó có thể giúp tâm trạng nhẹ nhàng hơn và là một cách dễ dàng để hạn chế sự tiêu cực do những lỗi thậm chí là tồi tệ nhất gây ra.
Nhưng nếu bạn không sử dụng nó hoàn hảo, nó có thể bị coi là hạ mình và xúc phạm người dùng. Đó chỉ là một to rủi ro để chấp nhận.
[D] đừng cố gắng pha trò - sự hài hước gượng ép có thể tệ hơn không chút nào. Nếu bạn không chắc chắn, hãy giữ một khuôn mặt thẳng thắn.
(Tôi nhấn mạnh)
Viết đánh dấu có thể truy cập
Chúng tôi có thể dễ dàng dành toàn bộ một bài báo về khả năng tiếp cận và cách nó liên quan đến kỹ thuật viết. Rất tiếc, khả năng tiếp cận thường được bao gồm trong các hướng dẫn phong cách nội dung, bao gồm cả những hướng dẫn dành cho microsoft và Mailchimp.
Bạn là một nhà phát triển và có thể đã biết rất nhiều về khả năng tiếp cận. Bạn thậm chí có thể là một trong những nhà phát triển siêng năng hơn khiến khả năng tiếp cận trở thành một phần cốt lõi trong quy trình làm việc của bạn. Tuy nhiên, thật không thể tin được là tần suất các cân nhắc về khả năng tiếp cận được đặt lên hàng đầu, cho dù tất cả chúng ta đều biết tầm quan trọng của nó là tạo ra những trải nghiệm trực tuyến có thể truy cập bao gồm tất cả các khả năng.
Vì vậy, nếu bạn thấy mình đang triển khai copywriting của người khác vào mã của bạn, viết tài liệu cho các nhà phát triển khác hoặc thậm chí viết UI sao chép bản thân, lưu ý đến một số phương pháp hay nhất về khả năng tiếp cận cơ bản, vì chúng làm tròn tất cả các lời khuyên khác cho việc viết kỹ thuật.
Những thứ như:
Andy Bell cung cấp một số tương đối những việc nhỏ bạn có thể làm để giúp nội dung dễ tiếp cận hơnvà rất đáng để bạn dành thời gian kiểm tra chúng. Và, chỉ dành cho những cú đá, John Rhea thể hiện một số thủ thuật chỉnh sửa gọn gàng điều đó có thể thực hiện được khi chúng tôi đang làm việc với các phần tử HTML ngữ nghĩa.
Kết luận
Đó là sáu cách chứng minh cách viết và phát triển kỹ thuật trùng khớp với nhau. Mặc dù các ví dụ và lời khuyên có thể không phải là khoa học tên lửa, nhưng tôi hy vọng rằng bạn thấy chúng hữu ích, cho dù đó là cộng tác với các nhà phát triển khác, duy trì công việc của riêng bạn, phải viết bản sao của riêng bạn trong một nhúm, hoặc thậm chí soạn thảo một đề xuất dự án, trong số đó nhiều thứ.
Điểm mấu chốt: trau dồi kỹ năng viết của bạn và nỗ lực thêm một chút vào bài viết của bạn thực sự có thể khiến bạn trở thành một nhà phát triển tốt hơn.
Tài nguyên kỹ thuật viết
Nếu bạn quan tâm đến kỹ thuật viết:
Nếu bạn quan tâm đến copywriting:
Nếu bạn quan tâm đến kính hiển vi:
Nếu bạn quan tâm đến việc sử dụng hướng dẫn văn phong chuyên nghiệp để cải thiện bài viết của mình:
Nếu bạn quan tâm đến việc viết cho khả năng tiếp cận:
