Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#Мнения</a>

2 <ul><li>30 дек 2021</li>

3 <li>0</li>

4 </ul>Опытный CTO рассказал о best practices в подходе к разработке - они помогут выстраивать отличные отношения с коллегами и вообще быть молодчиками.

5 Кадр: сериал "Кремниевая долина"

6 Фанат Free Software Foundation, использует Linux и недолюбливает Windows. Пишет истории про кодинг и программы на Python. Влюблён в Lisp, но пока что не умеет на нём программировать.

7 Александр Субботин

8 об эксперте

9 За 10+ лет в IT прошёл такой путь: верстальщик → фулстек-разработчик на JS и Ruby on Rails → CTO в Appbooster. В Telegram-канале<a>Saturday Night Hack</a>делится своими мыслями про командную работу, создание продуктов и менеджмент. Есть личный<a>сайт</a>и <a>твиттер</a>.

10 Я регулярно собеседую разработчиков и встречаю среди кандидатов всё больше выпускников IT-курсов. На курсах дают много информации о технологиях, фреймворках и паттернах. В итоге ребята в основном понимают,с чемнужно работать, но мало кто из них понимает,какнужно работать и к чему стремиться.

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

12 Допустим, вы получили большую задачу, ушли в свой угол и, ни с кем не общаясь, решаете её весь месяц. В итоге ваши коллеги всё это время будут ломать голову и задаваться вопросами: "А всё ли у вас хорошо? Вы всё ещё выполняете эту задачу или переключились на что-то другое? А точно ли все поняли друг друга и на выходе будет именно то, что нужно?" Часто кажется, что ответы на эти вопросы очевидны для всех и все понимают, что вы заняты делом - однако в реальности для людей вокруг вовсе не очевидно то, что очевидно для вас.

13 Если вдруг вы раздражаетесь от регулярных вопросов менеджера: "Ну чё там? Когда будет готово?" - значит, вам пора научиться вести свою работу прозрачно. Если вы начнёте регулярно делиться, с какими проблемами столкнулись, и показывать результаты своей работы (проактивно, а не по запросу), то у менеджеров просто не будут возникать подобные вопросы.

14 В чём польза?

15 <ul><li>Люди перестанут в самый неподходящий момент лезть к вам с вопросами в стиле "Ну как успехи?".</li>

16 <li>Команде проще планировать работу, понимая, что и когда будет готово.</li>

17 <li>Вы сможете проще делить и координировать работу с другими членами команды.</li>

18 </ul>Продолжим разбирать пример с большой задачей на месяц. Теперь представьте, что после того, как вы решили задачу, вам нужно пройти код-ревью. Наверняка после месяца фултайм-работы это будет царь-пул-реквест - с сотнями, а то и тысячами строк изменённого кода. И вот ваш коллега-разработчик открывает<a>Git</a>, видит этот пул-реквестище и… закрывает его. Причина проста: у вашего коллеги и так высокая когнитивная нагрузка - ведь ему приходится решать кучу собственных задач, а тут нужно дополнительно переварить огромный кусок информации, разобраться в хитросплетениях вашего кода и всех изменениях.

19 Если хотите, чтобы другие разработчики быстрее и охотнее ревьюили ваш код, тестировщики его тестировали, а продакты быстрее выдавали аналитику о поведении реальных пользователей - декомпозируйте большую задачу на много маленьких последовательных подзадач.

20 В чём польза?

21 <ul><li>Вы сможете быстрее получать фидбэк и корректировать свои планы.</li>

22 <li>Вам будет не так обидно что-то переделывать или откатывать - то есть вы не будете подвержены<a>эффекту IKEA</a>.</li>

23 <li>Команда будет регулярно видеть осязаемые результаты вашей работы и понимать её ценность.</li>

24 </ul>Конечно, чем опытнее разработчик, тем сложнее задачи, которые он решает, и стек технологий, с которыми он работает. Конечно, тяжело, когда люди из бизнеса или менеджеры не понимают всех тех трудностей, через которые вам приходится проходить, и важности ваших предложений (именно поэтому нередко отдают предпочтение новым фичам, а не рефакторингу или переезду на новый стек).

25 Но делают они это не потому, что для них не важна стабильность или скорость разработки. Скорее всего, они просто не понимают ваших доводов. Так что надо развить в себе суперсилу: научиться простым языком объяснять сложные вещи нетехнарям (помните про<a>метод Фейнмана</a>?).

26 В чём польза?

27 <ul><li>Ваши идеи чаще будут слышать, понимать и принимать.</li>

28 <li>Люди быстрее будут делать то, что вы у них просите (ведь теперь для них станет понятно, что же вы хотите).</li>

29 <li>Вы будете лучше разбираться в том, о чём говорите (иначе невозможно простым языком объяснить сложные вещи).</li>

30 </ul>Некоторые программисты считают, что их работа - писать код. Но это не так. Их работа - создавать системы. А у систем есть два требования: они должны решать поставленные задачи и быть простыми в поддержке и эксплуатации. И если задачу можно решить так, чтобы не тратиться потом на поддержку: с помощью no-code, serverless, готового сервиса, фреймворка или библиотеки - используйте такой вариант. В итоге в глазах новых участников команды разработки ваш проект должен выглядеть скучным и однообразным.

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

32 В чём польза?

33 <ul><li>Вы намного проще и быстрее будете ориентироваться в проекте.</li>

34 <li>Вы сможете делегировать простые задачи менее опытным разработчикам, а своё время тратить на упрощение проекта и систематизацию.</li>

35 <li>Вы без проблем сможете передать проект другому разработчику и начать что-то новое.</li>

36 </ul>Большинство разработчиков - перфекционисты. Они пытаются довести свою работу до идеала. Но в работе на реальных проектах всегда есть ограничения по времени и ресурсам. Поэтому опытному разработчику нужно ориентироваться в текущих требованиях и быть способным сделать<a>правильный выбор</a>.

37 Что важнее прямо сейчас - качество или скорость? Лучше написать тесты или сделать быстро? Разобраться в новой модной библиотеке, которая вроде бы решает проблему, или сделать так, как умеем?

38 Хороший разработчик сразу после написания кода понимает, что можно улучшить. Но также хороший разработчик понимает, что не всегда нужно идти и улучшать.

39 <a>Бесплатный курс по Python ➞Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу</a>