Наверное, есть тее, которые читали статью про то, как не надо входить в хату, в которой я делился своим опытом смены профиля в разработке. Конкретнее с разработки под МК на Embedded Linux. Вкратце: опыт довольно болезненный и всё-таки полезный при условии, если учишься на совершенных ошибках.
Практически 6 лет моего опыта — это разработка на Си под микроконтроллеры, причем разные:
-
это всякие AVR, STM и т. д., под которые есть много кодовой базы и материалов
-
какие‑нибудь SOC от Texas Instruments, по которым есть инфа только на закрытых форумах, доки (с пробелами и неточностями) и примеры драйверов, из которых можно подчерпнуть много полезного.
Ну и Embedded Linux, куда же без него. И вот тогда мне казалось, что я пишу мало кода. Как же я ошибался...
В моей практике Embedded Linux оказался переходным звеном из мира низкоуровневой разработки в мир прикладного ПО и уже на этом промежуточном этапе было сильно меньше написания кода, в основном изучение драйверов, переделка уже имеющихся. Вспоминая времена разработки под МК, удивляюсь тому огромному количеству моего кода, которое отгружалось в проекты.
Если говорить уже о прикладном - тут ситуация стала еще "круче" в нескольких аспектах.
Во-первых, как вы могли догадаться, программирования стало еще меньше. Да, это всё легаси, которое постоянно улучшается, приобретает новый функционал и избавляется от багов. И программировать там особо не надо, но при этом развивать другие навыки, которые...
Во-вторых, ... связаны не с языком программирования, а (барабанная дробь) с системным администрированием! Да, один из продуктов компании - это собственно набор утилит, помогающий администрировать записи пользователей малого/среднего/крупного бизнеса. Ясен пень, что нужно уметь этим софтом пользоваться, чтобы понимать его работу. Конечно, раньше я мечтал о том, чтобы влиться в Linux-разработку, ориентироваться в командной строке, как рыба в воде, писать утилиты, но что бы настолько... Да, я в Linux-разработке, да, привык к интерфейсу командной строки, но количество написанных строк кода почему-то какое-то мизерное.
Как говорится в одном известном меме:
Ну и напоследок, навыки отладки пачки одновременно работающих утилит. Например твой сервис отправляет сокеты в один, который обменивается данными с контроллером домена и толкает другой, что-то кладущий в свою БД и общающийся с клиентом на другой машине. Чтобы это всё анализировать помимо обычных логов же используется много чего: и GDB, и Perf, и какой-нибудь tcpdump и много чего еще интересного. Забавная была трансформация от состояния "а куда вообще тут смотреть?" до "ща запущу нужные утилиты, и буду смотреть что от куда вытекает и куда перетекает". Менять привычки, конечно, сложно, особенно в отладке: раньше тебе хватало только логов и осциллографа, не то что сейчас :)
В текущей ситуации состоялась одна из моих самых важных трансформаций: не надо брезговать пользоваться готовыми решениями. Раньше профдеформация говорила мне: камон, ты же практически всё пишешь с нуля, давай с нуля и вот это вот напишем. И в целом она была недалека от реального положения дел. Ты завязан только на своём коде, и что‑то в него встраивать извне себе дороже. Сейчас же ситуация прямо противоположная: проще встроить готовый инструмент/библиотеку и уже вот это всё корячить под себя, будет банально дешевле.
А да, еще одна трансформация — это отношение к Python: если раньше я как‑то с высока на него смотрел, типа фу‑фу‑фу, питонисты — не тру программисты, то сейчас: «М‑м-м, какой удобный язык: и тестики на pytest'е как легко пишутся и автоматизация процессов, блин, как удобно. И как же я раньше жил без него?...». Раньше делая какую‑то автоматизацию, я пытался в bash , но потом бросил эту затею, так как в пайтоне реально удобнее. Иными словами, в голове надежно закрепилось понимание, что у каждого ЯП свои задачи и относиться к этому надо соответствующе.
В общем, кодинга стало меньше, скиллов работы с утилитами в CLI и изученных ЯП — больше. В связи с этим не перестаю задаваться вопросом:
Так кем же в итоге я стал?
Автор: Vanovsky714
