Жизнь разработчика непростая. Мы живем двойной жизнью, разрываясь между идеалистическими идеями (тупица?) О первоклассном качестве программного обеспечения и, ну, в общем, жизнью; сроки, резкие углы и написание программного обеспечения без единого теста. Я знаю, знаю, но открой свои кровоточащие уши, это правда - твой кодекс никогда не будет идеальным, потому что обстоятельства никогда не будут идеальными. Но вот что вы можете и определенно должны сделать, чтобы сделать свою жизнь разработчика лучше и проще для тех (будущее, которое вы тоже учитываете), кто будет работать над вашим кодом после вас.
Вы когда-нибудь работали над фрагментом кода, который не могли понять, и после часа попыток понять, что, черт возьми, происходит, вы заходили в свой VSC и нажимали Git Blame, и вы были похожи на я клянусь, кто бы ни написал этот код…
Ага. Звучит знакомо?
- Задокументируйте свой код
У других людей нет такого же контекста, как у вас. Это может быть так же просто, как правильно назвать переменные, чтобы ваш код был понятным без пояснений. Не используйте загадочные сокращения; переименуйте этот getA в getActiveLayer - вы можете быть удивлены, насколько он вводит в заблуждение.
Просмотрите свой файл README. Когда на борт приходит новый человек, вы хотите, чтобы для нее все было гладко. Вы же не хотите, чтобы в первый день она тратила драгоценное время на борьбу с такой простой задачей, как создание проекта. Вы тот новичок, и некоторые вещи в README устарели? Выпейте трав, проглотите свое разочарование и ИСПРАВИТЕ ЭТО. Помните, что лучший способ научить других хорошему опыту - это подавать пример самому.
2. Не доверяйте серверу
… Или что-нибудь, что поступает извне в ваш блестящий компонент. Проверяйте наличие нулей, реализуйте резервные варианты на предмет потенциальных ошибок или несуществующих данных. Меня не волнует, что API обещал дать такие результаты; в противном случае произойдет сбой именно вашей страницы.
3. Сообщайте о решениях
Или лучше. Включите свою команду, чтобы объединить их. Вы только начинаете новый проект и думаете, какое решение для маршрутизации использовать. Или подумайте об идеальном потоке git для вашего случая использования. Четко излагайте свои мысли и предположения, но будьте открыты для предложений других людей. Не оставляйте это вне обсуждения и молчите; вы запутаете младших разработчиков, а для них это прекрасная возможность узнать, как вы принимаете решения. И мало ли, другие могут удивить вас лучшим решением проблемы. Как только вы все согласитесь, переходите к шагу 1 и задокументируйте это для будущих разработчиков.
4. Честно оценивайте
Привет. Я был здесь. Приближается крайний срок, и вы хотите с ним покончить. Но это вы тут же врете себе. Оценки сложны, поэтому не усложняйте их, предполагая лучший сценарий. Вы могли подумать, что это раскрывающееся меню выглядит довольно просто; вы использовали его тысячу раз раньше и реализовали его, ну, немного реже. Но учли ли вы анализ данных, который входит в эту задачу? Кстати, вы знаете, что серверная часть еще не готова, верно? И вы помните, что бэкэнд-инженеры злы и не собираются служить вам в том формате, который вы хотели бы иметь, да? Если вы решили, что будете использовать библиотеку для написания этого раскрывающегося компонента, проверили ли вы, как изменить стили CSS по умолчанию? Как можно добавить недостающие функции? Стоит ли вообще использовать эту внешнюю библиотеку или лучше написать свою собственную? Подумайте обо всех этих случаях при оценке задач. Убедил ли я вас вычеркнуть те 4 часа, о которых вы изначально думали?
5. Подробно опишите свои PR.
Может быть, если вы читаете мысли, вы знаете, что собираетесь рецензировать. Я сомневаюсь, что этому человеку придется сидеть с вами в одной комнате, а вы должны быть ведьмой 17 века. Чем больше информации и контекста вы дадите о своем PR, тем лучше; напишите о введенной вами бизнес-логике и о том, что вам пришлось использовать CSS! important, потому что вы используете стороннюю библиотеку - вы сэкономите свое время и время рецензента, упрекая вас в этом! important и вы объясните, почему вам пришлось его использовать. Перед тем, как открыть запрос на перенос; дайте дополнительную прокрутку для просмотра внесенных вами изменений. Возможно, вы забыли удалить этот console.log или оставили магическое число.
6. Поднимайте при подъеме
Если у вас уже есть несколько лет опыта, вы, возможно, не помните, как трудно было, когда вы были младшим разработчиком (zapomniał wół jak cielęciem był). Имейте в виду, что вы также можете быть младшим в том, с чем еще не сталкивались. У всех нас бывают такие моменты хотя бы пару раз в день. Наставник других; объясните, почему вы поступили именно так. Придумайте новые метафоры для этой функции reduce. Проведите сеанс парного программирования. Подайте руку время от времени. Предложите кому-нибудь провести эту встречу. Будьте добры в процессе и будьте скромными, никто не любит снисходительных людей.
Я обещал 20 вещей, но здесь у вас 6. Вероятно, вы уже жестко запрограммировали 20 элементов, а теперь у вас 14 undefined. Хорошо, не доверяйте серверу и следите за новостями 📻 🙌
