Со временем код становится все запутаннее, сложнее. Изящные, в былое время, методы превращаются в «спагетти» код из тысяч строк. Конечно, до какого-то момента проще просто добавить в метод новое условие или цикл. Но когда количество строк в методе переваливает за сотню и при этом это единый блок условий и циклов невероятной вложенности, то понять его уже гораздо сложнее.
Очень не хватало возможности ввести пользователей в контекст перед голосованием. Спасибо! И так
Преамбула
Работая со старым унаследованным кодом, порой встречаются достаточно проблемные участки, которые есть желание переписать\исправить\переделать, но нет такой возможности. Этот код может быть с ошибками, которые не исправляются годами и с ними приходится мириться. Что делать с таким кодом?
Любое действие занимает некоторое время. Одни действия требуют меньше времени, другие больше, одни повторяются часто, другие, напротив, очень редки. Любой наш день состоит из множества действий, и занимают они 24 часа нашего времени. А на что же мы тратим ежедневно эти 24 часа?
Современный темп разработки ПО просто поражает своей скоростью. Функционал всегда «нужен вчера». Зачем? Конкуренция — обойдут, обгонят. Времени тестировать нет, надо отгружать функционал, надо, надо, надо.
На помощь командам разработки приходят практики, методологии, подходы и четкие регламенты. Попробую сформулировать в виде десяти правил концепцию «спокойной» разработки. А она то вынудит использовать современные методологии разработки ПО. И заказчик спокоен, и нервы свои целы. Profit!
Когда проект разрастается, обзаводится множеством модулей и зависимостей, настройка сборки проекта вручную может занять непомерно много времени. К тому же настройкой, а значит и тратой времени, занимаются все технические участники проекта от разработчиков, тестировщиков, до администраторов.
К тому же надо постоянно обновлять разработческие и тестовые системы, да еще и ничего не перепутать. Тут не обойтись без практики непрерывной интеграции.
Грамотно налаженные и состоявшиеся процессы — не для нас! Это ведь скучно, когда все уже настроено и работает как часы, но к этому надо стремиться. А уж после порадоваться проделанной работе и очередной раз проверить, как же все хорошо работает…
В последнее время все чаще встречаю мысли о переходе на специальность разработчика. Будь то менеджер, консультант, военный офицер, физик ядерщик или ландшафтный дизайнер — все захотели стать программистами. Попробуем разобраться, почему это происходит и к чему может привести.
В продолжение статьи habrahabr.ru/post/150065 обсудим конфликтные ситуации, возникающие в процессе работы над одним проектом. Случаи “кровной мести” или принципа “глаз за глаз” рассматривать не будем, так как в этом случае стоит подумать, а так ли нужен конфликтный человек команде.
Все рассматриваемые случаи чаще всего возникают в крупных компаниях с десятилетними проектами. Молодые и малые компании подвержены этим проблемам гораздо меньше.
Периодически, сталкиваясь с различными веб-сервисами, я задаюсь вопросом: «Зачем было так все усложнять?». Мы много внимания уделяем процессам разработки, чистоте кода, тестам и методологиям. Пишем комментарии и создаем документации. Но при этом слишком мало внимания уделяем основообразующим внешним системным интерфейсам – веб-сервисам.
Политика политикой, но почитав сегодняшние новости на своем любимом ресурсе мне стало жутко обидно и стыдно за его пользователей. Речь идет о заметке Коммерция в Министерстве обороны РФ.
Уже не в первый раз мне задают связанные вопросы:
«Зачем ты делаешь так много функций?»;
«Зачем ты выносишь, однократно используемый, код в функции?»;
«Остальные не знакомы с твоими правилами именования функций. Как они будут с этим работать?». Поэтому опишу свое видение проблемы. Ну а сообщество подскажет, к чему же стоит стремиться.
Со временем любой работник сталкивается с такой процедурой, как смена работодателя. У каждого найдется ряд важных для этого причин. При этом в одних компаниях формируется крепкий и дружный коллектив, а в других присутствует серьезная смена кадров. Какая разница между этими компаниями, как их различать?
Речь пойдет о замечательной книге Алана Купера, Роберта Реймана, Дэвида Кронина «Об интерфейсе». В этой книге представлен огромный пласт знаний авторов, который открывает глаза создателям цифровых продуктов.
Как много руководителей встречается нам на жизненном пути. Приходится общаться с большими и маленькими руководителями, царями и царьками, настоящими профи и самодурами. Но как понять, с каким человеком будет приятно и интересно работать, а с каким работа может превратиться в ад?
Не многие задумываются о том, кто такие программисты. Кажется в современном информационном обществе без них никуда. Но кто же они? Существует несчетное количество стереотипов, много слов написано о том, что это такие же люди, как и все остальные. Предлагаю посмотреть на этот вопрос в свете быстроразвивающейся отрасли информационных технологий.
Меня до глубины души задело заявление моего коллеги, что использовать исключения — это неправильно. А далее последовала череда объяснений: это медленно, это некрасиво, это неэффективно, это неудобно.
Точное физическое моделирование требует высокополигональных карт. Чем выше точность карты, тем больший объем памяти она занимает и тем больше приходится обрабатывать данных, чтобы получить высоту. Сплайновая интерполяция позволяет получить сетку любого разрешения, с любым, удобным в данный момент, шагом по широте и долготе.
