Можно долго ссылаться на различные причины, которые мешают выполнить условия GPL лицензии. А можно хотя бы
Не работать в плохих компаниях.
Потому что можно сколько угодно ругаться на ужасные компании, тот же Роскомнадзор, но ведь находятся же ИТ-специалисты, которые там работают. Хотя, казалось бы, выбор компаний огромен — выбери компанию получше.
А у бизнеса принцип простой — если телега едет, деньги капают, то зачем что-то менять?
В компаниях, где я работал, обертка над тестами в виде Codeception была по умолчанию — чтобы в случае необходимости добавить приемочные тесты — их можно было легко добавить без дополнительных настроек.
Меня спросили всего один вопрос — «знаю ли я, что такое SQL?». Несмотря на то, что я слышал это слово первый раз, я с уверенностью сказал — «Конечно знаю, у меня даже в дипломном проекте был SQL».
Моя зп в Амазоне выросла на 10% за 5 лет
Удивительно, но люди, которые выбирают путь «казаться, а не быть», сами в итоге становятся жертвами чужих «вау-образов» (работать в Amazon/Google/Facebook это же так круто!)
Еще бы добавил, всем, кто считает, что «много/немного врать» это нормально — ваша ложь работает только на тех, кто сам плохо разбирается в теме. Соответственно идя по этому пути вы попадаете в заведомо слабые команды.
И по поводу работы Amazon/Google/Facebook и прочих — мне кажется, что работать там имеет смысл только годик-два, чтобы получить в свое резюме строчку «работал в Google», что резко выделяет вас на фоне остальных кандидатов. С точки же зрения денег и комфорта — небольшие компании, на мой взгляд, готовы и платить больше, и ценят своих сотрудников лучше. Потому что к ним, в отличие от «хайповых» компаний, не стоит очереди из желающих.
Читал эту книгу, там про другое — про то, что если одному программисту делать проект год, то нельзя утверждать, что 12 программистов сделают этот проект за месяц. А также про такой интересный эффект, когда добавление новых программистов под конец разработки не ускоряют, а замедляют релиз.
Наблюдаю такой интересный эффект, не встречал, чтобы его кто-то научно описал, но он точно есть.
Его суть в том, что чем больше людей работает над проектом, тем меньше каждый из них отвечает за проект в целом и, закономерно, заинтересован в проекте в целом (зачем забивать себе голову тем, что не является твоими должностными обязанностями). Простыми словами: в команде из 2 человек каждый из них, условно, отвечает за 50% проекта и несет ответственность в размере 50%. Когда на проекте 1000 человек — то конкретно каждый отвечает лишь за очень-очень небольшой кусочек, и может делать его отлично, но вот за проект в целом, уже как бы никто и не отвечает (или люди, которые, казалось бы должны отвечать — думаю в основном о деньгах)
И нередко получается, что проект сделанный одним человеком и лучше и качественнее проекта, который делало 50 человек.
Лучше не участвовать в разработке в единственном лице. Это не только минус для самого разработчика: будете вариться в собственном соку, но и риск для бизнеса — программист может изображать видимость работы, а потом, за пару месяцев до релиза уволиться. А новый программист услышав «тут почти все готово, осталось немного доделать» скажет, что «тут вообще все переделывать надо, с этим невозможно работать».
Даже если все хорошо, и программист и бизнес довольны, выйдя с такой работы на рынок лет так через 5… может оказаться, что ваши подходы к разработке полностью устарели и вы «неликвид».
А гуманитарии от программистов часто ожидают именно волшебства. Вот есть крупный продукт, который 10 лет писали абы как, забивая на чистый код, авто-тесты и технический долг, а потом ждут, что вот придет новый крутой программист, сделает «вжух» и все проблемы исчезнут.
И это самое неприятное — объяснять людям, что магии не бывает.
А если эти сотни тысяч багов — минорные глюки, которые проявляются в очень специфических условиях?
И это как раз самая проблема.
Баг, который легко воспроизводится со 100% шансом — это просто. А вот баг, который появляется раз в месяц, при непонятно каких условиях (слишком много входящих и сложная логика), и непонятно как его воспроизвести — вот это жопа.
Такие темы нужно поднимать. И проблема не только в уровнях абстракций.
Сейчас все больше и больше проектов микросервисные, и работают не только в рамках своей компании, но и завязаны на внешние API.
А так как везде разработка идет в формате «быстрей-быстрей, сроки горят» (исключения лишь подтверждают правило), то в каждом API есть баги, которые… Начинают перемножаться. Имеете 3 API с 3 ошибками, которые завязаны друг на друга — получите ~27 кейсов с багами. А если больше?..
Еще больший бред начинается тогда, когда ошибки одного API приходится исправлять через изменение другого API. Получаем дополнительное усложнение (с потенциальным ростом ошибок) на ровном месте.
Одному мне показалось странным то, что нигде не сказано о том, что по важность производительности можно узнать у самого заказчика, в самом начале разработки?
Я не вижу никаких проблем ни у себя, ни у окружающих программистов сделать какую-угодно прихоть клиентов:
Хотите быстро — пожалуйста
Хотите надежно — пожалуйста
Хотите производительность — пожалуйста
Проблемы начинаются там, где программистов в первый год разработки только гонят по срокам реализации новых фич, а потом, через год, начинают спрашивать «а почему так много багов?», «а почему все так тормозит?» и у программистов, почему-то, не хватает смелости сказать очевидную вещь: а что хотели, то и получили!
Есть даже такой классический развод «функционал бонусом», когда в ТЗ указано 10 пунктов, а потом, в процессе, заказчик хочет еще 5 пунктов за те же деньги и сроки, и доказывает, что они «само-собой разумеющиеся». Детская разводка, которая, к сожалению, очень часто срабатывает.
Но факт в другом — человек, который поддается на разводы, в любом случае будет виноватым. Каким бы он не был классным, сколько бы выходных он не проработал сверхурочно.
Был знакомый, который сумел выбить себе 3 оклада, за согласие уволиться. Но, от момента «уволься под собственному», до «на тебе три оклада — покинь уже нас» прошел месяц жесткого прессинга, который далеко не каждый выдержит.
Если ты отличный специалист, за которым стоит очередь из HR (а еще хватает мозгов не брать кредиты и иметь запас денег) — то вообще непонятно, зачем бодаться с работодателем. Не понравились друг другу — разошлись, нашли нового.
В популярных пакетах такое редко встретишь, а вот во внутренних модулях компаний — постоянно. До банального указания обязательных зависимостей не через конструктор, а через отдельный метод.
P.S.
И это гораздо хуже, чем спагетти — потому что спагетти мы можем отрефакторить и что-то нормальное в результате получить. А чтобы получить что-то нормальное из такой лазаньи, её надо сначала растерзать и превратить в понятные и очевидные спагетти, а потом заново собирать лазанью, только уже правильную.
Еще раз убеждаюсь, как же сложно написано. Моя аналогия, которая, мне кажется, намного понятнее:
Ситуация №1: Неопытный программист пишет код как получается: получаем лапша-код, объекты, которые не объекты, а просто классы по которым как-то распиханы данные и методы для работы с этими данными. Его код плохой, но понятно как его рефакторить (потому что все когда-то так писали, и переписывали свой код)
Ситуация №2: Неопытный программист начитался умных книжек про паттерны, DDD и прочее, и начинает внедрять их на рабочем проекте. В результате его код получается сильно хуже, и намного более переусложненным, чем в ситуации с первым программистом.
Мораль проста: все новое лучше вначале проверять «на кошках» — на каких-то небольших и неважных проектах (например, на домашних), и только после обкатки (которая может занять и год и больше), и когда уже набился шаблон и этот шаблон проверен временем — уже внедрять в рабочих проектах.
P.S. И как хорошо где-то сказано: задача тимлида не в том, чтобы говнокода в проекте не было, а в том, чтобы этот говнокод не растекался — т.е. создать такие условия, чтобы говнокод каждого конкретного рядового программиста был как-то изолирован в себе (через вынесение в микросервис, или в модуль с отдельным неймспейсом, с указанным тимлидом интерфейсом использования, или как-то по другому — уже не суть)
Как-то все очень сложно описано. Примерно понимаю о чем написано, но человеку, который пока пишет код на уровне Yii2 эта статья, как мне кажется, никак не поможет научиться писать код лучше.
А что поможет? Мне сильно помог такой вариант:
1. Берем, и начинаем писать в свое свободное время какой-то большой проект-монолит. В свободное время — чтобы вас никто не подгонял со сроками, монолит — потому что только в монолите с сотнями моделей и сложной логикой хорошее ООП становится обязательным, а не желаемым. Что-то небольшое (микросервис) можно написать тяп-ляп и готово. Разработка большого монолита по принципам тяп-ляп быстро приводит к тому, что развивать его становится невозможно (думаю все с таким сталкивались на рабочих проектах)
2. Пишем проект как вам хочется. Это очень важно — писать не так, как кто-то в интернете написал, или в книжке, а как вам хочется. Хочется без SOLID и тестов — пишите. Здесь важно именно наступить на грабли и получить по лбу в тех моментах, в которых вы по лбу еще не получали. Чтобы прийти к тому же SOLID или тестам не по тому, что об этом Вася в интернете написал, а потому что вы сами, на личном опыте, к этому пришли.
3. Через какое-то время наступает момент, когда дальше разрабатывать проект становится невыносимо. Костыль на костыле и тому подобное. В этот момент берем, и пишем все с нуля. Переписываем на более лучший (по вашему мнению) вариант существующий функционал, и продолжаем добавлять новый. В моем опыте первое переписывание с нуля произошло через пол года. Второе — где-то через два года.
4. В процессе переписывания вы на личном опыте доходите до таких вещей, которые умные дяди пишут в умных книжках — например, хорошо бы какой-то функционал выносить в полностью независимый модуль (привет DDD), чтобы в следующем переписывании можно было просто взять его, и скопировать в новый проект (в новое «переписывание с нуля»). В этом же процессе вы обязательно придете к авто-тестам, и не только к ним, а ощутите те приятные моменты, когда возвращаясь к проекту через пол года, уже забыв что там как работает, и работает ли вообще, вы выполняете тесты, они проходят, и вы себе говорите «о, все работает, супер».
5. И так далее — новый функционал, новые переписывания, новый опыт — процесс бесконечный.
Конечно, чтобы годами писать какой-то домашний сложный проект нужно любить программирование. Ну и быть без детей, наверное :) Так что кто еще молодой и без семьи — ловите момент.
Кода который бы понравился всем не существует. Банально — есть программисты с немалым опытом, которые вообще не пишут комментарии. И считают, что так правильно. И есть программисты с таким же опытом, которые считают, что подробные комментарии обязательны.
Важных моментов два:
1. Перед приходом в команду попросить показать код (хотя бы через скайп, хотя бы пару файлов) — визуально оценить, понравится ли вам работать с таким кодом. Если код, который пишет команда вам сразу не нравится — то и идти работать, наверное, не стоит.
2. Во всех спорных моментах можно прийти к единому варианту, выработать единый стандарт комментариев, названий классов, свойств, методов в проекте. Можно (нужно) делать подробные ревью кода, выявлять непонятные места и править их. Но, все это требует времени. А его не будет, если разработка проходит в спешке. Соответственно лучше не работать в компаниях, где разработка проходит в постоянно горящих сроках.
P.S. Хороший код — это код в который не приходится заглядывать — который атомарно выполняет свою задачу и выполняет её хорошо и без ошибок :)
Не работать в плохих компаниях.
Потому что можно сколько угодно ругаться на ужасные компании, тот же Роскомнадзор, но ведь находятся же ИТ-специалисты, которые там работают. Хотя, казалось бы, выбор компаний огромен — выбери компанию получше.
А у бизнеса принцип простой — если телега едет, деньги капают, то зачем что-то менять?
В компаниях, где я работал, обертка над тестами в виде Codeception была по умолчанию — чтобы в случае необходимости добавить приемочные тесты — их можно было легко добавить без дополнительных настроек.
P.S. Последняя картинка очень уж пережата, а хотелось бы взглянуть на текст на ней.
Удивительно, но люди, которые выбирают путь «казаться, а не быть», сами в итоге становятся жертвами чужих «вау-образов» (работать в Amazon/Google/Facebook это же так круто!)
Еще бы добавил, всем, кто считает, что «много/немного врать» это нормально — ваша ложь работает только на тех, кто сам плохо разбирается в теме. Соответственно идя по этому пути вы попадаете в заведомо слабые команды.
И по поводу работы Amazon/Google/Facebook и прочих — мне кажется, что работать там имеет смысл только годик-два, чтобы получить в свое резюме строчку «работал в Google», что резко выделяет вас на фоне остальных кандидатов. С точки же зрения денег и комфорта — небольшие компании, на мой взгляд, готовы и платить больше, и ценят своих сотрудников лучше. Потому что к ним, в отличие от «хайповых» компаний, не стоит очереди из желающих.
Его суть в том, что чем больше людей работает над проектом, тем меньше каждый из них отвечает за проект в целом и, закономерно, заинтересован в проекте в целом (зачем забивать себе голову тем, что не является твоими должностными обязанностями). Простыми словами: в команде из 2 человек каждый из них, условно, отвечает за 50% проекта и несет ответственность в размере 50%. Когда на проекте 1000 человек — то конкретно каждый отвечает лишь за очень-очень небольшой кусочек, и может делать его отлично, но вот за проект в целом, уже как бы никто и не отвечает (или люди, которые, казалось бы должны отвечать — думаю в основном о деньгах)
И нередко получается, что проект сделанный одним человеком и лучше и качественнее проекта, который делало 50 человек.
И тем не менее, пока есть люди, которые критически воспринимают любые изменения — можно пользоваться GNU/Linux спокойно.
Беспокоиться нужно будет тогда, когда любую «замечательную фичу» сообщество будет воспринимать розовыми соплями.
Даже если все хорошо, и программист и бизнес довольны, выйдя с такой работы на рынок лет так через 5… может оказаться, что ваши подходы к разработке полностью устарели и вы «неликвид».
А гуманитарии от программистов часто ожидают именно волшебства. Вот есть крупный продукт, который 10 лет писали абы как, забивая на чистый код, авто-тесты и технический долг, а потом ждут, что вот придет новый крутой программист, сделает «вжух» и все проблемы исчезнут.
И это самое неприятное — объяснять людям, что магии не бывает.
И это как раз самая проблема.
Баг, который легко воспроизводится со 100% шансом — это просто. А вот баг, который появляется раз в месяц, при непонятно каких условиях (слишком много входящих и сложная логика), и непонятно как его воспроизвести — вот это жопа.
Сейчас все больше и больше проектов микросервисные, и работают не только в рамках своей компании, но и завязаны на внешние API.
А так как везде разработка идет в формате «быстрей-быстрей, сроки горят» (исключения лишь подтверждают правило), то в каждом API есть баги, которые… Начинают перемножаться. Имеете 3 API с 3 ошибками, которые завязаны друг на друга — получите ~27 кейсов с багами. А если больше?..
Еще больший бред начинается тогда, когда ошибки одного API приходится исправлять через изменение другого API. Получаем дополнительное усложнение (с потенциальным ростом ошибок) на ровном месте.
Я не вижу никаких проблем ни у себя, ни у окружающих программистов сделать какую-угодно прихоть клиентов:
Проблемы начинаются там, где программистов в первый год разработки только гонят по срокам реализации новых фич, а потом, через год, начинают спрашивать «а почему так много багов?», «а почему все так тормозит?» и у программистов, почему-то, не хватает смелости сказать очевидную вещь: а что хотели, то и получили!
Есть даже такой классический развод «функционал бонусом», когда в ТЗ указано 10 пунктов, а потом, в процессе, заказчик хочет еще 5 пунктов за те же деньги и сроки, и доказывает, что они «само-собой разумеющиеся». Детская разводка, которая, к сожалению, очень часто срабатывает.
Но факт в другом — человек, который поддается на разводы, в любом случае будет виноватым. Каким бы он не был классным, сколько бы выходных он не проработал сверхурочно.
Распределенная (микросервисная) архитектура это в первую очередь про масштаб. Масштаб команды, масштаб нагрузки, масштаб проекта.
Если ты отличный специалист, за которым стоит очередь из HR (а еще хватает мозгов не брать кредиты и иметь запас денег) — то вообще непонятно, зачем бодаться с работодателем. Не понравились друг другу — разошлись, нашли нового.
Российские чиновники: — Подержите мое пиво
Ничего не сказано про такой важный, на мой взгляд, аспект формирования пакетов, как использование не классического паттерна Единая точка входа
Потому что использовать интерфейсы вида:
$response = $object->handle($request) // handle(RequestInterface $request): ResponseInterface
Сильно удобнее, чем что-нибудь вроде:
$object->setParam1(...)
$object->setParam2(...)
$object->setParam3(...)
$result = $objcet->getResult()
В популярных пакетах такое редко встретишь, а вот во внутренних модулях компаний — постоянно. До банального указания обязательных зависимостей не через конструктор, а через отдельный метод.
P.S.
Еще раз убеждаюсь, как же сложно написано. Моя аналогия, которая, мне кажется, намного понятнее:
Мораль проста: все новое лучше вначале проверять «на кошках» — на каких-то небольших и неважных проектах (например, на домашних), и только после обкатки (которая может занять и год и больше), и когда уже набился шаблон и этот шаблон проверен временем — уже внедрять в рабочих проектах.
P.S. И как хорошо где-то сказано: задача тимлида не в том, чтобы говнокода в проекте не было, а в том, чтобы этот говнокод не растекался — т.е. создать такие условия, чтобы говнокод каждого конкретного рядового программиста был как-то изолирован в себе (через вынесение в микросервис, или в модуль с отдельным неймспейсом, с указанным тимлидом интерфейсом использования, или как-то по другому — уже не суть)
А что поможет? Мне сильно помог такой вариант:
1. Берем, и начинаем писать в свое свободное время какой-то большой проект-монолит. В свободное время — чтобы вас никто не подгонял со сроками, монолит — потому что только в монолите с сотнями моделей и сложной логикой хорошее ООП становится обязательным, а не желаемым. Что-то небольшое (микросервис) можно написать тяп-ляп и готово. Разработка большого монолита по принципам тяп-ляп быстро приводит к тому, что развивать его становится невозможно (думаю все с таким сталкивались на рабочих проектах)
2. Пишем проект как вам хочется. Это очень важно — писать не так, как кто-то в интернете написал, или в книжке, а как вам хочется. Хочется без SOLID и тестов — пишите. Здесь важно именно наступить на грабли и получить по лбу в тех моментах, в которых вы по лбу еще не получали. Чтобы прийти к тому же SOLID или тестам не по тому, что об этом Вася в интернете написал, а потому что вы сами, на личном опыте, к этому пришли.
3. Через какое-то время наступает момент, когда дальше разрабатывать проект становится невыносимо. Костыль на костыле и тому подобное. В этот момент берем, и пишем все с нуля. Переписываем на более лучший (по вашему мнению) вариант существующий функционал, и продолжаем добавлять новый. В моем опыте первое переписывание с нуля произошло через пол года. Второе — где-то через два года.
4. В процессе переписывания вы на личном опыте доходите до таких вещей, которые умные дяди пишут в умных книжках — например, хорошо бы какой-то функционал выносить в полностью независимый модуль (привет DDD), чтобы в следующем переписывании можно было просто взять его, и скопировать в новый проект (в новое «переписывание с нуля»). В этом же процессе вы обязательно придете к авто-тестам, и не только к ним, а ощутите те приятные моменты, когда возвращаясь к проекту через пол года, уже забыв что там как работает, и работает ли вообще, вы выполняете тесты, они проходят, и вы себе говорите «о, все работает, супер».
5. И так далее — новый функционал, новые переписывания, новый опыт — процесс бесконечный.
Конечно, чтобы годами писать какой-то домашний сложный проект нужно любить программирование. Ну и быть без детей, наверное :) Так что кто еще молодой и без семьи — ловите момент.
Кода который бы понравился всем не существует. Банально — есть программисты с немалым опытом, которые вообще не пишут комментарии. И считают, что так правильно. И есть программисты с таким же опытом, которые считают, что подробные комментарии обязательны.
Важных моментов два:
1. Перед приходом в команду попросить показать код (хотя бы через скайп, хотя бы пару файлов) — визуально оценить, понравится ли вам работать с таким кодом. Если код, который пишет команда вам сразу не нравится — то и идти работать, наверное, не стоит.
2. Во всех спорных моментах можно прийти к единому варианту, выработать единый стандарт комментариев, названий классов, свойств, методов в проекте. Можно (нужно) делать подробные ревью кода, выявлять непонятные места и править их. Но, все это требует времени. А его не будет, если разработка проходит в спешке. Соответственно лучше не работать в компаниях, где разработка проходит в постоянно горящих сроках.
P.S. Хороший код — это код в который не приходится заглядывать — который атомарно выполняет свою задачу и выполняет её хорошо и без ошибок :)