Стоит почаще задаваться вопросом «чтобы что?», чтобы избегать многих описанных ловушек.
Перед написанием комментария. Перед тем, как поставить смайлик в тексте.
Перед тем, как отправить уже написанный текст.
Перед тем, как вообще начать тратить время на что-то, что отнимет у вас более 10 секунд.
Интернет стал бы намного чище от этого. Но увы.
Вы представьте на секунду, что вам аппендицит удаляет стажёр. Под надзором опытного хирурга.
Всё еще считаете, что «неопытному специалисту» можно что-то прощать?
Я могу согласиться с тем, что в ревью, которое более опытный разработчик делает на код менее опытного, он должен стараться нести конструктив, поясняя суть своих замечаний, предлагая варианты решений и т.п.
Но снижать планку требований? Да с каких это вдруг таких заслуг? Не можешь тянуть лямку такого проекта — работай над проектами попроще.
Это я говорю, как человек, поработавший более, чем с десятком «младших» коллег, но и неоднократно потрудившийся «ведомым».
На свой собственный код, кстати, я давно привык делать ревью ещё до пуша, в gitk-е. Последний у меня запускается автоматически скриптом при ежедневном начале работы над проектом.
Вы поинтересуйтесь, ради расширения кругозора, как оно в других профессиях происходит. Попробуйте, например, рулём покрутить, раскатывая по городу вместе с инструктором по вождению, сварщику с десятилетним стажем порассказывать, что нужно делать, чтобы электрод не залипал, или токарю шестого разряда разъяснить, какой резец выбрать.
Начинающие водители грузовиков, например, очень часто игнорируют советы старших товарищей снимать обручальное кольцо перед работой. А потом ломают пальцы или сдирают кожу. Иногда вместе с мясом.
Потому что опыт — он в любой профессии опыт. Он не является неким абсолютным мерилом всего, но всё равно крайне важен при оценке авторитетности мнения.
Если для вас требовать от нового члена команды соответствовать стандартам, в этой команде принятой — это дедовщина, то тут и обсуждать нечего, мы в разных плоскостях работаем.
Самые лучшие проекты, как мне кажется, вот так вот и вырастают, когда мы делаем вещи, которых нам не хватает 8)
Зарегистрировался у вас и залил своё резюме. Желаю удачи с проектом!
Не важно же кто прав или не прав, проблема в том, что два человека в команде не смогли договориться и тратят свои сили не туда
Или я как-то непонятно изъясняюсь, или вы странно меня читаете.
Я как раз предлагаю тратить ресурсы не вникуда, а на полезную деятельность.
И зачем вы продолжаете приписывать мне то, чего я не говорил. Где я предлагаю «силовое решение»?
Вот у нас с вами происходит то же самое, что у персонажей заметки.
Так что давайте я вам на живом примере и поясню, что я имею ввиду, поставив в этом споре точку. Вот она:.
Самые ужасные проекты (в первую очередь с точки зрения бизнеса), за которыми мне удавалось наблюдать, почему-то велись адептами «идеального» кода, серебряных пуль, патернов и принципов
Вот вы взяли и навесили мне ярлык. А я разве где-то говорил про идеальный код? Я говорю о том, что во главе угла должна стоять задача, а не умащивание нежных чувств отдельных членов команды. Если человек пишет говнокод — значит он должен его исправить. Если я вижу, как его исправить с уровня F (в системе координат автора статьи) до уровня A, то почему мы должны остановиться на D? Нет, если переход на A требует неадекватных затрат времени, то мы можем остановиться и на B. Но почему D? Просто потому что автор кода — эмоциональная девушка, не желающая уступать?
но вот ни разу не наблюдал, чтобы люди умеющие договариваться создавли такой адЪ
Во-первых, если вы чего-то не наблюдали лично — то этого не существует?
Во-вторых — вы так говорите, словно я ратую за то, что договариваться ни в коем случае нельзя. Я лишь говорю о том, что работа не должна превращаться в бесконечные переговоры. Если два разработчика упёрлись рогом на код ревью — они оба неправы, какова бы ни была их квалификация.
Т.е. сознательно ухудшить продукт, просто чтобы подыграть чувствам коллеги?
> и убедить внести правки
Вот здесь — да. Но я сам неоднократно сталкивался с тем, что менее опытные коллеги упираются рогом просто потому, что не понимают сути моих претензий.
Я в таких случаях рогом в ответ не упираюсь. Не нравится моя оценка — либо докажи мне, что я неправ, либо мёрджи без моего подтверждения, а потом сам объясняйся с руководством, почему ты так сделал. Я больше на это своё время тратить не буду. Sapienti sat.
lpwaterhouse правильно говорит.
В коде тоже довольно легко формализовать оценку отдельно взятого фрагмента.
Например, если я в ревью придираюсь к тому, соответствует ли код стандартам PEP-8 — то это означает, что у нас заранее было оговорено, что мы придерживаемся PEP-8.
Если то, как предлагаю сделать я — быстрее/безопаснее/надёжнее/читабельнее, и я могу это доказать — значит так и надо делать. Если мне, при ревью моего кода, аргументированно такое доказывают — я не упираюсь рогом и не трачу время ни ревьювера, ни своё, ни кого-либо ещё из команды. Это то, что я считаю профессионализмом. Формулируя чуть короче — профессионализм, это когда стараешься делать своё дело лучше и быстрее, избавляясь от того, что тебя сдерживает.
А заниматься выстраиванием отношений в команде вместо работы над продуктом — это хипстерская херня. Да, коммуникация важна. Да отношения с коллегами надо поддерживать.
Но всё это не должно быть самоцелью, мы здесь работать собрались, а не играть клуб анонимных алкоголиков.
Сейчас в среде разработчиков принято называть «суперзвёздами» или «рок-звёздами» тех, кто кроме своего эго ничего не видят, не умеют делегировать, и, в результате всего этого — замедляют работу над продуктом, а не ускоряют. И, в итоге, сгорают сами.
Я считаю, это неправильно.
Те, кто выгорел — это не суперзвёзды. Настоящие суперзвёзды, как Линус Торвальдс, год за годом локомотивом пробивают пробивают дорогу не только себе, но и другим.
Занятная статья.
Я сам делал очень похожее несколько лет назад. Устройством, правда, был не роутер, а две Nanostation Loco M5, собранные в мост. Мне нужно было выводить уровень сигнала и скорость линка в дашборд, и я сделал примерно так же — питоноскрипты, ползающие по вебу.
Пара замечаний(было больше, но про девтулс уже написали 8):
Код. Он ужасен. Функции, возвращающие либо строку с ошибкой, либо id, break после return и прочее. Однако, добавлю конструктива — если вам не пофиг, то по качеству кода я могу накидать замечаний в гитхаб или какой-то другой сервис, если код вы выложите туда.
Вы ошибаетесь, считая, что не храните пароль в открытом виде. То есть, сам-то пароль, конечно, да. Но у вас в открытом виде лежит строка, которая позволяет авторизоваться на веб-интерфейсе роутера. Это не то, чтобы плохо — вам в любом случае пришлось бы либо хранить что-то, либо требовать ввода от пользователя, я лишь хочу указать на ошибку в тексте.
Спасибо за заметку.
У меня тут как раз Raspberry PI(правда, постарше, вторая ещё) висит, на которую заведены и видеонаблюдение, и сбор данных с нескольких датчиков температуры/влажности, раскиданных по дому, и скоро должен приехать пучок релюшек Sonoff для управления светом и прочими
Я как раз подумывал ко всему этому прикрутить телеграм-бота, а тут ваша статья.
Правда, касательно самого видеонаблюдения, у меня всё несколько сложнее, потому что частный дом, камера не одна, а уже 4(и будет больше), и все они смотрят на улицу. Через это в моем случае рациональнее оказалось ставить железный видеорегистратор, который сам умеет следить за движением и отправлять сообщения по почте.
Другое дело, что с учетом того, что камеры уличные, лог сработок на шкале времени выглядит примерно вот так:
И это ещё не самый "активный" день.
С одной стороны — все эти сработки неплохо иметь в архиве, чтобы, например, во время отпуска можно было вечером за небольшое время посмотреть "ретроспективу" за день. С другой стороны — если каждую сработку показывать в телеграме, то поток сообщений будет слишком густым и малополезным.
Поэтому я пока ещё работаю над всем этим и думаю, как сделать правильнее. Пока видятся два возможных пути — либо прикручивать второй слой анализа картинок(например, ZoneMinder), либо ставить дополнительные датчики движения, и заводит их на "тревожные" входы регистратора.
Нет, конечно же.
Ваш собственный опыт для меня имеет нулевую ценность.
На то есть несколько причин:
1. слишком маленькая выборка
2. слишком мало информации
3. в этой ветке комментариев вы уже дали серьёзные основания сомневаться в вашем понимании как основ научного метода, так и основ логики и рациональности вообще
Что вы там «проверили на своем теле»? Перестали есть мясо и чудесным образом исцелились от рака?
Это очевидно и без комментариев.
Речь была о том, что вы сначала рекомендуете веганство и сыроедение, а потом, в ответ на аргументы, которым вам нечего противопоставить в рамках логики, начинаете «уточнять» свою позицию так, чтобы избегать неудобных для вас моментов. «Дракон, живущий у меня в гараже», классика же.
У меня, просто, та же история с кашлем. После каждой простуды месяц-два. По каким врачам только не ходил и на что только не проверялся. В итоге пульмонолог решила, что это аллергия, отправила к аллергологу. Он у нас в городе один, поэтому пока на прием не попал.
Впроцессе бегания по врачам выяснил, что у меня предиабет, и, в итоге, начал менять образ жизни — спортзал, внимательное отношение к еде, ну и таблетки, конечно(для улучшения усваиваемости глюкозы). За последний год многое в состоянии изменилось, и последняя простуда прошла почти без давно ставшего привычным затяжного кашля — всего пара дней вместо пары месяцев.
А теперь вот ваш пост, и я чот даже запереживал. Надо, видимо, в онкологию мчаться на анализы.
А чем не подходит использование штатного поля USERNAME_FIELD?
Перед написанием комментария. Перед тем, как поставить смайлик в тексте.
Перед тем, как отправить уже написанный текст.
Перед тем, как вообще начать тратить время на что-то, что отнимет у вас более 10 секунд.
Интернет стал бы намного чище от этого. Но увы.
Всё еще считаете, что «неопытному специалисту» можно что-то прощать?
Я могу согласиться с тем, что в ревью, которое более опытный разработчик делает на код менее опытного, он должен стараться нести конструктив, поясняя суть своих замечаний, предлагая варианты решений и т.п.
Но снижать планку требований? Да с каких это вдруг таких заслуг? Не можешь тянуть лямку такого проекта — работай над проектами попроще.
Это я говорю, как человек, поработавший более, чем с десятком «младших» коллег, но и неоднократно потрудившийся «ведомым».
На свой собственный код, кстати, я давно привык делать ревью ещё до пуша, в gitk-е. Последний у меня запускается автоматически скриптом при ежедневном начале работы над проектом.
Вы поинтересуйтесь, ради расширения кругозора, как оно в других профессиях происходит. Попробуйте, например, рулём покрутить, раскатывая по городу вместе с инструктором по вождению, сварщику с десятилетним стажем порассказывать, что нужно делать, чтобы электрод не залипал, или токарю шестого разряда разъяснить, какой резец выбрать.
Начинающие водители грузовиков, например, очень часто игнорируют советы старших товарищей снимать обручальное кольцо перед работой. А потом ломают пальцы или сдирают кожу. Иногда вместе с мясом.
Потому что опыт — он в любой профессии опыт. Он не является неким абсолютным мерилом всего, но всё равно крайне важен при оценке авторитетности мнения.
Зарегистрировался у вас и залил своё резюме. Желаю удачи с проектом!
Или я как-то непонятно изъясняюсь, или вы странно меня читаете.
Я как раз предлагаю тратить ресурсы не вникуда, а на полезную деятельность.
И зачем вы продолжаете приписывать мне то, чего я не говорил. Где я предлагаю «силовое решение»?
Вот у нас с вами происходит то же самое, что у персонажей заметки.
Так что давайте я вам на живом примере и поясню, что я имею ввиду, поставив в этом споре точку. Вот она:.
Вот вы взяли и навесили мне ярлык. А я разве где-то говорил про идеальный код? Я говорю о том, что во главе угла должна стоять задача, а не умащивание нежных чувств отдельных членов команды. Если человек пишет говнокод — значит он должен его исправить. Если я вижу, как его исправить с уровня F (в системе координат автора статьи) до уровня A, то почему мы должны остановиться на D? Нет, если переход на A требует неадекватных затрат времени, то мы можем остановиться и на B. Но почему D? Просто потому что автор кода — эмоциональная девушка, не желающая уступать?
Во-первых, если вы чего-то не наблюдали лично — то этого не существует?
Во-вторых — вы так говорите, словно я ратую за то, что договариваться ни в коем случае нельзя. Я лишь говорю о том, что работа не должна превращаться в бесконечные переговоры. Если два разработчика упёрлись рогом на код ревью — они оба неправы, какова бы ни была их квалификация.
Т.е. сознательно ухудшить продукт, просто чтобы подыграть чувствам коллеги?
> и убедить внести правки
Вот здесь — да. Но я сам неоднократно сталкивался с тем, что менее опытные коллеги упираются рогом просто потому, что не понимают сути моих претензий.
Я в таких случаях рогом в ответ не упираюсь. Не нравится моя оценка — либо докажи мне, что я неправ, либо мёрджи без моего подтверждения, а потом сам объясняйся с руководством, почему ты так сделал. Я больше на это своё время тратить не буду. Sapienti sat.
В коде тоже довольно легко формализовать оценку отдельно взятого фрагмента.
Например, если я в ревью придираюсь к тому, соответствует ли код стандартам PEP-8 — то это означает, что у нас заранее было оговорено, что мы придерживаемся PEP-8.
Если то, как предлагаю сделать я — быстрее/безопаснее/надёжнее/читабельнее, и я могу это доказать — значит так и надо делать. Если мне, при ревью моего кода, аргументированно такое доказывают — я не упираюсь рогом и не трачу время ни ревьювера, ни своё, ни кого-либо ещё из команды. Это то, что я считаю профессионализмом. Формулируя чуть короче — профессионализм, это когда стараешься делать своё дело лучше и быстрее, избавляясь от того, что тебя сдерживает.
А заниматься выстраиванием отношений в команде вместо работы над продуктом — это хипстерская херня. Да, коммуникация важна. Да отношения с коллегами надо поддерживать.
Но всё это не должно быть самоцелью, мы здесь работать собрались, а не играть клуб анонимных алкоголиков.
Сейчас в среде разработчиков принято называть «суперзвёздами» или «рок-звёздами» тех, кто кроме своего эго ничего не видят, не умеют делегировать, и, в результате всего этого — замедляют работу над продуктом, а не ускоряют. И, в итоге, сгорают сами.
Я считаю, это неправильно.
Те, кто выгорел — это не суперзвёзды. Настоящие суперзвёзды, как Линус Торвальдс, год за годом локомотивом пробивают пробивают дорогу не только себе, но и другим.
Занятная статья.
Я сам делал очень похожее несколько лет назад. Устройством, правда, был не роутер, а две Nanostation Loco M5, собранные в мост. Мне нужно было выводить уровень сигнала и скорость линка в дашборд, и я сделал примерно так же — питоноскрипты, ползающие по вебу.
Пара замечаний(было больше, но про девтулс уже написали 8):
breakпослеreturnи прочее. Однако, добавлю конструктива — если вам не пофиг, то по качеству кода я могу накидать замечаний в гитхаб или какой-то другой сервис, если код вы выложите туда.Спасибо за заметку.
У меня тут как раз Raspberry PI(правда, постарше, вторая ещё) висит, на которую заведены и видеонаблюдение, и сбор данных с нескольких датчиков температуры/влажности, раскиданных по дому, и скоро должен приехать пучок релюшек Sonoff для управления светом и прочими
Я как раз подумывал ко всему этому прикрутить телеграм-бота, а тут ваша статья.
Правда, касательно самого видеонаблюдения, у меня всё несколько сложнее, потому что частный дом, камера не одна, а уже 4(и будет больше), и все они смотрят на улицу. Через это в моем случае рациональнее оказалось ставить железный видеорегистратор, который сам умеет следить за движением и отправлять сообщения по почте.
Другое дело, что с учетом того, что камеры уличные, лог сработок на шкале времени выглядит примерно вот так:
И это ещё не самый "активный" день.
С одной стороны — все эти сработки неплохо иметь в архиве, чтобы, например, во время отпуска можно было вечером за небольшое время посмотреть "ретроспективу" за день. С другой стороны — если каждую сработку показывать в телеграме, то поток сообщений будет слишком густым и малополезным.
Поэтому я пока ещё работаю над всем этим и думаю, как сделать правильнее. Пока видятся два возможных пути — либо прикручивать второй слой анализа картинок(например, ZoneMinder), либо ставить дополнительные датчики движения, и заводит их на "тревожные" входы регистратора.
В общем, копать — не перекопать 8)
Ваш собственный опыт для меня имеет нулевую ценность.
На то есть несколько причин:
1. слишком маленькая выборка
2. слишком мало информации
3. в этой ветке комментариев вы уже дали серьёзные основания сомневаться в вашем понимании как основ научного метода, так и основ логики и рациональности вообще
Что вы там «проверили на своем теле»? Перестали есть мясо и чудесным образом исцелились от рака?
Думаю, что это очень популярная книжка с весьма спорными тезисами, которые критикуются многими специалистами в области.
С научной точки зрения здесь всё немного иначе.
Речь была о том, что вы сначала рекомендуете веганство и сыроедение, а потом, в ответ на аргументы, которым вам нечего противопоставить в рамках логики, начинаете «уточнять» свою позицию так, чтобы избегать неудобных для вас моментов. «Дракон, живущий у меня в гараже», классика же.
Впроцессе бегания по врачам выяснил, что у меня предиабет, и, в итоге, начал менять образ жизни — спортзал, внимательное отношение к еде, ну и таблетки, конечно(для улучшения усваиваемости глюкозы). За последний год многое в состоянии изменилось, и последняя простуда прошла почти без давно ставшего привычным затяжного кашля — всего пара дней вместо пары месяцев.
А теперь вот ваш пост, и я чот даже запереживал. Надо, видимо, в онкологию мчаться на анализы.