freelance — you're doing it wrong!
Доброго времени суток уважаемые хаброжители, меня зовут Юра, и сегодня я поведаю вам о проблемах высокотехнологичного отпрыска удалённой работы — фриланса, а именно о разработке мобильных, десктопных и вэб-приложений, вёрстке и дизайне. Работаю я в этой сфере достаточно недавно, буквально с 2008 го, и опыта хорошего и плохого у меня накопилось достаточно много. Цель данной публикации — показать разницу между простыми сотрудниками и фрилансерами, а также — показать основные организационные проблемы, которые возникают при разработке и проектировании программного обеспечения. Я надеюсь, что этот пост поможет прояснить некоторые производственные моменты, которые могли бы быть не совсем очевидны для разработчиков и их руководства.Суждения в данной статье субъективны — сплошная концентрированная «отсебятинка».Они основаны на моём личном опыте и опыте людей с которыми я общаюсь.
Далее многабукфЗаранее извиняюсь за сумбурность и слишком упрощённый характер повествования в статье.Я прекрасно понимаю, что тут много людей для которых слишком важны ложно-научные формальности и официальщина, так что можете просто не читать.Основными причинами конфликтов и организационных проблем являются Компенсаторные процессы психологических проблем Я хочу быть самым главным и/или самым умным… Позиция игрока-авантюриста, требует быстрого удовлетворения своих желаний и потребностей. Я хочу подчиняться… Позиция жертвы-мученика, требует получения страданий, а не каких-либо реальных выгод. …, а не разрабатывать качественные, конкурентоспособные и надёжные продукты Конечно, когда обе группы людей находят друг друга — они работают некоторое время, и даже способны выпускать продукты. Именно поэтому на территории СНГ не было выпущено вменяемых стартапов о которых можно было рассказать внукам, а большинство людей мигрируют — там часто принято решать проблемы интенсивно, а не игнорировать их, или попусту наращивать персонал, и само понятие проблемы по определению совсем другое. Впрочем, у нас тут и стартапом принято сейчас обзывать любой молодой мелкий бизнес в рунете, так что дожились, товарищи, дожились… В принципе, есть исключения, но можно посчитать на пальцах: Яндекс, ВКонтакт, Одноклассники да Mail.ru что-то в предсмертных конвульсиях задёргалось, да что-то делать начало за последние 5 лет. Это всё конторы, для которых свойственно интенсивное решение большинства проблем, и компенсироваться там сложно, из-за этого тоже возникают достаточно глупые ситуации.К сожалению, мы живём в больном постсоветском социуме с довольно примитивными книжными проблемами на которых ещё и принято зарабатывать кучу денег. Эти проблемы передаются из поколения в поколение, и это всячески поощряется окружением и чаще всего принято за норму.
1.1 Коммуникационные проблемы Чаще всего коммуникационные проблемы возникают из-заНеадекватной самооценки и неадекватных представлений о людях Разделения на «свой-чужой» Несоответствия ролей в коллективе Отсутствия ресурсов — времени или денег Первые три пункта — чаще всего, компенсаторные процессы, которые приводят к коммуникационным барьерам с последующими конфликтами. Недостаток ресурсов чаще всего приводит к изоляции и игнорированию существующих проблем без какого-либо желания руководства участвовать в процессе разработки продукта.Для фрилансера особо важно разобраться с коммуникационными проблемами уже на стадии выработки требований, или же сразу при первом знакомстве. Особенности рынка таковы, что больше половины коллективов строятся абсолютно стихийно и неадекватное поведение со стороны руководства — вещь абсолютно обыденная, а минимальное несоответствие уровней доверия или ожиданий приводит к достаточно большим конфликтам. В любом случае вопрос идентификации и разрешения коммуникационных проблем достоин отдельной статьи.
В случае с удалённой работой важнейшим фактором является равенство и распределение ролей. Для руководства важно проявлять внимание одинаково и для удалённых и для локальных сотрудников — делать ресурсы, результаты их работы и планы публичными и доступными для общего обсуждения, пробовать перекидывать локальных сотрудников на удалёнку и обратно для предотвращения социальной ингибиции.
Часто приходишь в коллектив и не понимаешь, чего люди свой хлеб едят — модель БД не нормализирована, лапша из «перестыкованного полтергейста» приправленная парой «божественных объектов» с «синглетонизацией» всего, тобой пытается руководить человек, который очень фанатично относится к своему творению и не способен выдержать какой-либо критики. Очень уж руководить ему хочется, а те, кто выше даже не проверяли его компетенции. Поэтому, я просто перестал работать с РНР проектами — процент дилетантов слишком большой.
Роли в коллективе могут меняться по мере реализации проектов и это можно использовать как дополнительное средство мотивации и укрепления сотрудничества.
Далее я рассмотрю пару основных когнитивных искажений с которыми мне приходится сталкиваться постоянно.
Я почти всегда ставлю крест на людях, которые настаивают на «первой личной встрече».Ввиду своего дилетантства их много раз кидали, но это совсем не значит, что подобного рода контингент готов учиться на своих собственных ошибках. Первая личная встреча означает, что им нужно создать позитивное впечатление, которым потом они будут компенсировать любые последующие раздражения из-за задержки сроков, отсутствия видимого результата и т.п. Они не хотят быть частью процесса, вникать в его составляющие и приложить усилия для того, чтобы получить продукт, который им действительно нужен. Им проще создать и поверить в иллюзию что «вот тот умный парень решит все мои проблемы за деньги», и вы сами прекрасно понимаете, что будет дальше…
Также я ставлю крест на проектах с фразами по типу «это всё очень просто, для профессионала это 2 часа работы» с копеечными бюджетами. Обычно так пишут дилетанты, которые верят в суперменов и оправдывают своё нищебродство. Конечно у них может быть какое-то техническое подспорье за плечами, и они сами могут что-то уметь, но если уж такие умные — пускай делают сами. Как бы вы не старались, до абстрактного супермена в вакууме вы в любом случае не дотяните, не оправдаете надежд, и это будет хорошим оправданием того, что вам платят копейки. Подобное мнение формируется, когда один дилетант встречает другого, и они очень поверхностно аргументируют сроки на реализацию каких-либо задач. Опять же, эти сроки срываются, не факт, что задача будет вообще решена…, но каша про простоту и 2 часа работы в мозгах остаётся на достаточно долгое время.
Люди не склонны проверять на практике навыки фрилансера о котором «кто-то сказал хорошо», либо который оставил хорошее впечатление человека способного «всё сделать за деньги», а таких на самом деле не бывает. Нужно помнить о потребности развития и пытаться понимать какой именно опыт нужен конкретному исполнителю, и зачем он здесь?… Сделать шаблонный проект, срубить денег, и побежать дальше?… Но кому нужны такие продукты? Они нужны жадным людям, которые в меру своей недоразвитости верят в иллюзию быстрой прибыли от публикации продукта любого качества, а что потом?… А потом объявления в стиле «доделайте то… доделайте сё… за 1000 руб. без документации и тестов». Выполняют подобные проекты люди, которые застряли на каком-то одном инструменте и не способны развиваться далее, как разработчик. Впрочем, часто они не способны развиваться и как личность.
Если люди не могут нормально общаться в онлайне, в живую они тоже не смогут этого делать.
Если не удаётся разрешить коммуникационную проблему — фрилансер просто «ливает».А вот сотрудникам сложнее: слишком много народу мысленно привязано задним местом к своему стулу.Соответственно фрилансеры, которые развивают свои навыки и не «застревают» на каких-либо специализациях, очень быстро учатся на организационных ошибках своего руководства. Но и подолгу на одном месте они не задерживаются.
Зрелая личность способна посмотреть на себя со стороны, попытаться оценить принятые решения и их последствия, осознать свою глупость и извлечь для себя какой-то опыт. А остальным нужно к психологу.
Хотя и психология сейчас развита не особо — открываются большие шарлатанские клиники, работающие по одному методу, который мистическим образом за деньги решает все проблемы, и где там эзотерика, а где психология ещё нужно разобраться. Терапия в некоторых особо запущенных случаях может длится около пяти лет. Одной таблеткой от всех болезней не вылечиться.
Отсутствие контроля качества Нет выработки требований Понятное дело, что любой заказчик начнёт с желания решить какую-то проблему разработав для этого конкретный продукт. Странно, но часто начинают не с постановки и формулировки конкретной задачи, и проблем, которые хотят решить, а с видения самого решения с точки зрения заказчика. К сожалению, не он собирает «авто», и не ему думать какие «формы», «металлы», «детали» и «соединения» подойдут для его задач лучше. Он же не ходил на автозавод и не рассказывал местным работникам каким должно быть его реальное авто. Он может сказать, что ему нравится, но это не означает, что именно это он получит в итоге — на его авто будут кататься другие, и им ни к чему «котики и радужные пони». Конечно, вы можете сказать «заказчик всегда прав», но зачем выпускать продукты, которые потом стыдно показывать? Понятно, что 80+ страниц ТЗ по ГОСТу для автоматизированных систем никто со старту не напишет, но требования к проекту могут меняться в процессе исследования рынка сбыта и целевой аудитории. Так что выработка требований — отдельный процесс разработки требующий прямой коммуникации с заказчиком и/или руководством, его нельзя осуществлять только одними лишь менеджерами, тут полезна любая точка зрения не только дизайнера или программиста, а может даже и ваших родственников, чем больше взглядов на продукт и задачи, которые он решает, тем точнее требования. Обратная связь от целевой аудитории является более релевантной, чем первоначальные требования, что приводит к последующей их эволюции. Обычно проходит 2–3 цикла выработки требований прежде чем они формулируются окончательно.
Форма требований может быть любой — вы можете вести пользовательские истории, а можете и просто записывать размышления на диктофон или снимать видеоролики, вести журналы, по которым потом будете переписывать или составлять пользовательские истории. В любом случае не стоит сильно привязываться к бумагам, нужно формализовать намерения целевой аудитории, а не способы их осуществления.
Вот так обычно проходит выработка требований[embedded content]
Зачем кому-то рисовать семь красных линий? Какую задачу пытаются решить таким образом? Для какой целевой аудитории предназначен подобный функционал?
Подобные вопросы решаются при выработке требований, а не заказчиком самостоятельно.Проблемы начинаются, когда заказчик мнит себя главным боссом способным правильно формулировать задачи.
Нет учёта выработки персонала Для руководства всегда нужно держать «руку на пульсе», и сложнее всего с внедрением средств контроля выработки персонала, не только фрилансеров, но и простых офисных и удалённых работников, понятное дело, больше 6ти часов в сутки никто в IDE’шке не протянет, а даже если и протянет — наверняка зря. Но даже эти 6 часов уже о чём-то говорят. Вы можете спокойно запустить у себя какой-то Harvest или RescueTime — результаты довольно интересные. Отлынивают все, а руководство — больше всех. Цифры — мотивируют. Нет тестов Для меня лично, печальнее всего частое отсутствие приёмочного тестирования, для проектов в 1–2 тела — это может сэкономить достаточно много времени. Щёлкаешь руками — себя не уважаешь. Приёмочные тесты также являются хорошим индикатором продвижения работы для руководителей. Если приёмочные тесты это must have и без них обойтись довольно сложно, то от функциональных (модульных), интеграционных и нагрузочных чаще всего приходится отказываться до первого релиза.Отсутствие тестов, это
экономия времени и ресурсов сейчас (около 20%), но большие затраты в перспективе, естественно с экспоненциальной зависимостью крест на поддержке продукта и BusFactor = 1 неспособность руководства думать о перспективах продукта, и давать гарантии клиентам.Скорее напротив, подобного рода руководство склонно делегировать ответственность сторонним вендорам, создавать vendor lockin и довольно замысловатые зависимости с кучей побочных эффектов. Хотя на самом деле, чем больше готовых неконтролируемых структур используется для поддержания работоспособности продукта — тем больше риск отказа его компонентов. Нет репозитория Если вы приходите работать, не важно или очередным сотрудником, или фрилансером- готовьтесь к большому гранитному осколку, с которого нужно будет лепить конфеты. Ну или не лепить, и давать давиться клиентам, возможно, даже с травматическим исходом. Если руководство интересует только прибыль — обычно так и происходит. Для того чтобы пилить гранит, нужно как минимум приёмочные и функциональные (модульные тесты) с репозиторием исходников. Переписывать чаще всего приходится и тесты, и код параллельно выработке требований. Естественно, без детальной истории всех изменений, даже одному человеку, это бывает довольно сложно. Нет аудита существующих решений Нужно понимать сколько людей — столько и взглядов на проблему, и это хорошо. Аудит существующего решения в рамках конторы может принести много новых плодотворных идей и решать достаточно большое количество проблем. Чем больше человек «проходится» по коду — тем он чище, и как минимум не будет спагетти-кода, bloatware и pattern-hell. Нет рефакторинга Никто не пишет идеальный код с идеальной архитектурой с первого раза. Если такое случается, то быстрее всего человек уже решал проблему ранее и сталкивался с какими-то её аспектами, но и в этом случае у него придёт идея «как можно было сделать лучше», и не позволить ему это сделать — убить доверие и потенциал проекта. С другой стороны, без аудита со стороны подобные решения заканчиваются кодом «Паблика Морозова» в котором кроме его автора никто разобраться толком не может.Разработка программного обеспечения — это рекуррентный процесс. Вообще по ГОСТу для автоматизированных систем всего 2 итерации: эскизный и технический проект, потом идёт разработка проектной документации. Хотя на практике обычно нужно 4–5 прежде чем продукт можно будет спокойно использовать и поддерживать. Для рефакторинга обязательно наличие тестов и репозитория.
Нет аудита ресурсов и соответствующей оптимизации расходов/доходов Люди не умеют получать прибыль с продукта, оценивать риски, и тратить всё с умом. Нет смысла закупать 100 серверов по 64Гб памяти в каждом и с б/у винтами по 500Гб в RAID-10, когда у проекта всего три десятка клиентов. Нет смысла экономить на организации процессов, но любые решения, принимаемые без обсуждения и аудита со стороны, подразумевают под собой какие-то риски, нужно брать эти риски в расчёт, иначе деньги пускаются «на ветер».Нет смысла хранить весь мёд в одном горшке — получать деньги в долларах в Европейский банк, перегонять их в рубли, потом опять в доллары для того чтобы рассчитаться за очередную услугу.
Нет вещей, которые можно купить и получить прямо сейчас.В любом расходуемом ресурсе или услуге нужен запас, или возможность компенсации его отсутствия на время доставки. Нужно проводить комплексные оценки рисков, с построением графа зависимостей всех ресурсов.
Отсутствие отработанной методологии разработки Я недавно писал почему SCRUM не очень подходит для постсоветского пространства. И причиной тому как раз-таки психологические проблемы и компенсаторные процессы. Люди заменяют процесс анализа обсуждениями, а предположения принимают за факты. Это тоже различные случаи когнитивных искажений при принятии решений.Получается «Собрание ради собрания», «Код ради кода».Нужно понимать, что методологии нужно адаптировать к конкретному коллективу и подбирать под конкретный проект.Методологии придумали не менеджеры, методологии придумали маркетологи — это ещё одна «красивая конфета» для руководства неспособного руководить, и которому нужны гарантии со стороны, что эта «конфета» решит все их проблемы. Так было разработано достаточно большое количество сокращений с трёх-четырёх букв, на стандартизации и выпуске сертификатов которого люди зарабатывают миллионы.
Хватит орать «у нас тут Agile», Agile это четыре забавных правила, к которым все хотят стремиться для повышения качества ПО и счастья разработчиков… Agile методологии — это набор абстрактных методов, которые можно использовать для достижения целей Agile. Но это не означает, что они будут работать для вашего коллектива.
Нужно начинать с чего-то малого — возьмите V-model и адаптируйте его к Lean c Kanban’ом.Вместо того чтобы строить высоко-рекуррентные процессы, выполняйте всего 2–3 задачи одновременно по принципу «разделяй и властвуй», а потом, когда закончите 2–3 проекта, уже можно играться со всякими SCRUM’aми. Из документации достаточно пользовательских историй, описания модели БД, описания сервисов в SOA, тестов, и схемы API в ком-нить Swagger’e или JSON-WSP.
Организационные антипаттерны Аналитический паралич — выработка абстрактных спецификаций ставится выше разработки даже самой сырой реализации продукта. Выработка требований и реализация — рекуррентные процессы, и пытаться «проглотить слона не пережёвывая» довольно глупо. Миграция расходов — передача задачи оптимизации расходов потенциально уязвимому партнёру или подразделению, которое может быть в этом не заинтересовано. В общем любой подрядчик будет заинтересован больше в оплате труда, нежели в гарантии того, что какой-либо продукт будет разработан и завершён вовремя. Дойная корова — деньги должны приносить деньги, не стоит всё «проедать», тратьте прибыль с проектов на реализацию более масштабных. Нет ничего вечного. Непрерывное устаревание — портирование плохо структурированного legacy кода из-за смены условий или требований к проекту заканчивается ужасными расходами и задержками сроков. Это, наверное, наиболее типичный антипаттерн для существующих костыльных проектов в которых «зачем переписывать, а мы что зря свой хлеб ели?». Ползучие улучшения — внедрение нового функционала без переработки уже существующего приводит к большему количеству побочных эффектов и «детонаторов» в коде. Разработка комитетом — проектирование без централизованного и компетентного руководства. Такое встречается в 80% проектов в СНГ и в Европе. Много народу собирается и «тыкают пальцем что популярно, туда и двигают», ничего не меряют и не анализируют, принимают решения в стиле «если это использовалось в большом проекте, и оно там работает, значит это будет работать и у нас». В итоге получается «много, но дурного» и bloatware. Я же тебе это говорил — игнорирование мнения эксперта руководством. Такая ситуация возникает, когда подчинённые более компетентны, чем руководство, и вместо смены ролей возникает конфликтная ситуация — для руководства важны только те решения, которые они принимают самостоятельно. Это делается для того, чтобы компенсировать внутреннее напряжение, которое возникает из-за чувства неполноценности. Эскалация преданности — продолжение поддержки устаревших решений, даже если доказана их неприспособленность к текущим задачам и показаны существующие ошибочные решения. Не важно насколько далёко вы зашли по неверному пути, важно развернуться и двигаться прямо сейчас в правильном направлении. Менеджмент числами — внедрение избыточного количества поверхностных метрик, целесообразность которых под большим вопросом. Любят руководители и менеджеры для имитации деятельности и оправдания своей полезности. Vendor lock-in — отсутствие адаптеров для различных вендорных решений, очень сильная связанность с их функционалом. Как говорится, «никого ещё не уволили за покупку софта IBM». Особенно это касается решений на основе Oracle и Microsoft — перейти на OpenSource потом бывает довольно сложно. Грибной менеджмент — отсутствие вменяемой выработки требований с последующим требованием решения различных задач, которые непосредственно к проекту не имеют большого отношения и быстрее всего будут переписываться наново. Случается, из-за бездарности руководства, которое не способно рассмотреть и принять любые варианты реализации кроме своих собственных. Обычно подобное потом ещё нужно 2–3 раза переписывать и покрывать тестами. Мой самый ненавистный случай. Одна знающая голова — это когда один человек в проекте более-менее разбирается во всех процессах и принимает аргументированные решения, а все остальные просто наблюдают. Без нормальной документации это BusFactor == 1. Если ещё человек раздувает свою значимость, то он превращается в антипаттерн «рыцарь в сияющих доспехах», даже когда он принимает довольно глупые решения все продолжают кивать головой в ответ. Архитектурные антипаттерны Я не хочу копировать вики или лурку. Но в общем, проблема в том, что люди застревают на определённом этапе развития и инструментария, не отрабатывают даже самые распространённые шаблоны проектирования. Я уже не говорю о разнице между proactor’ом и reactor’ом, или о таких монстрах как CQRS-ES. Но пару книжек о шаблонах по любому надо прочитать и сразу же реализовать всё на практике и покрыть тестами, иначе толку реально мало.Веб стал асинхронным, может неравномерно, но всем скоро придётся с этим смириться. Мобильные и десктоп приложения всегда должны были быть асинхронными, возможно, мы не всегда это понимали, так как не было хороших инструментов и требования рынка были в разы меньше чем сейчас. Сам вопрос асинхронности, реактивности и реактивных расширений в рамках CQRS-ES, и как это всё потом подружить с SOA, достоин отдельной статьи.
Я считаю, что архитектура асинхронных многопоточных приложений должна быть отработана всеми разработчиками, которые хотят выпускать конкурентоспособные продукты в следующие пару десятков лет. Другое дело, что это сплошная головная боль, особенно отладка и тестирование…
Если вы попадаете в проект, то первое на что стоит обратить внимание это
Нормализация модели БД — пятая/шестая форма это уже MustHave, а не «третей формы хватит всем» как и 640Кб оперативки Менеджмент зависимостей — Composer / pip / Bundler / Gradle / npm / bower… это то что должно быть в любом проекте. Непрерывное внедрение — если проект раздроблен на кучу мелких сервисов, нужно постоянно тестировать их взаимодействие и разворачивать тестовые сборки. Разворачивание инфраструктуры и мониторинг — возможность настроить сервер для определённого сервиса за минимальное время очень ценна. Сейчас немного поменялись тенденции в мониторинге инфраструктуры — люди слезли с Zabbix/Nagios на Kibana и индексируют логи с logstash/fluentd в ElasticSearch. Мониторинг является средством обратной связи для осуществления горизонтального масштабирования и определения недостатка существующих ресурсов. Профилирование решения — мерить скорость работы и потребление ресурсов отдельных модулей нужно постоянно. Не думайте, что если у вас есть проект на ноде и вы перепишите критические участки на сишку это будет быстрее — меряйте, меряйте и ещё раз меряйте. Как же это всё обычно происходит? Рассмотрим круговорот разработчиков в природе, основные причины миграций флоры и фауны, а также наиболее распространённые инструменты и задачи для каждого из этапов.Концентрация «отсебятины» очень сильно «зашкаливает», можете просто прочитать пункт »3» из этого списка и перейти к его концу, если влом читать.
Базовые знания технического ВУЗа неподкреплённые реальной практикой
На уровне третьего курса Компьютерной Инженерии (КИ), Компьютерных Наук (КН) и Программной Инженерии (ПИ) или даже Автоматизированных систем управления (АСУ) и Телекоммуникационных систем (ТС), к сожалению, большинство преподавателей не объясняют в чём же разница между родственными кафедрами, даже если больше половины основных предметов совпадает. В случае с «некомпьютерными кафедрами», которые делают упор на проприетарные решения, Vendor Lockin и пустую теорию, ситуация довольно прискорбна — люди чаще всего много знают, но применить на практике, и адаптировать к существующим процессам разработки, свои знания не могут. Большая часть абитуриентов поступает «потому что престижно», а не потому что «я знаю, что я хочу делать, и как я помогу этим другим», и это довольно прискорбно.Бывают и исключения из правил, и особо фанатичные школьники пилят Сишку с самодельными ATMEGA8 платками (TQFP, а не DIP), ЛУТ'ом, и простыми 0805 SMD компонентами. Arduino — часть POP-культуры, да и довольно дорогая, так что обычно проходит мимо. А уже к 1–2 курсу подобный контингент легко и непринуждённо осваивает Cortex-m0, Cortex-m3 и даже Cortex-A5 A9 и ARMv7 ARMv9. В таком случае часто развиваются навыки администрирования и приход к OpenSource софту возникает в возрасте 15–16 лет. Чаще всего склоняются в сторону ArchLinux или же более дружественных Ubuntu/Mint (если у них были деньги на Arduino). Если же этот период не был пройден «в школе», то он затягивается до 3его 4 го курса университета, а заканчивается всё работой в каком-то более-менее престижном аутсорсе.
Чаще всего школьники и студенты идут в сторону вёрстки и разработки простых сайтов на популярных CMS, естественно особым качеством или стабильностью подобные решения не отличаются, но определённую целевую аудиторию они имеют. Навыки администрирования чаще всего на уровне «могу поставить LAMP чтобы работало».
В принципе у школьников все это протекает довольно хаотично, и что попадёт под руку, то и будет прочитано…Первым школьным холиваром является «лучший язык программирования», или «лучший фреймворк/СMSка». К сожалению подобным вопросом задаётся очень большое количество дилетантов. Правда такова, что идеального решения нет — пробуйте всё, тогда вы сможете подобрать какой-то один более подходящий инструментарий для конкретных условий и задач определённого проекта. Верить, что ваш любимый SomeRandomName фреймворк подходит для всего — наивно и достаточно рискованно для заказчика, это детский антипаттерн «golden hammer», и через это все проходят рано или поздно.
Обычно люди в этом периоде читают книжки, статьи, заводят свои игрушечные проекты, изучают что-то новое.К этим занятиям очень часто возвращаются во время работы, или во время смены места работы, по самым различным причинам, которые будут описаны далее.
Проблема в том, что не всегда можно найти людей, у которых можно было бы действительно чему-то поучится, но как показывает практика доступность информации в наше время почти нивелирует эту проблему. Важно не только получать информацию, но и реализовывать какие-то простые вещи для закрепления. Велосипеды можно писать, когда вы, к примеру, знаете большую часть популярных инструментов самых разных платформ, и точно уверенны, что делаете что-то новое и оно будет лучше того, что есть. Мысль в одну голову не приходит — всегда найдётся что-то готовое, лучше 300 раз проверить, чем тратить своё собственное время, а иногда из-за предрассудков и время заказчика/руководства.
Обычно люди начинают реализацию первых проектов на
Wordpress / Drupal / Joomla C# WinForms ASP.NET C++ Qt Python Django PHP Yii / Symfony2 / Zend / CakePHP / Kohana html5/css3/js jQuery Angular node.js Express.js / Sails.js + mongodb А вот с java сейчас почти никто не начинает :(Ну по крайней мере я как-то не заметил за последние 3 года, хотя язык достаточно простой.На данном этапе люди ещё не понимают на сколько важно тестирование, как обеспечить качество и долгосрочную поддержку, плохо ориентируются в существующих паттернах проектирования и типичных сервисах сервис-ориентированной архитектуры. Довольно часто одной из проблем является нормализация/денормализация моделей БД, ведение статистики на атомарных счётчиках и менеджмент зависимостей приложения.
С этого места начинается фриланс, возможно, даже удалённая работа.
Проект, где есть чему поучиться
Если человек развивает свои навыки самостоятельно, разрабатывает собственные решения и проводит их аудит, то такое случается нечасто. Главной особенностью подобных проектов является наличие сформировавшегося коллектива, возможно, даже стихийного. Любые компенсаторные процессы замедляются ввиду интенсификации процессов разработки, но они не останавливаются и часто выражаются в виде не самых приятных «обрядов посвящения» новичков.В данном случае возможны две причины возникновения конфликтных ситуаций:
Нарушение сформировавшейся идиллии новыми подходами и инструментами. Существующие решения ценятся слишком высоко, в том числе и организационные. Предложения оптимизации или критика не могут восприниматься адекватно*. * адекватность вообще очень популярное слово в последнее время, никто не знает, что оно значит, но все разбрасываются — понимают, что ситуация с психологическим здоровьем людей довольно печальна, а заняться своими проблемами мозга не у всех хватает. В данном случае я подразумеваю неадекватное поведение индивида из-за когнитивного искажения.Нянчиться никто не любит, но и «грибной менеджмент» в «дымоходе» тоже не самая хорошая ситуация — публичность существующих ресурсов и процессов позволяет избежать её. Главное — помочь руководству понять разницу между достаточным количеством информации о проекте и её недостатком или отсутствием.
Главная проблема сформировавшихся коллективов — это «обряды посвящения» и другие «производственные ритуалы». Налаживание социальных связей может быть довольно сложной задачей. В идеале у всех членов коллектива и руководства должна возникать взаимная эмпатия, а реализация существующих задач — приводить к удовлетворению, даже если эта работа не имеет отношения к конкретным индивидам. Но это просто утопические коллективы, слишком уж сильно повседневные проблемы влияют на работу.
Знания нужно заслужить, так как разбираться самому в большинстве случаев довольно трудно и нужен более-менее компетентный человек для поддержки.
Из инструментариев сейчас очень популярны:
Angular React и сборка фронтенда на основе gulp + browserify/webpack node.js решения на основе express.js / sails.js, и socket.io / sock.js для коммуникации Play2 и Typesafe stack, иногда Xitrum ElasticSearch и Kibana c logstash/fluentd PHP / Python / Ruby на сегодняшний день плохо подходят для современных требований рынка, с его реактивностями, RESTful сервисами, богатым фронтэндом, push-нотификациями на сайты и в мобильные приложения. Исключением являются порты под JVM, типа jRuby с их оптимизированным компилятором на уровне Project Graal. Вот про производительность Jyton’a ничего не знаю, так что ничего не могу сказать. Groovy тоже сейчас довольно шустрый, но вот от J2EE сервлет-бутербродов я испытываю глубокое отвращение.В десктопе сейчас в принципе ничего нового, Qt да .net правят балом.Java и Air всё реже используется для десктопа, хотя я лично в восторге от JavaFX2.
Люди, которые начинают разрабатывать мобильные приложения, обычно начинают не с них, это либо различные J2SE, а не J2EE, Java проекты после которых переходят на Android, либо это различные сайтики на джанге, рельсах и ноде после которых переходят на Objective-C / Swift и разработку под яблоки. Поэтому именно с этого момента начинается разработка мобильных приложений, у людей должен быть средний достаток чтобы стабильно начать разрабатывать под различные мобильные платформы, да и навыков в дэсктопе и вэбе должно быть достаточно много.
В принципе, в подобных проектах можно работать достаточно долго, и получать очень хороший опыт. Но когда возникают мелкие конфликты из-за проблем менеджмента и организации — люди чаще всего идут «дальше учиться», бывает, что и остаются работать «как есть и терпят недовольство». Подавление любых конфликтов приводит к компенсаторным процессам и когнитивным искажениям, которые в свою очередь не очень хорошо отражаются на работе. Для хорошего руководства важно понимать, когда и кого отправить на переобучение всех премудростей, обеспечивать материалами и возможно даже менторами. А от плохого люди обычно сами убегают.
Опять же нужно понимать, что деньги людей в таких проектах почти не мотивируют.И вопрос мотивации решается личностным и профессиональным развитием.
Проект «мясоперерабатывающий цех»
Для подобных проек
