Я учился в CompSci, где нас в первую очередь учили Java, но я узнал, что моя страсть - это системы, поэтому я всегда работал на стороне оператора. Я очень разбираюсь в сценариях, поэтому я не ищу сайт, где можно научить меня Ruby, но что-то объясняет более подробно, что вы, разработчики, делаете весь день. Я хочу лучше понять культуру и то, как вы перевариваете огромное количество файлов в ваших проектах - нематериальные активы.
Если бы я узнал сегодня, что меня перевели в команду разработчиков в понедельник, что бы я хотел прочитать на этих выходных?
culture
builds
methodology
software-engineering
Стивен С
источник
источник
Ответы:
Поскольку вы пометили этот вопрос как «культура», я предполагаю, что вы заинтересованы не в конкретном приложении, а в более широких вопросах рабочего процесса и управления.
Я бы, наверное, начал с «Руководства по DevOps»; это хороший обзор различных вещей, которые стоит рассмотреть, не погружаясь слишком глубоко.
«Непрерывная доставка» Джеза Хамбла также часто упоминается; Я еще мало читал об этом, но он охватывает концепции управления исходным кодом и автоматизации сборок.
Если вы начинаете получать приложения в масштабе (это может быть слишком много предположений), еще одна хорошая книга - «Практика администрирования облачных систем» (Limoncelli et al.).
источник
Это не DevOps, а прямая разработка программного обеспечения, я полагаю.
Что ж, главное в прямой разработке (без угла DevOps), безусловно, «проворный», то есть по большей части SCRUM. Вы можете сделать хуже, чем сесть и прочитать Agile Manifesto или учебник по SCRUM или Kanban для более ежедневных задач по исправлению ошибок и обслуживанию.
Кроме того, говорить о «культуре» вообще, если говорить со стороны разработчиков, в основном о DevOps. Да, у нас есть и наши евангелисты, особенно для более новых вещей, таких как рубин или голанг, но не такие экстремальные, как в мире DevOps / Cloud, где происходят реальные изменения парадигмы.
Сам поработав над нетривиальными приложениями ruby, ничего страшного. Видите ли, эти файлы не просто разбросаны, но есть иерархия, соглашения и все такое. На самом деле вам никогда не нужно иметь все эти файлы в своей голове в один момент времени для хорошо спроектированного проекта. Если вы работаете в определенной области, обычно довольно ясно, где находятся соответствующие файлы, и вы можете легко увеличить их. То же самое должно быть в других современных средах программирования.
В плохих приложениях все по-другому, но тогда разработчик на самом деле ничего не «переваривает», а просто безумно весь день спотыкается, пока не уйдет. ;)
источник