README. Суровые реалии разработчиков
Қосымшада ыңғайлырақҚосымшаны жүктеуге арналған QRRuStore · Samsung Galaxy Store
Huawei AppGallery · Xiaomi GetApps

автордың кітабынан сөз тіркестері  README. Суровые реалии разработчиков

Полная уверенность в чем-то — явный признак недостаточной компетентности в соответствующей области.
4 Ұнайды
Комментарий жазу
Александр Ф.
Александр Ф.дәйексөз келтірді1 жыл бұрын
гласит закон Каннингема, «лучший способ получить правильный ответ в интернете — это не задать вопрос, а опубликовать неверный ответ».
3 Ұнайды
Комментарий жазу
Artanias
Artaniasдәйексөз келтірді2 жыл бұрын
Все инженеры должны научиться правильно задавать вопросы. Новички обычно боятся лишний раз побеспокоить коллег и пытаются разобраться во всем самостоятельно, что негативно сказывается на скорости и эффективности работы. Правильные вопросы помогут вам учиться быстро, не раздражая окружающих. Для этого нужно провести исследование, четко сформулировать вопрос и выбрать подходящее время, чтобы его задать.
3 Ұнайды
Комментарий жазу
1 Майкл К. Физерс предлагает следующие этапы безопасного изменения существующих кодовых баз. 1. Определение точек изменения. 2. Нахождение тестовых точек. 3. Разрывание зависимостей. 4. Написание тестов. 5. Внесение изменений и рефакторинг кода.
Комментарий жазу
Рефакторинг, то есть улучшение внутренней структуры кода без изменения его функциональности, производится при добавлении функции: таким образом упрощается ее внедрение. Удаление кода имеет место во время исправления ошибки.
Комментарий жазу
При внесении изменений нельзя нарушать существующее поведение программы. Вы должны понимать ход мыслей других разработчиков, придерживаться существующих стилей и шаблонов
Комментарий жазу
Если у вас есть предложения, касающиеся масштабного рефакторинга или переписывания кода, обсудите их со своей командой, используя такую последовательность действий. 1. Изложите ситуацию, опираясь на факты. 2. Оцените степень риска и стоимость долга. 3. Предложите решение. 4. Обсудите альтернативы (включая бездействие). 5. Взвесьте компромиссы. Изложите предложение в письменной форме. Не основывайте свою позицию на оценочном суждении («этот код является устаревшим и плохо написанным»). Сосредоточьтесь на стоимости долга и выгоде, связанной с его выплатой. Будьте конкретны и не удивляйтесь, если вас попросят продемонстрировать обещанные преимущества после завершения работы.
Комментарий жазу
Не ждите конца света, чтобы исправить проблемы, возникшие в течение месяца. Вместо этого старайтесь приводить код в порядок прямо по ходу работы, выполняя мелкий рефакторинг
Комментарий жазу
Может оказаться, что постепенного рефакторинга недостаточно и необходимы более значительные изменения. Масштабный рефакторинг — это серьезное обязательство. В краткосрочной перспективе погашение технического долга замедляет внедрение новых функций, в то время как увеличение размера долга ускоряет этот процесс. В долгосрочной перспективе верно обратное: выплата долга ускоряет внедрение новых функций, а увеличение размера долга его замедляет. Продакт-менеджеры заинтересованы в разработке большего количества функций (что ведет к увеличению размера технического долга).
Комментарий жазу
Хорошей практикой является проведение ретроспективы проектов, что позволяет команде обнаруживать такой неумышленный долг и решать, когда его погашать и стоит ли это делать. Важный вывод заключается в том, что возникновение некоторого долга неизбежно, поскольку неумышленные ошибки невозможно предотвратить. Кроме того, технический долг может быть признаком успеха и свидетельствовать о том, что проект просуществовал достаточно долго для возникновения в нем беспорядка.
Комментарий жазу