Hot Positions, Cool Company! NeoGames
×Закрыть
software engineer в FrontRange Solutions
  • Подкасты

    Bieng The Worst подкаст о разработке на английском:
    beingtheworst.com/...tegory/podcasts
    и на русском

    beingtheworst.com/...ory/episodes-ru

  • 76-й выпуск подкаста «Откровенно про IT карьеризм». Беседа с Александром Кондуфоровым, Software Architect в AltexSoft

    У тебя номера подкастов в названии, это то что надо.

  • 76-й выпуск подкаста «Откровенно про IT карьеризм». Беседа с Александром Кондуфоровым, Software Architect в AltexSoft

    Твоя газета утверждает, что первый. Они там итак сортируются по дате. Уже несколько раз я хотел найти там выпуск номер N и забивал в процессе.

  • 76-й выпуск подкаста «Откровенно про IT карьеризм». Беседа с Александром Кондуфоровым, Software Architect в AltexSoft

    Очень неудобно, что в iTunes подкасты пронумерованы наоборот, 76-й это 1-й почему-то.

  • Работа в продуктовой компании aka авгиевы конюшни

    Согласен

  • Работа в продуктовой компании aka авгиевы конюшни

    Вы описали когда всё плохо, видимо потому, что у вас не было хорошо или просто крик души, т.к. именно сейчас всё плохо. То, что описано — это вопрос выбора, выбора, котрый вы делаете на собеседовании. Стоит пообщаться с командой, позадавать умные вопросы и решить та ли эта продуктовая компания о которой вы мечтаете.

    Я тоже поработал и в аутсорсинге и в двух продуктовых компаниях, всё по своему хорошо, но второе мне нравится больше, только потому, что есть возможность попасть в клёвую команду и надолго. Т.е. дольше работать с классными людьми, пусть даже и вместе разгребать старинный какашкокод (доу, разреши, пожалуйста, писать слово «г0внокод»), но под девизом «так будет не всегда» =)

    Когда есть классная команда — пофигу какого типа компания, всё итак будет хорошо.

    Поддержал: Serge Smertin
  • 56-й выпуск подкаста «Откровенно про IT карьеризм». Беседа с Сергеем Мовчаном, куратором обучения в сказочном королевстве

    Смертный грех, кстати, не гордость, а гордыня, т.е. непомерная гордость.

    Поддержали: Sergey Medvedev, Oleksandr Manenko
  • Профит-Шоу XVII: Николай Палиенко, директор Prom.ua

    а зачем?

  • Code review

    Код-ревью — это вообще очень сильная проверка/встряска для команды. Очень сложно достичь момента, когда критика воспринимается не лично, а с пониманием, что это во благо. Сложно правильно делать ревью, тоже нужна деликатность, т.к. каждый любит свой код и не хочет признавать, что в нём, что-то не так. Тем не менее, такую встряску я нахожу полезной, выводит отношения на новый уровень понимания и доверия.

  • Code review

    Если пункт «уговорить» выполнен, такого не случится, т.к. все будут эту активность, если не любить, то принимать и понимать. То, что вы описываете, это когда этот пункт не выполнен.

    По поводу вашего «сомневаюсь»:

    В трёх разных командах трёх разных компаний удалось убедить сокомандовцев этим заняться и прочувствовать пользу. Стратегия такая «объяснить пользу на словах», «уговорить попробовать», «собрать фидбек», «повторять до наступления эффекта».

    Поддержал: Олексій Орєшко
  • Code review

    Ещё как получится и будет более эффективным средством, чем наличие «Процесса».

  • Code review

    Довольно много размышлений было на эту тему. Пробовал разные подходы. В итоге отказался от всего формального, в данный момент как такового строгого процесса в команде нет, но ревью у нас это часть definition of done. Т.е. это единоличная ответственность каждого, а не одного человека. Хорошо, что все понимают, зачем это нужно и находят удовольствие в процессе.

    В виду описанного выше, ревью происходит разными способами:
    + Подойти и попросить «пошли код покажу =)»
    + Лично я просматриваю изменения всей команды
    + Раз в неделю у нас есть митинг, куда мы «приносим», что-то на ревью, длина около часа.
    + Забавные, непонятные участки отправляем по почте, сохраняем дискуссию потом.

    + Иногда создаём презентации (да да PowerPoint) для демонстрации чего-то эдакого (удобно стрелочки рисовать)

    Команда из разных людей — сильных и взрослых (40+), молодых и способных (23+). За всё время экспериментов пришёл к выводу, что гораздо более важным является добиться понимания, что ревью это не просто нужно, а ещё и полезно и весело. Когда люди начинают это чувствовать, процесс происходит сам собой, то там, то тут, то одним, то другим способом. Становится обычной каждодневной активностью.

    Тем не менее идеальным иснтрументом я вижу следующее:
    + плагин для IDE, который имеет интерфейс как у Review Tools from MS Word
    + результаты хранятся в сорс контроле

    + доступен веб интерфейс с подсветкой кода и навигацией близкой к привычной в IDE

    Даже было начал писать подобное решение, но пока подзабил.

  • Code review

  • Русский язык в ИТ Украины

    Далеко не все смогут/захотят перейти, незнание русского — действительно проблема.

  • Креш-тест резюме, выпуск № 1: Советы Инны Скочко

    Краштест, как описание выводов из усреднённого набора резюме это полезно, но формат бизнес-линча я бы нашёл более интересным.

  • Креш-тест резюме, выпуск № 1: Советы Инны Скочко

    На GitHub в GitMarkdown это последний пункт ++

  • Креш-тест резюме, выпуск № 1: Советы Инны Скочко

    А почему ссылки на html страницу недостаточно?

  • Учиться, учиться и ещё... где/когда/как?

    Книги несомненно лучше, но подкасты это, когда в дороге или когда глаза заняты.

  • Как поменять минус на плюс, или Давайте сделаем это интересным

    Я думаю вы не так меня поняли, отсюда и все колкости по поводу моего тайтла и т.п. Я написал, что «тесты не решают проблему наличия багов», а вы написали «они уменьшают количество багов» — чувствуете разницу? Несомненно они уменьшают, но не решают прооблему их наличия.

    Давайте я лучше немного расскажу о себе, я с первого года работы проникся идеей юнит тестирования, усиленно вводил эту практику на первой работе, затем на второй и вот сейчас на третьей, около 4-х лет я пишу юнит и интеграционные тесты в каждом проекте в котором работаю, и не просто пишу, а тренирую людей это делать. Читаю по этому поводу лекции (restuta.net/...elopers-slides ). Некоторое время работал на Typemock, куда был принят после собеседования с Roy Oscherove (минутки тщеславия).

    И да, проблемы юзабилити и неверного решения, как вы написали, такие тесты никогда не выявят, но они и не должны, ибо это совсем другая история, которая решается только человеческим взлядом на реализацию/юзабилити и сравнением их с требованиями.

    Суть того, что я написал в том абзаце было — уточнение, того, что написал автор в топике. Я забочусь, чтобы читатели правильно понимали применение этого инструмента. Т.е. уменьшить количество багов в коде покрытом тестами удастся, но никак не других типов багов. Часто создаётся ложная иллюзия того, что когда команда пишет тесты, то багов у них в проекте быть не должно или «тесты не работают», я слишком часто слышал такие фидбеки от менеджеров и других людей, которые ещё не поняли предназначения юнит тестов. Также мой опыт показвыает, что баги которые пользователи находят в приложении это (очень субъективно) 90% UI сторона, нежели server side. (которую тоже можно покрыть тестами, но уже не юнит, разве что сложныйе Javascript скрипты покрыть тестами на JavaScript тест-фреймворке, остальное это удел автоматизированных тестов).

    грамотно написанные тесты, покрывающие всю критическую функциональность приложения, во-первых тестируют код данной функциональности на баги, а также дают 100% уверенность, что рефакторинг архитектуры/кода не поломает ничего, а при переделке легаси системы это 100500% правильный путь, иначе систему разломают и не соберут.

    Несомненно, единственное, что хочу заметить, что для легаси системы я рекомендую такой путь:
    интеграционные тесты на то, что мы собираемся менять/рефакторить -> рефакторинг, чтобы можно было написать юнит тесты -> юнит тесты

    так мы сможем получить гарантию, что ничего не сламаем во время рефакторинга + получим набор интеграционных тестов

    Я не буду комментировать остальные участки вашего сообщения, т.к. надеюсь мы друг друга поняли и нашли корень miss communicatioin.

  • Как поменять минус на плюс, или Давайте сделаем это интересным

    Конечно, наоборот, очень даже «треба». Всё, что написано в том абзаце — лишь уточнение того, что написал автор, уточнение «тесты уменьшат нам кол-во багов». Уточнение, чтобы не складывалось ощущение «ага, тесты это волшебство», давайте их попробуем — баги всё равно будут (и может даже много), и потому мы будем потом кричать «ааа, не работают ваши тесты мы пробовали».

    Вот я и уточнил (just to be clear приписка там не случайна), чтобы ложного впечатления не было, а было понимание, что конкретно даст использование этого средства.

← Сtrl 1234 Ctrl →