2019-12-25 13:00:54
5 правил программиста1. Монорепозиторий? Лучше не надоЕсли ты не знаком с таким понятием как монорепозиторий, я постараюсь объяснить: вместо использования множества репозиториев для своих приложений, библиотек, компонентов, монорепозиторий предполагает размешать все в одном единственном репозитории.
Это помогает сделать разработку множества проектов проще, но это имеет свою цену: ты должен использовать subversion, ты не можешь использовать Git. Git, при всей своей гибкости и универсальности, не поддерживает так называемые sparse checkouts как subversion.
Sparse checkouts позволяет делать чекаут от отдельных директорий огромного дерева директорий. Это дает возможность командам работать над отдельными частями такого дерева. Git же чекаутит целиком такое дерево.
Git предполагает разделение отдельных частей приложения на отдельные репозитории.
У монорепозитория есть и ряд других недостатков:
- долго скачивать и разворачивать
- в история коммитов будет целый роман c несколькими сюжетными линиями
- сильная связанность и проблема масштабируемость.
Да, эти проблемы решаются и у монорепозиториев есть плюсы (не спроста же их используют Google, Facebook, Twitter), но это отдельная история. В общем случае: лучше не надо.
2. Сначала проблема - потом решение
У каждого из нас есть технологии, которыми мы любим пользоваться: Redis, MySQL и т п. Это совершенно нормально и здорово иметь предпочтения.
Проблемы начинаются, когда предпочтения превращаются в требования.
И нужно признаться, что это не только наши личные грехи, организации тоже в этом виноваты.
Многие компании выбирают определенные технологии, библиотеки или инструменты, часто лишь потому, что это модно, это используют вот те крутые ребята, или просто прочитав где-то статью или комментарий.
И компании навязывают эти вещи разработчикам, которым в итоге приходится использовать или внедрять эти технологии.
Это очень странная, но при том очень распространенная, ситуация в корпорациях, когда группа архитекторов или, что еще хуже, просто руководство является повелителями простых программистов, которые на самом деле пишут код.
Часто, в компании принимается решение использовать определенную технологию или продукт - Kubernetis, AWS или еще что-то - без полного понимания проблемы в этой самой компании, которую эти технологии призваны решить.
Особенно страшно, когда технологию внедряют без понимания зачем, и не имея разработчиков, которые бы работали с ней или выстраивали приложения вокруг этой технологии.
Необходимо сначала понимать проблему, до того как начинать использовать какой-либо инструмент.
3. Задавай вопросы.
Я не устану это повторять из раза в раз.
Это звучит очень просто, очевидно и по-детски. Но для многих это оказывается очень сложным. Не понял что-то? Задавай вопросы. Хочешь знать почему принято именно это решение? Задавай вопросы. Хочешь понимать куда движется проект? Задавай вопросы.
Даже не для того, чтобы получить нужный ответ. Часто ты не получишь ответа вовсе. Но если ты не будешь задавать вопросы, ты никогда и не узнаешь об этом.
При устройстве на новую работу, например, совершенно точно нужно задавать вопросы. Зачастую люди стесняются или боятся задавать вопросы, потому что не хотят показаться глупыми. В этом нет ничего плохого!
Вопросы “Прости, а не можешь объяснить почему тут так” это не только невероятно эффективный способ понять нужные вещи, но и борьба с “так исторически сложилось”.
Ты будешь удивлён, как много организаций делает что-то “по историческим причинам” или просто “потому что”. Обычно это происходит потому, что однажды кто-то так сделал, а после этого никто не потрудился это исправить.
Задавая вопросы, бросая вызов “исторически сложившимся” вещам и докапываясь до истины мы делаем лучше нашу команду, проекты, самих себя и свою жизнь лучше. Часто просто задавая вопросы можно выкинуть целые слои из приложения без особых проблем.
339 views10:00
Я
