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