Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 35
«Удалять мертвый/закомментированный код»
Я даже научился удовольствие от такого получать. Этот как ранку засохшую ковырять, когда не больно.
Я даже научился удовольствие от такого получать. Этот как ранку засохшую ковырять, когда не больно.
Разработчики ленивы и часто слишком засиживаются на своих «старых-добрых» технологиях.
А мне казалось что как раз благодаря своей лени я изучаю новые технологии, чтобы не делать много однотипных вещей приходится как-то выкручиваться и все автоматизировать.
Проблема в том, что новые технологии появляются сейчас чаще, чем завершается цикл разработки проекта. Есть шанс уйти в бесконечный цикл разработки )
Ну если только ради автоматизации рутинных задач то думаю ничего страшного не произойдет, а если ради новшеств то да, можно будет долго так метаться между все более новыми технологиями.
Вспоминается истории одного аспиранта который писал работу по IP телефонии 8 лет потому что как только часть напишет то выходит что-то новое и интересное, и так по кругу…
Вспоминается истории одного аспиранта который писал работу по IP телефонии 8 лет потому что как только часть напишет то выходит что-то новое и интересное, и так по кругу…
Есть хорошее правило: не более одной-двух новых технологий в новом проекте.
Пункты про боязнь изменения кода и нестабильность сильно перекликаются. Перекликаются они в одном: тесты. Код покрыт тестами — менять не страшно. Код покрыт тестами — ты уверен в его стабильном поведении. Если же тестов нет, приходится бояться и изменений, и нестабильности. Пишите тесты, господа!
А если тест не все варианты покрывает, ну мало ли о чем думал разработчик, то ему станет весело :)
Пишу тесты примерно пять лет. Последние два работаю в основном по TDD. И за это время было так много косяков и аномального поведения систем, что уже давно сбился со счёта.
К тому же тесты не везде применимы и порой их реализация неоправданна. На пример в embedded программах тестирование порой просто невозможно из-за нехватки памяти в устройстве.
К тому же тесты не везде применимы и порой их реализация неоправданна. На пример в embedded программах тестирование порой просто невозможно из-за нехватки памяти в устройстве.
А я сейчас как раз пишу тестирование embedded системы. Причем командами по USB с PC. Тестирую я не все, но тесты мне нужны для того чтобы иметь возможность сменить некоторые части системы и убедиться что все работает.
Это уже тестирование на другом уровне. Обычно его называют Smoke testing, подразумевая, что оно заменяет или дополняет QA работников. Но суть в том, что вы тестируете систему в целом из вне.
Вау :) Круть :) не знал.
Но вообще говоря тестируем мы не то, что может проверить человек без отладки. Поэтому автоматический тест и стали писать.
Например, по USB в устройство отправляются команды, а если они уходя слишком часто — устройство не успевает их обрабатывать и они остаются без ответа или вовсе теряются. Тут мы должны посмотреть сколько пакетов устройство успевает обрабатывать (а-ля анализ размера буфера), нужно посмотреть не придут ли лишние ответы, не уйдут ли лишние запросы и т.п.
Но вообще говоря тестируем мы не то, что может проверить человек без отладки. Поэтому автоматический тест и стали писать.
Например, по USB в устройство отправляются команды, а если они уходя слишком часто — устройство не успевает их обрабатывать и они остаются без ответа или вовсе теряются. Тут мы должны посмотреть сколько пакетов устройство успевает обрабатывать (а-ля анализ размера буфера), нужно посмотреть не придут ли лишние ответы, не уйдут ли лишние запросы и т.п.
Попытка абстрагировать опыт в термины, для выделения рецепта волшебной палочки) Оно одновременно так, и нихрена не так) У каждого опыт рождает свою матрицу ощущений. Вот нами делятся… с ней можно соглашаться или нет… просто знайте что если слова зазвенят — это ваше.
Потом из таких звоночков складывается система мышления и надеюсь это поможет нашим животам все же не набирать вес а код улучшится)
Потом из таких звоночков складывается система мышления и надеюсь это поможет нашим животам все же не набирать вес а код улучшится)
> Если кажется что технология или фреймворк полностью соответствует вашим нуждам, попробуйте.
Да, пока все эти горы фреймворков/технологий попробуешь (чтобы понять что точно подходит) — пол жизни уйдет, да и сами фреймворки/технологии устареют. Пробовать что-то новое стоит только на досуге или когда старое уже не дает требуемых возможностей. Всё остальное — баловство и бесконечная и бессмысленная гонка за новыми версиями.
Да, пока все эти горы фреймворков/технологий попробуешь (чтобы понять что точно подходит) — пол жизни уйдет, да и сами фреймворки/технологии устареют. Пробовать что-то новое стоит только на досуге или когда старое уже не дает требуемых возможностей. Всё остальное — баловство и бесконечная и бессмысленная гонка за новыми версиями.
Бояться удалять старый код? Да это самая приятная вещь на свете!
> Что ж, тогда это, возможно, не совсем подходящая для вас работа.
Ой как он не по-русски (еще бы) написал. Код некрасивый? РАБОТАЙ! СТАРАЙСЯ! ПОВЫШАЙ УРОВЕНЬ!
Хотя бы до того уровня, чтобы самому нравилось. Нравится себе — с окружающими будешь говорить не с позиции «я сирый и убогий».
А вот потом уже (без оговорок) и решай, «подходящая ли это для вас работа».
Ой как он не по-русски (еще бы) написал. Код некрасивый? РАБОТАЙ! СТАРАЙСЯ! ПОВЫШАЙ УРОВЕНЬ!
Хотя бы до того уровня, чтобы самому нравилось. Нравится себе — с окружающими будешь говорить не с позиции «я сирый и убогий».
А вот потом уже (без оговорок) и решай, «подходящая ли это для вас работа».
>8 вещей, которых не должен бояться разработчик
а должен бояться менеджер =)
а должен бояться менеджер =)
От себя добавлю – разработчик не должен бояться создавать новые файлы, вынося код в отдельные классы. По моим наблюдениям, в проектах на Rails многие новички страдают этой фобией. Причины тому, чаще всего, несовершенное владение средствами редактора по быстрому поиску файлов в проекте и нежелание «загромождать проект» файлами длинною всего в несколько строк.
Удалять мертвый/закомментированный код
Когда правишь не свой код или нет достаточного покрытия тестами сложной системы, где есть кандидат в такой код… черт реально стремно!
Что же стремного в удалении чужого закомментированного кода? А под мертвым кодом, я думаю, имелся в виду код, который вообще не вызывается. Опять же — что тут стремного? Такое обычно бояться удалять по причине «а вдруг пригодится», но, как верно указал автор статьи, система контроля версий похранит все за вас.
А вот рефакторинг и изменение чужого кода с непокрытыми тестами — это да…
А вот рефакторинг и изменение чужого кода с непокрытыми тестами — это да…
Отлично, спасибо!
Отправил ссылку коллегам.
Отправил ссылку коллегам.
«Сталкиваться с неудачами» — напомнило историю одного байта :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
8 вещей, которых не должен бояться разработчик