Комментарии 16
Плохие привычка которая у меня была на самом начале - это учить все одновременно. Помню изучал java, python, sql, алгоритмы одновременно. Из за этого у меня была каша в голове. За двумя зайцами погонишься, ни одного не поймаешь, как говорится
Ну, sql тут и правда лишний, а остальное не сказал бы что так уж вредно совмещать.
Алгоритмы хочешь не хочешь — а придётся учить одновременно с другим ЯП, а изучение двух ЯП сразу позволяет лучше понять чем алгоритмы отличаются от их реализации.
Согласен, когда изучал JS, Python (Django), PHP и C# (.net core и wpf), тоже была путаница, особенно, когда у тебя в Python пролезает camelCase, вместо рекомендуемого pep :-)
В итоге, остановился на JS (основа) + C# (wpf, как хобби). И то, после JavaScript тяжело включиться сразу в C#, но, ничего, справляюсь :)
У меня только одна вредная привычка - прокрастинация и завтра я с ней обязательно покончу!
Послезавтра. Завтра прикину план - как с ней покончить.
После послезавтра. Завтра прикину план, а послезавтра будут думать над его реализацией и искать подвохи в исходном плане
Не, ну это слишком. План ведь составить - это тоже дело непростое и небыстрое. Нужно сначала подготовиться, выбрать наилучшее время для составления плана, а после этого уже прикидывать. Только так.
Про goto забыли написать.
К тому же, никто не мешает вернуться к плохому коду в более спокойной время, и устранить свой технический долг.
Давайте будем откровенны, в современной разработке мало у кого получается вернуться к плохому коду и устранить ТД. Потому что менеджмент постоянно хочет новых фич (продаются они, а не рефакторинг), потому что плохой код уже много где используется и от него зависит другой плохой код, потому что и сами программисты не очень могут в рефакторинг и протчая, и протчая
Я б вообще говорил о, таксказать, развенчании этого лукавого понятия. Мы им просто извиняем свою усталость/лень/некомпетентность/нежелание бодаться с менеджментом и т.п.; хотя между перфекционизмом и разгильдяйством ведь еще целая куча градаций
Имхо, конечно
По этой причине в проекте и встречаются файлы с овер 6000 строк c++ кода без комментариев, где каждая строка это отдельный комит одного из 60-и программистов, который придерживался какой-то своей религии программирования и который в фирме уже не работает, а ведь можно было бы просто отнаследоваться от класса и намесить новых фич уже в другом файле не трогая этот, но прогеру легче добавить две строчки новых фич и всё заработает, но именно по этой причине в проекте и встречаются файлы с овер 6000 строк c++ кода без комментариев, где каждая строка это...
К тому же, никто не мешает вернуться к плохому коду в более спокойной время, и устранить свой технический долг.
"ldss" прав, готов подписаться под каждым словом. Сколько раз сам сталкивался с подобной ситуацией и каждый раз идя на поводу у менеджера/заказчика прилично так отхватывал негатива.
Нам никто не позволит, в последствии, выплатить технический долг. Это не продается. На это не выгодно тратить время.
Ни менеджер, ни заказчик не взаимодействуют с кодом напрямую. Многие из них даже никогда разработкой не занимались, и с трудом представляют себе какие эмоции возникают при взаимодействии с таким кодом, и к какому истощению это в итоге приводит.
Не выплачивая технический долг достаточно долгое время проект начинает замедляться, буксовать, а затем его становится просто невыгодно продолжать. При этом у измотанных разработчиков нет ни малейшего желания возится с замусоренной кодовой базой. В итоге все сходятся в одном, что проект пора либо хоронить, либо переписыать, что также зачастую равносильно "смерти".
Отказ осознанно идти на нарушение принципов, вызванное пониманием того к чему такое нарушение в последствии может привести. Это то, что отличает профессионала, несущего ответственность за свои действия от, простого наемного рабочего, которому нет особого дела до того, что станет с проектом в дальнейшем.
Бюрошник никогда не изменяет своим методам ради отношений с клиентом.
Следование собственной методологии отличает профессионала. Бюрошник не должен позволять клиенту решать за себя, как именно делать работу. Достижение результата — это интимный профессиональный процесс, который определяет сам дизайнер или его старший коллега.
Если по методу работа начинается с понимания задачи, не переходите к макетам по настоянию клиента. Если всегда рисуете главную страницу в конце проекта, не начинайте с неё в угоду генеральному директору. Если всегда сами передаёте макеты и указания в производство, не отдавайте их через клиента из-за организационных трудностей.
Бюрошник постоянно ищет способы улучшить профессиональные приёмы и процедуры, оптимизирует личную деятельность. Методы постоянно меняются с ростом опыта и знаний. Если бюрошник не предлагает улучшений в собственной работе или работе коллег, это признак застоя и равнодушия.
По поводу пункта 5 (Переоцениваете собственный стиль).
Я встречал проекты где это правило работало и неукоснительно соблюдалось. Правда там были свои проблемы с эти связаные. Лет 5-6 назат я бы полностью согласился с данным высказыванием автора. Я и сам раньше топил за единообразие. Но потом мне пришлось изменить свои взгляды. Все дело в том, что главным способом увеличения производительности и эффективности является ваш комфорт, а он достижим только в том случае если вы пользуетесь инструментами и методиками что вам подходят. В противном случае будет копиться стресс, что в итоге приведет к выгоранию.
Можно заявить что привыкнуть нужно всего один раз, но это не так. Новый проект - новый стиль кода, даже в одной и той же компании, а чаще стиля просто нет. Каждый пишет как умеет. К чему тогда привыкать. Да и с проекта на проект людей перебрасывают регулярно. Как показала моя личная статистика, построенная на основании опроса знакомых программистов, более полугода на одном проекте это редкость. А там изменение приоритетов, реструкторизация, производственная необходимость, ... Короче пол года и снова привыкать, кновым людям, к новому стилю кода, к новым правилам. А это опять стресс. Я не могу винить тех кто забивает на командный стиль и пишет как умеет. В добавок, профессионала от разнорабочего отличает наличие собственного инструментария и методологии, а также следование ей. Стиль кода также сюда входит.
Невозможно достичь выдающихся результатов и стать сильным, если в совершенстве не научишся пользоваться своими уникальными способностями, а став сильным, ты неизбежно сталкиваешся с ситуацией когда ты не помещаешься в граници ни одиного из существующих форматов и тебе неизбежно приходится создавать свой собственный.
Способность сделать так, чтобы все знали, чего ждать от вас, насколько это возможно, является лучшей чертой, которой может обладать мастер. Не только ваш менеджер выиграет от этого. Это также принесет вам пользу. У вас будет меньше опасений о будущем вашего проекта.
Внутри меня что-то противится этому утверждению. Если в проекте участвует n сотрудников, то количество каналов общения между ними равно n(n-1)/2 и растет оно как O(n2).
Сразу же возникает вопрос: А сколько энергии придется затратить на то, чтобы уведомить всех обо всем, что ты собираешься сделать? Как правило осмысленная переписка отнимает прилично так сил. Выигрываем в количестве, проигрываем в качестве. Перед глазами возникает знакомая картина, когда есть некая группа ключевых разработчиков или менеджер, на которых завязаны все процессы. Через таких людей постоянно протекает огромный поток информации. Чаще всего эти люди находятся в полуадекватном состоянии. Состоянии предельно "клипового мышления". Имеет место краткосрочная память и поверхностное мышление. Это приводит к неспособности вникать в более-менее сложные задачи, формировать четкие вопросы, а также генерировать адекватные управленческие команды. Сколько раз в деловых чатах мне приходилось иметь дело с вопросами или советами, составленными явно на скорую руку, людьми не вникшими в суть дела, но при этом раздающими ценные указания.
Если через систему управления протекает поток информации, который она не способна адекватно обработать, то будет иметь место снижение качества управления. Не лучше ли уведомлять о своих действиях только тех, кого они непосредственно касаются. Тогда и головы сотрудников освободятся для выполнения их прямой работы. Наличие зон ответственности, ключевой элемент в теории управления, позволяющий распределить информационную нагрузку и недопускать выгорания.
Чтобы человек знал чего ждать от своего напарника, то ему для начала нужно с такими человеком сработаться. Ведь все мы разные, с разными жизненными траектории, а потому привычки, опыт и подходы у нас тоже разные. В сфере IT этот срок примерно от полугода и сократить его невозможно. Это не я придумал, а врачи неврологи.
Да и вообще, мастерство это помоему про другое. Мастер - это тот кто в совершенстве овладел каким-либо ремеслом, попутно выработав свой уникальный и неповторимый стиль, который как-раз таки и позволил ему достичь такого уровня, признаваемого остальными. Поправьте если что говрю не так.
На счет опасений за будущее проекта. Так у меня эти опасения возникают постоянно, когда я начинаю общаться с человеком, который принимает управленческие решения, но при этом находится в таком состоянии, что уже не помнит о том, что обсуждалось накануне. "Синдром загнанной лошади."
Публикации
10 вредных привычек в программировании, с которыми нужно покончить прямо сейчас