group-telegram.com/iosmakesmehate/2971
Last Update:
Помните мы читали одну из лучших книг прошлого года? The Software Engineer's Guidebook. Тогда я делился главой про написание кастомных решений. Автор говорил, что свои велосипеды — это лучший путь для карьерного и профессионального развития. Фундамент promotion driven development.
Утверждение крайне спорное. В комментах поста крутые инженеры немного поспорили выгодно ли писать свои решения или лучше заимствовать чужие?
Недавно заметил за собой, что в канале ни разу не писал разборы чужих опенсоурсов. Дико не люблю разборы чужих библиотек и фреймворков. Своих велосипедов на работах всегда хватало
По мне лучше изучать исходники языка и нативных инструментов, чем рытаться в открытом коде, скорее всего написанном на скорую руку. Где времени на ревью и проектирование почти нет. Аккуратно подниматься по абстракциям снизу вверх. А я еще не до конца изучил даже исходников Swift, чем переходить к условному PointFree.
В FAANG’ах любят писать все свое. На то есть несколько причин:
1. Антипаттерн Vendor Lock. Используя закрытое чужое решение, становишься от него зависимым.
В Яндексе есть свой git, jira, свой teamcity. Казалось бы зачем? Помню, как у многих были проблемы с CI. А в Авито в один день отключили корпоративные учетки гугл доков, потеряв очень много ценной инфы.
Также самое и в мобилке. Если либа не обновлялась год, то значит она почти мертва. Стоит ли тащить избыточное решение целиком или лучше взять лучшую часть и адаптировать под себя?
2. Если твоя компания может позволить нанять себе лучших специалистов и у них есть все нужные ресурсы написать решения лучше, то почему этого не сделать? Так ты поможешь и продукту выполнить метрики. И создать технологичное конкурентное преимущество.
Например, на последнем конкурсе телеграм, для написания видеоплеера нужно было отказаться от AVFoundation. Задача усложнялась в разы и в итоге победителей конкурса не оказалась.
Слышал, что написать свой AVFoundation в ВК видео вроде заняло почти три года. Но объективно плеер ВК в разы лучше телеграмовского.
Конечно, писать или заимствовать вопрос многих переменных: сроков, цены, целей. Но для меня лучше всегда писать хотяб минимум, но своих решений. Улучшать или дополнять. Так мы находим боевой опыт, который дает уникальную ценность нам и нашему продукту. А также повышая техническую осознанность.
Деградация кодовой базы, инфляция стандартов и циркуляция новых решений в ит сравнится как негде. Вечные патчи, апдейты, обновления — все требует бесконечного обновления. В этих условиях невозможно жить без своих велосипедов и инхаус решений.
Мораль. Использовать готовые решения можно и иногда даже необходимо, но если у тебя есть ресурсы и возможности создать свое — то преступление этими возможностями не пользоваться.
Но все же иногда стоит помнить, что инженер оценивается не потому сколько прочитал, а сколько написал сам.
