Особенно красным подчеркиваются термины, которые словари не знают. Приходится для перепроверки каждый раз гуглить термин, чтобы не допустить ошибку. Лучше, конечно, один раз добавить в словарь и использовать постоянно — автоматизация.
Ещё лучше оставить текст полежать день или два, а потом перечитывать. В этом случае больше вероятности обнаружить какие-то незаметные ошибки.
Часто бывает, что требования бизнеса меняются и нужно менять функционал и, соответственно, дизайн. А дизайнер уже сдал макет и ушел, до него уже не достучаться. Заказчик говорит разработчику, сам как-нибудь разберись. Разработчик конечно может разобраться, но не сделает же так профессионально, как сделал бы дизайнер. Думаю, каждый специалист должен заниматься своим делом.
Это жестоко. Они сами для себя проблемы создают для будущего. Хотя им это устраивает пока что, кто знает, может через год их компании вообще не будет. Поэтому пока устраивает, оставляют как есть, а когда уже нужно будет, перепишут всё это безобразие.
Такого мнения и Роберт Мартин, что вся ответственность за хороший код лежит на разработчике. Но не во всех ситуациях это работает. В некоторых бизнесах требуется сделать всё быстро и с минимальной затратой денег. Если ты будешь очень долго делать одну фичу, тебя просто будут считать неэффективным.
Хотя, нужно стараться держать какую-то минимальную планку. Если даже не успеваешь что-то сделать сейчас, написать кода, учитывая, что это будет в будущем.
К сожалению, очень сложно совместить потребности бизнеса и потребности профессионального разработчика. Клиенты чаще всего хотят быстро и дёшево, то есть, за минимальное время и бюджет получить максимальный объем работы. Их не интересует качества кода, так как они его не могут оценить. Для клиентов показатель качества, это, когда покликали и всё заработало без багов. В целом им устраивает это, до сих пор пока разработка сайта не войдет в тупик.
Программист в принципе может чувствовать себя комфортно в продуктовой компании, где налажены уже все процессы и работают не на количество, а на качество. Но не стоит забывать, что этот продукт, когда-то тоже был стартапом. И все процессы начали настраивать в нём только, когда он стал востребован среди публики.
Если смотреть со стороны бизнеса, достаточно выгодно им порождать такого монстра. Ведь реально, можно очень долго делать всё идеально и сливать всё, так как продукт не выстрелил.
Тут есть ещё психологический фактор — можно действовать, как перфекционист и долго зависать на одном функционале, а потом сломаться психологически, выгореть и не довести дело до конца. Поэтому для бизнеса это тоже важно, хоть как-то, но закончить проект, а потом уже думать, как улучшить.
Аутсорсинг, это всегда компромисс между требованиями бизнеса и профессионализмом. Только нужно найти какую-то гармонию, чтобы не был значительный перевес в одну из сторон. И это по какой-то части зависит от программиста — умеешь ли ты до бизнеса донести свои профессиональные потребности и слышит ли тебя бизнес.
Давно ещё заскринил такой текст из вакансии, это конечно смешно, но очень подходит к ситуации.
Мало кто из дизайнеров документирует свой дизайн, просто кидают макет и всё. Особенно это сильно заметно на фрилансе. А про ревью верстки вообще не говорю, многим особо не хочется этим заниматься. Они рисуют дизайн как картинку и даже не задумываются, как он будет работать на реальном проекте. Потом, во время разработки возникают много вопросов, на которые должен отвечать дизайнер, но в итоге отвечает клиент.
В те времена интернета было мало и он был малодоступным, поэтому и люди ценили его больше, чем сейчас. Отправка файла или письма через почту была что-то очень крутым. Сейчас из-за переизбытка технологий люди перестали ценить возможности современного интернета и интернет используют больше для развлечений, нежели для саморазвития.
Помню, как будучи школьником я купил карту, чтобы подключиться dial-up соединением через домашний телефон. Втыкаешь кабель, открываешь настройки, прописываешь туда данные и запускаешь Internet Explorer.
У меня один даже раз заработало, открылась страница в браузере. Но потом интернет просто пропал и я так и не смог разобраться в причине. После этого у меня появился кабельный интернет с ограниченным скоростным трафиком. После использования 20 гигабайтов, вроде, скорость падала насколько, что для просмотра какого-то видео, нужно было его оставить грузиться минут 5-10. Это уже было хотя бы что-то годное, а dial-up я так и не смог нормально запустить.
Да, кстати, верно заметили. Поэтому нужно для начала просто начать что-то делать, а потом уже думать, как это улучшить. Особенно это касается кодинга — написал основной код, а потом прошелся по нему и начал рефакторить. Хотя иногда будет полезно какие-то базовые вещи изначально обдумать, потом уже приступить к кодингу.
Я попробовал этот метод, но что-то не зашло. Всё равно начинаешь уставать спустя какое-то время, как и уставал раньше. Даже установил расширение на браузер, который имел свой сайт. На сайте был to-do лист рядом с таймером, где можно было добавить свои задачи.
Наверно, не стоит ожидать какого-то чуда от этого метода, и нужно время, чтобы привыкнуть к такой дисциплине. Возможно, метод начнет работать спустя какое-то время, когда уже есть опыт.
Но я не представляю, как можно метод Помидора использовать в программировании. Когда ты входишь в состояние потокового кодинга очень сложно каждые 30 минут оторваться. Потому что, по сути, после перерыва нужно настраиваться снова. Возможно, Помидор больше подходит для маленьких задач, которые можно решит в пределах 30-и минут.
Особенно красным подчеркиваются термины, которые словари не знают. Приходится для перепроверки каждый раз гуглить термин, чтобы не допустить ошибку. Лучше, конечно, один раз добавить в словарь и использовать постоянно — автоматизация.
Ещё лучше оставить текст полежать день или два, а потом перечитывать. В этом случае больше вероятности обнаружить какие-то незаметные ошибки.
Часто бывает, что требования бизнеса меняются и нужно менять функционал и, соответственно, дизайн. А дизайнер уже сдал макет и ушел, до него уже не достучаться. Заказчик говорит разработчику, сам как-нибудь разберись. Разработчик конечно может разобраться, но не сделает же так профессионально, как сделал бы дизайнер. Думаю, каждый специалист должен заниматься своим делом.
Это жестоко. Они сами для себя проблемы создают для будущего. Хотя им это устраивает пока что, кто знает, может через год их компании вообще не будет. Поэтому пока устраивает, оставляют как есть, а когда уже нужно будет, перепишут всё это безобразие.
Такого мнения и Роберт Мартин, что вся ответственность за хороший код лежит на разработчике. Но не во всех ситуациях это работает. В некоторых бизнесах требуется сделать всё быстро и с минимальной затратой денег. Если ты будешь очень долго делать одну фичу, тебя просто будут считать неэффективным.
Хотя, нужно стараться держать какую-то минимальную планку. Если даже не успеваешь что-то сделать сейчас, написать кода, учитывая, что это будет в будущем.
К сожалению, очень сложно совместить потребности бизнеса и потребности профессионального разработчика. Клиенты чаще всего хотят быстро и дёшево, то есть, за минимальное время и бюджет получить максимальный объем работы. Их не интересует качества кода, так как они его не могут оценить. Для клиентов показатель качества, это, когда покликали и всё заработало без багов. В целом им устраивает это, до сих пор пока разработка сайта не войдет в тупик.
Программист в принципе может чувствовать себя комфортно в продуктовой компании, где налажены уже все процессы и работают не на количество, а на качество. Но не стоит забывать, что этот продукт, когда-то тоже был стартапом. И все процессы начали настраивать в нём только, когда он стал востребован среди публики.
Если смотреть со стороны бизнеса, достаточно выгодно им порождать такого монстра. Ведь реально, можно очень долго делать всё идеально и сливать всё, так как продукт не выстрелил.
Тут есть ещё психологический фактор — можно действовать, как перфекционист и долго зависать на одном функционале, а потом сломаться психологически, выгореть и не довести дело до конца. Поэтому для бизнеса это тоже важно, хоть как-то, но закончить проект, а потом уже думать, как улучшить.
Аутсорсинг, это всегда компромисс между требованиями бизнеса и профессионализмом. Только нужно найти какую-то гармонию, чтобы не был значительный перевес в одну из сторон. И это по какой-то части зависит от программиста — умеешь ли ты до бизнеса донести свои профессиональные потребности и слышит ли тебя бизнес.
Давно ещё заскринил такой текст из вакансии, это конечно смешно, но очень подходит к ситуации.
Мало кто из дизайнеров документирует свой дизайн, просто кидают макет и всё. Особенно это сильно заметно на фрилансе. А про ревью верстки вообще не говорю, многим особо не хочется этим заниматься. Они рисуют дизайн как картинку и даже не задумываются, как он будет работать на реальном проекте. Потом, во время разработки возникают много вопросов, на которые должен отвечать дизайнер, но в итоге отвечает клиент.
В те времена интернета было мало и он был малодоступным, поэтому и люди ценили его больше, чем сейчас. Отправка файла или письма через почту была что-то очень крутым. Сейчас из-за переизбытка технологий люди перестали ценить возможности современного интернета и интернет используют больше для развлечений, нежели для саморазвития.
Помню, как будучи школьником я купил карту, чтобы подключиться dial-up соединением через домашний телефон. Втыкаешь кабель, открываешь настройки, прописываешь туда данные и запускаешь Internet Explorer.
У меня один даже раз заработало, открылась страница в браузере. Но потом интернет просто пропал и я так и не смог разобраться в причине. После этого у меня появился кабельный интернет с ограниченным скоростным трафиком. После использования 20 гигабайтов, вроде, скорость падала насколько, что для просмотра какого-то видео, нужно было его оставить грузиться минут 5-10. Это уже было хотя бы что-то годное, а dial-up я так и не смог нормально запустить.
Да, кстати, верно заметили. Поэтому нужно для начала просто начать что-то делать, а потом уже думать, как это улучшить. Особенно это касается кодинга — написал основной код, а потом прошелся по нему и начал рефакторить. Хотя иногда будет полезно какие-то базовые вещи изначально обдумать, потом уже приступить к кодингу.
Я попробовал этот метод, но что-то не зашло. Всё равно начинаешь уставать спустя какое-то время, как и уставал раньше. Даже установил расширение на браузер, который имел свой сайт. На сайте был to-do лист рядом с таймером, где можно было добавить свои задачи.
Наверно, не стоит ожидать какого-то чуда от этого метода, и нужно время, чтобы привыкнуть к такой дисциплине. Возможно, метод начнет работать спустя какое-то время, когда уже есть опыт.
Но я не представляю, как можно метод Помидора использовать в программировании. Когда ты входишь в состояние потокового кодинга очень сложно каждые 30 минут оторваться. Потому что, по сути, после перерыва нужно настраиваться снова. Возможно, Помидор больше подходит для маленьких задач, которые можно решит в пределах 30-и минут.