Справедливо написали, но на первых порах фрилансер вынужден взяться за любые заказы, чтобы выжить. Фильтровать заказчиков он может, если ему каждый день приходят 5-6 обращений от крупных заказчиков.
Абсолютно правильно. Клиент не разбирается так хорошо в этой области, чтобы предложить правильное решение. Если пытаться во всем удовлетворить клиента, можно получить откровенно провальный проект.
Очень правильно заметили, на фрилансе практически не обращают внимание на качество кода. Заказчику абсолютно всё равно (99 процентов случаев) какой код ты пишешь, главное, чтобы он кликал и всё безупречно работало. Этим и они оценивают работа выполнена качественно или нет. А про тесты вообще не говорю, их практически нет. Мне часто кидают проекты на доработку и ни в одном проекте я не видел тестов. А когда ты скажешь заказчику, что он должен уделить деньги на тесты и рефакторинг, он вообще будет возмущаться — "что это вообще такое, давай как-нибудь без этого".
Будучи фрилансером, я понял, что не могу считать себя полноценным программистом, если не буду знать о таких вещах как SOLID, парадигмы ООП и техники написания хорошего кода. Я всё это изучил самостоятельно. С одной стороны это круче, нежели, когда кто-то тебя учит. Но, к сожалению, это всё не получается применить в проектах, где от тебя требуют делать быстро, недорого и условно качественно. Почему условно, потому что под качеством обычно понимают отсутствие багов, а не хороший код.
Я понял, что уже перерос фриланс и хочется получить серьезный опыт, например, с микросервисами, высоконагруженными проектами и DDD (почему бы и нет). Но компании часто требуют коммерческий опыт, то бишь, опыт работы в компании, которого у меня нет.
Но, если смотреть с другой стороны, если получится выйти на крупных заказчиков, это лучше, чем в штате работать. Но опять же, в этом случае у тебя уже должна быть своя команда.
Немного с вами не согласен, что на фрилансе только маленькие заказы. Вот я разработал два крупных портала на фрилансе. Но опять же, заказчики хотели получить результат быстро. Потому что это стартап с непонятной перспективой. Никто не хочет вложиться в то, чего завтра может и не быть.
Не думаю, что во всех компаниях следуют хорошим практикам разработки, особенно, когда это аутсорс. Но в любом случае нужно выбрать компанию, где налажены эти процессы.
Я однажды спросил цену рекламного поста у админа Телеграм канала, а он сразу спросил меня, куда мне удобно оплатить) Но я просто хотел узнать цену, с чего он так был уверен, что цена меня устроила, интересно.
Если ты выполнил одну и ту же услугу миллион раз, ты можешь с точностью сказать сроки. И, если в этом случае ты нарушаешь их, проблема в самодисциплине. То, что вы описали в статье больше про стандартные услуги.
Но, если работа нетривиальная, очень сложно с точностью оценить сколько часов уйдет у тебя на выполнение. Можно только прикинуть примерные сроки.
Одно маленькое ТЗ может увеличиваться в размерах, когда начинаешь расспрашивать, что и как. Когда кидают ТЗ и просят оценить, даже не представляют, что для точной оценки может потребоваться очень много времени.
В общем, я пришел к тому, что оценка ТЗ должна быть отдельной услугой, в которую ещё входит составление более подробного ТЗ.
Например, в веб-разработке, особенно в сложных проектах сроки относительное явление. Разрабатывая нетривиальный функционал, ты заранее не знаешь с какими подводными камнями будешь сталкиваться и сколько времени потребуется на их преодоления. А вот, если большую задачу разделить на маленькие, немного легче будет оценивать.
Да, но вот я имею в виду, что это быстро в самом начале. Понятное дело, что в дальнейшем такой код будет тормозить разработку. Но условно говоря, если тебе надо написать какую-то логику и больше не трогать этот контроллер какое-то время, это будет быстро. Например, написал MVP для того, чтобы проверить гипотезу, потом, если уже понял, что проект представляет коммерческий интерес, переписал всё используя хорошие практики.
В принципе, в экстремальных условиях, когда очень сжатые сроки, профессионал вынужден писать плохой код. Когда есть постоянное давление со стороны менеджеров или заказчиков, очень сложно применить все хорошие практики.
Согласитесь, что всё хреначить в контроллере получается быстрее, чем, если вывести бизнес-логику на другой уровень абстракции и обдумать архитектуру. И таких примеров можно привести много.
Наверно, в начальном этапе стартапам выгоднее нанимать говнокодеров, нежели профессионалов. Поэтому и чаще они их нанимают, потому что их час работы стоит дешевле.
Думаю, многие стартапы идут путем переписывания спагетти-кода и выстраивания процессов, когда стартап уже выстрелил. Потому что написание плохого кода по-быстрому в начальном этапе обходится дешевле. В начале для создателей стартапа самая приоритетная задача, это когда кликаешь всё заработало. А об улучшении системы задумываются только, когда начинаются проблемы и торможения.
Справедливо написали, но на первых порах фрилансер вынужден взяться за любые заказы, чтобы выжить. Фильтровать заказчиков он может, если ему каждый день приходят 5-6 обращений от крупных заказчиков.
Абсолютно правильно. Клиент не разбирается так хорошо в этой области, чтобы предложить правильное решение. Если пытаться во всем удовлетворить клиента, можно получить откровенно провальный проект.
не переживайте, многие клиенты на фрилансе вполне комфортно чувствуют себя в роли эксплуататора)
Что вы понимаете под "разносторонним", можно подробнее?)
Очень правильно заметили, на фрилансе практически не обращают внимание на качество кода. Заказчику абсолютно всё равно (99 процентов случаев) какой код ты пишешь, главное, чтобы он кликал и всё безупречно работало. Этим и они оценивают работа выполнена качественно или нет. А про тесты вообще не говорю, их практически нет. Мне часто кидают проекты на доработку и ни в одном проекте я не видел тестов. А когда ты скажешь заказчику, что он должен уделить деньги на тесты и рефакторинг, он вообще будет возмущаться — "что это вообще такое, давай как-нибудь без этого".
Будучи фрилансером, я понял, что не могу считать себя полноценным программистом, если не буду знать о таких вещах как SOLID, парадигмы ООП и техники написания хорошего кода. Я всё это изучил самостоятельно. С одной стороны это круче, нежели, когда кто-то тебя учит. Но, к сожалению, это всё не получается применить в проектах, где от тебя требуют делать быстро, недорого и условно качественно. Почему условно, потому что под качеством обычно понимают отсутствие багов, а не хороший код.
Я понял, что уже перерос фриланс и хочется получить серьезный опыт, например, с микросервисами, высоконагруженными проектами и DDD (почему бы и нет). Но компании часто требуют коммерческий опыт, то бишь, опыт работы в компании, которого у меня нет.
Но, если смотреть с другой стороны, если получится выйти на крупных заказчиков, это лучше, чем в штате работать. Но опять же, в этом случае у тебя уже должна быть своя команда.
Немного с вами не согласен, что на фрилансе только маленькие заказы. Вот я разработал два крупных портала на фрилансе. Но опять же, заказчики хотели получить результат быстро. Потому что это стартап с непонятной перспективой. Никто не хочет вложиться в то, чего завтра может и не быть.
Не думаю, что во всех компаниях следуют хорошим практикам разработки, особенно, когда это аутсорс. Но в любом случае нужно выбрать компанию, где налажены эти процессы.
Насчет бирж правильно сказано.
Я однажды спросил цену рекламного поста у админа Телеграм канала, а он сразу спросил меня, куда мне удобно оплатить) Но я просто хотел узнать цену, с чего он так был уверен, что цена меня устроила, интересно.
Если ты выполнил одну и ту же услугу миллион раз, ты можешь с точностью сказать сроки. И, если в этом случае ты нарушаешь их, проблема в самодисциплине. То, что вы описали в статье больше про стандартные услуги.
Но, если работа нетривиальная, очень сложно с точностью оценить сколько часов уйдет у тебя на выполнение. Можно только прикинуть примерные сроки.
Верно. В принципе этим и можем закрыть тему)
Одно маленькое ТЗ может увеличиваться в размерах, когда начинаешь расспрашивать, что и как. Когда кидают ТЗ и просят оценить, даже не представляют, что для точной оценки может потребоваться очень много времени.
В общем, я пришел к тому, что оценка ТЗ должна быть отдельной услугой, в которую ещё входит составление более подробного ТЗ.
А ещё сложнее работать с заказчиками, которым задача нужна была ещё вчера)
Например, в веб-разработке, особенно в сложных проектах сроки относительное явление. Разрабатывая нетривиальный функционал, ты заранее не знаешь с какими подводными камнями будешь сталкиваться и сколько времени потребуется на их преодоления. А вот, если большую задачу разделить на маленькие, немного легче будет оценивать.
Да, но вот я имею в виду, что это быстро в самом начале. Понятное дело, что в дальнейшем такой код будет тормозить разработку. Но условно говоря, если тебе надо написать какую-то логику и больше не трогать этот контроллер какое-то время, это будет быстро. Например, написал MVP для того, чтобы проверить гипотезу, потом, если уже понял, что проект представляет коммерческий интерес, переписал всё используя хорошие практики.
В принципе, в экстремальных условиях, когда очень сжатые сроки, профессионал вынужден писать плохой код. Когда есть постоянное давление со стороны менеджеров или заказчиков, очень сложно применить все хорошие практики.
Согласитесь, что всё хреначить в контроллере получается быстрее, чем, если вывести бизнес-логику на другой уровень абстракции и обдумать архитектуру. И таких примеров можно привести много.
Наверно, в начальном этапе стартапам выгоднее нанимать говнокодеров, нежели профессионалов. Поэтому и чаще они их нанимают, потому что их час работы стоит дешевле.
Думаю, многие стартапы идут путем переписывания спагетти-кода и выстраивания процессов, когда стартап уже выстрелил. Потому что написание плохого кода по-быстрому в начальном этапе обходится дешевле. В начале для создателей стартапа самая приоритетная задача, это когда кликаешь всё заработало. А об улучшении системы задумываются только, когда начинаются проблемы и торможения.
Кстати, есть решение, чтобы переключаться на пользователя, для которого не предусмотрен логин.
Ну почему нет домашней директории. Для
www-dataключ создается в /var/www, там и можно конфиг файл гита создать.Согласен
Супер
Да, тоже можно. Но разве это не займет больше времени, чем мой вариант?
Ну пусть будет не рут, а другой пользователь. От этого суть не меняется.