Ну так ведь когда на аукционах Сотбис "пожелавшие остаться неизвестными" личности выкупают сами у себя за миллионы долларов для поднятия стоимости при покрывательстве галереи, происходит то же самое. И это уже было в Симпсонах)
И тут его коллега или друг хвастается другим токеном на ту же копию художественного произведения, только ссылка другая и брал его на другом ресурсе. И NTF превращается в WTF
Работодатели должны проплачивать подобные статьи, чтобы IT-шники наконец ощутили свою ненужность. На самом деле, то "планку понижать не хотел", то "хотел свое дело", итого выводы о реальной невостребованности персонажей статьи трудно сделать.
Все дело в том, что не указан технический редактор или хотя бы технический консультант. Он был бы дороже трёх обычных редакторов. Орфографические ошибки есть? Нет, по видимому. К редакторам претензий нет, может даже и две вычитки были. В целом даже chatGPT перевел бы более сносно. Если нет технической проверки, то уровень переводчика и редактора тут не при чём.
Так уровни же существуют, из-за того, что в компании должность называется одинаково "программист", а зарплата разная. Не особо шарю в бугалтерских делах, но год назад наблюдал такую сортировку в большой компании. Работаешь так с коллегами, а потом оказывается, что вы разных категорий.
Не понимаю причин вашей категоричности, так вы докажете, что NDA не существует в природе) Перечень критериев для безопасности, типа вот выше, легко внедрить в трудовой договор. В то же время гарантировать, что код будет легко поддерживаем новыми разработчиками заявление весьма размытое. То есть можно определить некие правила, и место им не в трудовом договоре а code-style, но будет он в действительности таковым зависит от разработчиков, а не правил. В обшем, если хотите что-то мне доказать, способ выше я указал.
Не соглашусь, у безопасности более четкие критерии, были похищены данные или нет, имел ли посторонний доступ к данным, была ли нарушена работа сервиса извне, etc. В сравнении к сугубо сравнительном описании практик правильного написания кода для его дальнейшей поддержки. Но, как уже написал, поддерживать можно любой код, зависит от средств и времени.
Ну а где я противопоставляю скорость работы (что не всегда производительность, кстати) безопасности?
Ну если кто-то ради бюрократии впишет в договор поддерживаемость, это очень сомнительная юридическая вещь, так как любой код поддерживаемый, но можно опровергнуть это различными известными практиками написания кода, что опять таки не доказывает юридически, что эти практики во всех случаях сработают именно так.
По иерархии ответственности, воображаемый начальник отдела не взял из собственного воображаемого кармана, а использовал лимит средств на разработку. Есть вещи, такие как производительность и безопасность, которые само собой разумеются, особенно в Веб. Ну кстати и в десктопных играх fps тоже немаловажно, но там это может быть на третьем плане. Но желание делать прямо все, что требует начальство, кажется беспринципным. Писать лапшекод, использовать незаконный контент и тд, это не рабочие обязанности, а выбор разраба, который решает, идти на компромисс или нет. Касаемо "чистого" кода - это то определение, что описывается в статье, от себя ничего не придумал.
Владельцу нужно, например, больше фич, но начальник отдела не забыл назначить человека, ответственного за безопасность - вот что имел ввиду. Быстродействие и безопасность - это базовые правила для веб-разработки, это конечно, не касается многих исключений, но в целом по индустрии это минимальные правило выживания. Можно привести большое количество примеров, когда заказчик попросит разработать быстро и тяп-ляп, покажет одному человеку и прибьет проект, и можно ли это относить к общей массе полноценных работающих проектов, вопрос другой. Мне кажется, такие наброски не стоит считать.
быстро выкатить в прод, а потом так же быстро развивать
Это из области фантастики, так как или то или другое.
А безопасностью иногда жертвуют в пользу удобства.
Мы же об одной и той-же безопасности? Если в проекте есть БД, например, то не защитить её как минимум от инъекций... Возможно, что первый, кто её обнаружит, сделает работу совсем уж неудобной)
Что вы имеете в виду под "владельцем"(?), фаундеров компании, отдыхающих на островах и не имеющих представления о технических подробностях? А раз так, то специалисты по безопасности начальниками отделов не назначаются? Преобладающая часть веба это сайты, если сайт грузится более 5 сек, то по статистике его просто не существует. Приведите, пожалуйста, в пример ситуацию когда владельцу нужно, чтобы сайт адски тормозил и мог быть взломан проходящим школьником. В угоду чего? Обсуждаемой здесь "чистоты" кода? Чтобы когда его в даркнете выложат, стыдно не было?) Хотя в конце своего сообщения за то и топлю, чтобы учитывать интересы заказчика, надо было просто дочитать.
PS Кстати, могу же и мнение поменять, приглашайте на работу в реальный проект (по технологиям обсудим), если все-все так ровно там, как вы защищаете, без спешки сделано, по канонам, работает шустро, все довольны. А то уже насмотрелся всякого, на техсобесе OOП, DDD, TDD и тд, а потом в коде жуть... Это в общем, а не к комментатору выше ответ.
Во всем вебе код должен писаться с упором на производительность и безопасность. Читаемость при "чистом коде" (как его преподносит автор) тоже хуже, больше символов и логики. Другой разработчик всё равно будет тратить время на то, чтобы понять чужой код, даже если он по всем стандартам. Естественно, нужно искать золотую середину.
И добавление функционала не заставит переписывать кучу кода.
Это по учебнику OOП, типа вот модель двигателя, а вот запчасти, красиво выходит, а потом добавляется второй двигатель (в реальности есть и такие автомобили, как камень еще в огород DDD) и переписывать все равно заново. Если бы бизнес шел проторенными шагами, условно не добавляя "вторые двигатели", то он скоро бы накрылся. Эти правила написания кода не учитывают реалии, которыми оперирует заказчик, не программист.
Из похождений (иначе не назовёшь) в прошлом по собеседованиям, уяснил только одно. Если человек очень нужен и резюме подходит - пара вопросов и берут сразу. В конце концов, при опыте работы в несколько лет технологии и фреймворки особо не имеют разницы. Почитать недельку мануалы и можно работать. Чтобы изначально звезды, то есть технологии, сошлись, надо рекрутерам очень постараться. Другое дело, что недели этой нет, нет мероприятий введения в должность, в общем сразу надо задачи делать, это настораживать должно, скорее галера, текучка или головотяпство верхов. В противном случае, все эти этапы собеседований и тд, на самом деле означают, что и так штат раздут или сами не знают, нужен или не нужен человек. Иногда подозреваю, что такое входит в задачу повышения кругозора собеседующих, кто как на этих технологиях работает в других компаниях.
Сколько времени необходимо на решение задач программистом проблема мировая. Наблюдал и сейчас наблюдаю, потуги решить её в различных компаниях, целые книги пишутся про сторипойнты и иже с ними, а воз и ныне там. Допустим, что один программист не увиливает от работы, а просто хочет сделать на совесть, чтобы максимально предотвратить появление последуюших багов, второй освобождает время для собственных проектов в рабочее время, третий некомпетентен для своей занимаемой должности. С точки зрения времени решения задач - они все равны. Если по пользе, то первый лидирует. Хотя, нынче существует тенденция считать, что баги нужно копить в беклоге. Главное галочку поставить, что спринт закрыт. Выше видел примеры про штучное производство, но здесь это не работает. В каждой задаче могут быть подводные камни или, как может быть у компаний уровня Гугла, жизненый цикл попадания задачи в прод, даже если это правка опечатки, занимает пару дней. Попробуй предскажи, когда там её проревьюят.
Ну невозможно обучится с нуля до мидла, максимум до джуниора. Мидл это еще опыт работы нужен. Самостоятельной работы в реальной компании, а не под кураторством и стажировками. Ведь чем он ценен - сам может принимать технические решения. Завязывайте с развешиванием лапши.
Ну так ведь когда на аукционах Сотбис "пожелавшие остаться неизвестными" личности выкупают сами у себя за миллионы долларов для поднятия стоимости при покрывательстве галереи, происходит то же самое. И это уже было в Симпсонах)
И тут его коллега или друг хвастается другим токеном на ту же копию художественного произведения, только ссылка другая и брал его на другом ресурсе. И NTF превращается в WTF
Работодатели должны проплачивать подобные статьи, чтобы IT-шники наконец ощутили свою ненужность. На самом деле, то "планку понижать не хотел", то "хотел свое дело", итого выводы о реальной невостребованности персонажей статьи трудно сделать.
Все дело в том, что не указан технический редактор или хотя бы технический консультант. Он был бы дороже трёх обычных редакторов. Орфографические ошибки есть? Нет, по видимому. К редакторам претензий нет, может даже и две вычитки были. В целом даже chatGPT перевел бы более сносно. Если нет технической проверки, то уровень переводчика и редактора тут не при чём.
Так уровни же существуют, из-за того, что в компании должность называется одинаково "программист", а зарплата разная. Не особо шарю в бугалтерских делах, но год назад наблюдал такую сортировку в большой компании. Работаешь так с коллегами, а потом оказывается, что вы разных категорий.
Не понимаю причин вашей категоричности, так вы докажете, что NDA не существует в природе) Перечень критериев для безопасности, типа вот выше, легко внедрить в трудовой договор. В то же время гарантировать, что код будет легко поддерживаем новыми разработчиками заявление весьма размытое. То есть можно определить некие правила, и место им не в трудовом договоре а code-style, но будет он в действительности таковым зависит от разработчиков, а не правил. В обшем, если хотите что-то мне доказать, способ выше я указал.
Не соглашусь, у безопасности более четкие критерии, были похищены данные или нет, имел ли посторонний доступ к данным, была ли нарушена работа сервиса извне, etc. В сравнении к сугубо сравнительном описании практик правильного написания кода для его дальнейшей поддержки. Но, как уже написал, поддерживать можно любой код, зависит от средств и времени.
Ну а где я противопоставляю скорость работы (что не всегда производительность, кстати) безопасности?
Ну если кто-то ради бюрократии впишет в договор поддерживаемость, это очень сомнительная юридическая вещь, так как любой код поддерживаемый, но можно опровергнуть это различными известными практиками написания кода, что опять таки не доказывает юридически, что эти практики во всех случаях сработают именно так.
По иерархии ответственности, воображаемый начальник отдела не взял из собственного воображаемого кармана, а использовал лимит средств на разработку. Есть вещи, такие как производительность и безопасность, которые само собой разумеются, особенно в Веб. Ну кстати и в десктопных играх fps тоже немаловажно, но там это может быть на третьем плане. Но желание делать прямо все, что требует начальство, кажется беспринципным. Писать лапшекод, использовать незаконный контент и тд, это не рабочие обязанности, а выбор разраба, который решает, идти на компромисс или нет. Касаемо "чистого" кода - это то определение, что описывается в статье, от себя ничего не придумал.
Владельцу нужно, например, больше фич, но начальник отдела не забыл назначить человека, ответственного за безопасность - вот что имел ввиду. Быстродействие и безопасность - это базовые правила для веб-разработки, это конечно, не касается многих исключений, но в целом по индустрии это минимальные правило выживания. Можно привести большое количество примеров, когда заказчик попросит разработать быстро и тяп-ляп, покажет одному человеку и прибьет проект, и можно ли это относить к общей массе полноценных работающих проектов, вопрос другой. Мне кажется, такие наброски не стоит считать.
быстро выкатить в прод, а потом так же быстро развивать
Это из области фантастики, так как или то или другое.А безопасностью иногда жертвуют в пользу удобства.
Мы же об одной и той-же безопасности? Если в проекте есть БД, например, то не защитить её как минимум от инъекций... Возможно, что первый, кто её обнаружит, сделает работу совсем уж неудобной)Что вы имеете в виду под "владельцем"(?), фаундеров компании, отдыхающих на островах и не имеющих представления о технических подробностях? А раз так, то специалисты по безопасности начальниками отделов не назначаются? Преобладающая часть веба это сайты, если сайт грузится более 5 сек, то по статистике его просто не существует. Приведите, пожалуйста, в пример ситуацию когда владельцу нужно, чтобы сайт адски тормозил и мог быть взломан проходящим школьником. В угоду чего? Обсуждаемой здесь "чистоты" кода? Чтобы когда его в даркнете выложат, стыдно не было?) Хотя в конце своего сообщения за то и топлю, чтобы учитывать интересы заказчика, надо было просто дочитать.
PS Кстати, могу же и мнение поменять, приглашайте на работу в реальный проект (по технологиям обсудим), если все-все так ровно там, как вы защищаете, без спешки сделано, по канонам, работает шустро, все довольны. А то уже насмотрелся всякого, на техсобесе OOП, DDD, TDD и тд, а потом в коде жуть... Это в общем, а не к комментатору выше ответ.
Во всем вебе код должен писаться с упором на производительность и безопасность. Читаемость при "чистом коде" (как его преподносит автор) тоже хуже, больше символов и логики. Другой разработчик всё равно будет тратить время на то, чтобы понять чужой код, даже если он по всем стандартам. Естественно, нужно искать золотую середину.
И добавление функционала не заставит переписывать кучу кода.
Это по учебнику OOП, типа вот модель двигателя, а вот запчасти, красиво выходит, а потом добавляется второй двигатель (в реальности есть и такие автомобили, как камень еще в огород DDD) и переписывать все равно заново. Если бы бизнес шел проторенными шагами, условно не добавляя "вторые двигатели", то он скоро бы накрылся. Эти правила написания кода не учитывают реалии, которыми оперирует заказчик, не программист.А что посоветуете взамен hh.ru?
Из похождений (иначе не назовёшь) в прошлом по собеседованиям, уяснил только одно. Если человек очень нужен и резюме подходит - пара вопросов и берут сразу. В конце концов, при опыте работы в несколько лет технологии и фреймворки особо не имеют разницы. Почитать недельку мануалы и можно работать. Чтобы изначально звезды, то есть технологии, сошлись, надо рекрутерам очень постараться. Другое дело, что недели этой нет, нет мероприятий введения в должность, в общем сразу надо задачи делать, это настораживать должно, скорее галера, текучка или головотяпство верхов. В противном случае, все эти этапы собеседований и тд, на самом деле означают, что и так штат раздут или сами не знают, нужен или не нужен человек. Иногда подозреваю, что такое входит в задачу повышения кругозора собеседующих, кто как на этих технологиях работает в других компаниях.
Если верить выдаче гугла, то там только архив распаковать нужно для установки. Хотя есть способ проще https://onlinephp.io/
Аналогичное "волшебство" на бекенде:
php -S localhost:8000
Сколько времени необходимо на решение задач программистом проблема мировая. Наблюдал и сейчас наблюдаю, потуги решить её в различных компаниях, целые книги пишутся про сторипойнты и иже с ними, а воз и ныне там. Допустим, что один программист не увиливает от работы, а просто хочет сделать на совесть, чтобы максимально предотвратить появление последуюших багов, второй освобождает время для собственных проектов в рабочее время, третий некомпетентен для своей занимаемой должности. С точки зрения времени решения задач - они все равны. Если по пользе, то первый лидирует. Хотя, нынче существует тенденция считать, что баги нужно копить в беклоге. Главное галочку поставить, что спринт закрыт. Выше видел примеры про штучное производство, но здесь это не работает. В каждой задаче могут быть подводные камни или, как может быть у компаний уровня Гугла, жизненый цикл попадания задачи в прод, даже если это правка опечатки, занимает пару дней. Попробуй предскажи, когда там её проревьюят.
Ну невозможно обучится с нуля до мидла, максимум до джуниора. Мидл это еще опыт работы нужен. Самостоятельной работы в реальной компании, а не под кураторством и стажировками. Ведь чем он ценен - сам может принимать технические решения.
Завязывайте с развешиванием лапши.
И правда, что же делать с огроменным легаси? Пропустить через ChatGPT и потом вручную проверять всё?