Рубрика «культура разработки»

В нашем блоге мы уже не один раз рассказывали о переезде в Нидерланды (раз, два). Разработчики, которые оказались в Амстердаме в один голос говорят о том, что с точки зрения технологий и подходов к разработке среди местных ИТ-компаний в лучшую сторону выделяется Uber. И сегодня нам удалось поговорить Алиной Коваленко, которая работает в компании в должности Software Engineer II. Алина поделится своим опытом переезда и даст несколько полезных советов. Передаем ей слово!

Читать полностью »

Как разработчик, вы услышите много сумасшедших, невероятных теорий о значении «строк кода». Не верьте ни одной. Строки кода — нелепая метрика. В очень редких случаях она что-то говорит, обычно — ничего. Использование строк кода для принятия решений похоже на оценку качества книги по количеству страниц.

Некоторые могут сказать, что чем меньше строк кода в приложении, тем легче его читать. Это только частично верно. Вот мои метрики для читаемого кода:

  • Код должен быть последовательным
  • Код должен быть информативным
  • Код должен быть хорошо документирован
  • Код должен использовать стабильные современные функции
  • Код не должен быть излишне сложным
  • Код не должен быть неэффективным (не пишите намеренно медленный код)

Если уменьшение количества строк кода противоречит любой из этих метрик, это становится проблемой. На практике оно почти всегда будет мешать и, следовательно, почти всегда является проблемой. Но вот в чём дело, если вы стремитесь соответствовать вышеуказанным критериям, то у вашего кода будет идеальное количество строк — и не нужно их подсчитывать.
Читать полностью »

Несмотря на то, что технологии модульного тестирования существуют уже 30 лет (в 1989 году Кент Бек написал статью “Simple Smalltalk Testing: With Patterns”), тем не менее не все программисты владеют этой технологией и не все компании сделали автоматическое тестирование частью своей корпоративной культуры. Даже несмотря на очевидные преимущества автоматического тестирования, все равно поведенческое сопротивление достаточно сильное. Кто пробовал внедрять автоматические тесты, тот знает, что всегда найдется какая-то причина, почему это не удалось сделать.

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

Все возражения я сгруппировал в пирамиду надежного программирования, которая включает четыре уровня:Читать полностью »

Я конечно не профессиональный психолог, но у меня уже сложился некоторый опыт, который, как мне кажется, позволяет мне выделить некоторые человеческие качества, которые могут оказаться полезными для разработчика и его жизни.

image

Статья в целом больше для разрабов-новичков, и для опытных старожилов всё описанное будет наверное очевидно, но возможно кое-что полезное смогут перенять и они в том числе. Пишите отзывы и высказывайте свои точки зрения на эту тему, это тоже интересно будет почитать.

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

Давайте поговорим немного о каждом из этих качеств.Читать полностью »

Devops в кровавом энтерпрайзе - 1
Вот к такому можно стремиться

У нас больше 350 своих разработчиков ПО и тестировщиков по всей стране, плюс мы часто взаимодействуем с инженерами и разработчиками заказчиков. Чтобы перейти на практическое использование devops, нам нужно было обеспечить не только внедрение методологии, но и приучить любимых российских заказчиков к некоторой базовой культуре. Просто пара диалогов для понимания:

— Почему у нас всё упало?
— Потому что вы откатали это на стенде, всё протестировали, а потом развернули на проде. Вот у вас настройка, которая не попала в инструкции, и жила только в голове старого админа.

Или:

— Почему не запускается по всей стране?
— Потому что у вас несколько десятков разных региональных инсталляций, каждая делалась руками, и на каждой разные конфиги. И ещё в паре случаев инженер ошибся.
— Поправите до завтра? Очень нужно! Только доступ удалённо мы вам не дадим.
— ..! Конечно, у нас есть команда высокооплачиваемых спецов, обожающих ездить на Дальний Восток. Нет проблем.

Читать полностью »

  1. Менеджмент некой компании уделяет большое внимание мотивации сотрудников.
  2. Для поощрения высоких результатов было решено выдавать премии командам по результатам соблюдения сроков и бюджетов проектов.
  3. Решение было доведено до сотрудников.
  4. Одна из команд занималась доработками зрелого и стабильного проекта, успешно выполнила все условия, получила премию.
  5. Другой команде достался новый сложный проект, люди работали над ним с неподдельным энтузиазмом.
  6. К сожалению, и запланированные сроки, и бюджет оказались превышены в разы.
  7. Получившийся в результате продукт дал компании рекордную прибыль.

Читать полностью »

«Почему ж всё так плохо?» — каждый раз я задаюсь этим вопросом, когда приходится иметь дело с очередным кодом, продуктом или API, созданными для внутренних нужд в непрофильной организации.

В профильных дела обстоят получше, но далеко не всегда: в коробочных тиражируемых решениях чаще лучше, чем в проектной разработке. В продуктах одного заказчика, обычно, хуже всего.

И деньги ничего не решают: ужасный код и ужасные продукты пишут как маленькие бедные ВУЗы, у которых денег хватает только на рабский труд аспирантов, так и крупные и богатые компании, включая IT-компании, включая зарубежные: несколько раз сталкивался с кодом, который писали зарубежные подрядчики и каждый раз от него хотелось рыдать и биться головой об стену.

Организация может декларировать строгие стандарты, нанимать дорогостоящих разработчиков, вводить регламенты и методологии, надувать щеки на совещаниях и громогласно обличать «неправильное решение» в чужом продукте. И продолжать делать ужасные продукты с ужасным кодом, вопреки высокой квалификации своих разработчиков и очень правильными и нужными регламентами и стандартами.

Я занимался разработкой ПО в нескольких организациях и по разным причинам несколько раз перенабирал команду с нуля. В итоге пришел к выводу, что качество продукта зависит только от культуры разработки. Всё остальное, включая методологии и стандарты — это инструменты: они необходимы, но одних их не достаточно.

Культуру разработки можно сравнить с экосистемой: как сад или аквариум. Крепкая, здоровая культура обладает запасом прочности, чтобы оздоравливать обитателей экосистемы, избавляться от вредителей, прощать небольшие ошибки ухода, сглаживать стрессы и на выходе все-равно получать отличный результат. А больная культура сводит на нет все усилия, заражает и губит даже самые здоровые и крепкие саженцы.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js