К сожалению, не стирается никогда, т.к. нет наработанного навыка доводить начатое дело до конца и это вылазит потом в работе постоянно. Конечно, я не сравниваю с теми, кто просто просиживал штаны в вузе, а с теми, кто знает зачем пришел учиться. Без крепкой инженерной базы и прикладных наук все, кто ушел, остаются на том же уровне мышления тупого копи-пасты, зарабатывания денег и нытья, а не создания новых продуктов, направлений и областей. Да, бывают исключения, кто потом наверстывает упущенное (сам знаю пару таких), но их подавляющее меньшинство.
Правильно замечено: "кодовая база без реального владения со временем деградирует". Сколько людей, столько мнений. И даже, если все профессионалы высокого класса, нужен координатор, чтобы привести к единому соглашению и следить, чтобы все придерживались единой линии.
Сейчас стараюсь четко определить владельца кода или сам станавлюсь им. Тогда можно говорить о каком-то порядке или возможности придерживаться плана и поставки в срок.
Вот не думал, что это еще кому-то интересно! Последний раз фотографировал экран лет 25 назад. Тогда еще на пленку, но выдержку и диафрагму, конечно, так же подбирал.
Еще раньше в универе на курсовую по моделированию процессов фотографировал код программы с экрана телевизора и напечатал большие фотографии, т.к. дома принтера не было. Так на защите преподаватель больше распрашивал как я фотографировал с экрана, что все четко, чисто, без искажений получилось и сетки не видно. Секрет-то "прост" - профессиональный фотограф во втором поколении :)
И билдер у ломбока, как раз, имеет ограничения. Если захотелось сделать хоть какую-то иерархию, то сгенерированый билдер перестает работать и никак раширить, как ту же ToString невозможно
Если используется два разных физических соединения к базам, то использование разных менеджеров транзакций очевидно. Ну, и про многопоточность и конкурентную работу тоже было указано. Так что школьные задачки, с дурно пахнущим кодом, можно было не приводить. А то, ненароком, кто-то ещё использует ;)
На нескольких уже последних проектах в первую очередь создаю страницу соглашений по проекту. Потом при ревью, помимо конкретного замечания, вставляется ссылка на пункт где развернутое описание "почему", чтоб не писать каждый раз что значит.
Например, переименовать тестовый класс согласно пункта 5 сглашения 'ссылка'. Где прописано, что тестовые классы именуются так-то, т.к. применяется маска и т.п. (Такую проверку, конечно, можно настроить в статическом анализаторе. Просто не во всех проектах возможно под себя перенастроить правила анализатора).
Это сильно сокращает время ревью и дает возможность посмотреть развернутое описание. Конечно, соглашение возможно пересматривать, дополнять, вносить исключения, но только аргументировано.
В 12м Обучение. Важная составляющая процесса обучения, как одной и сложных и важных систем, есть обратная связь. Не просто подискутировать, а убедиться, что все участники системы-команды поняли и приняли правила и найти оптимальное решение для улучшения процесса. Чаще всего, как раз, на процессе обсуждения все и заканчивается. Иногда, даже, пишут небходимые действия, но без контроля их выполнения это не работает.
Есть у меня на одном проекте такой персонаж, который знает все эти функции и выверты с подвывертами... Но если эти знания не подкреплены логикой иои логика есть, но своя - альтернативная, то это путешествие по минному полю с завязанными глазами.
-- Почему в базе, вдруг, исчезли все внешние ключи?
-- Я их убрал, т.к. они мешали вставить данные: ошибки вылетали.
-- Так в том же и смысл, чтоб обеспечить целостность базы!
-- Я все могу обеспечить и так.
Или таблицы без ключей и индексов и с сотнями столбцов, чтоб все в одной таблице хранилось, а то скорость выборки низкая. Но зато рэнки, партишены и т.д. и т.п. от зубов отскакивают!
Просто при установке аннотации таймаут транзакции отрабатывает корректно.
В Spring реализация менеждера транзакций достаточно кривая. Несколько лет назад столкнулись с неприятнейшей ошибкой, с которой, скорей всего, мало кто столкнется, но пришлось залезть глубоко в реализацию.
Ошибка: используется два соединения к базе, например,из одной базы переливаем данные в другую, на больших скоростях и больших объемах транзакций данные из одной транзакции могут попадать в другую, т.к. транзакции некорректно привязываются к потокам и нет корректной изоляции.
Пришлось принудительно управлять второй транзакцией в собственном менеджере транзакций с привязкой через ThreadLocal.
Казалось бы есть принцип построения отзывчивого интерфейса: новая версия не должна сужать возможности пользователя. Но, как говорил один дизайнер: В дизайне нет стандартов!
Правильно: Долой пользователей! Пчелы против меда!
Довольно часто пользуюсь схлопыванием блоков кода, но не всех, а выборочно в ходе ревью. Сверху ты можешь схлопнуть, а снизу - теперь нет.
Минимализм элементов управления - не лучшее решение, т.к. у всех зрение разное и попадать в мелкие элементы проблематично, а масштабирование, оно и в 21м веке кривое, к сожалению.
Да, ко всему можно привыкнуть, но зачем привыкать к плохому?
Лучше бы добавили функционал, что был в jBuilder более 20ти лет назад.
После void метода ничего не может быть и можно поставить ';' автоматом.
После точки, если уже выражение есть, то не нужно вставлять тоже самое выражение.
Любой BPM фреймворк нацелен на то, чтобы ввести уровень абстракции для дальнейшего переиспользования больших блоков процесса и эффективного развития процессов. Даже если вы работаете на уровне небольших приложений есть выгода от использования BPM. Например, визарды, заполение форм можно сделать с помощью BPM или workflow.
В случае встроенного BPM отладка такая же как в обычном приложении. Если BPM серверный, то либо удаленная отладка, либо как в любом распределенном приложении. Опять же хороший тон - присать тесты на процесс перед заливкой и проблем будет значительно меньше.
А в дорогом и медицинском оборудовании ПО не из АйТи?! К сожалению, из-за такого непонимания именно и проиходят аварии. Подумаешь, Винда зависла! Ага, при этом, например, расплав металла прожег оболочку и вылился в цех и покалечил реальных людей т.к. не сработала во время заслонка, которая контролировалась сервисом на той Винде. Зависла она, т.к. сервис решили написать на новомодном языке со своей библиотекой контроля времени, которую тестировала деффочка-лютик и прошлась только по саксесс сторис, работу принял манагер, который не в тех.процессе завода ни в разработке не смыслит, т.к. лингвист и у него "язык подвешен". И в довешении всего "Одмин-DevOps" решил, что "и одной винды хватит на это г#$но, зависнет перегружу или вообще переставлю".
У меня в дипломе по Электронному машиностроению тоже, казалось, много лишнего. Но по прошествию уже десятилетий можно сказать, что ничего лишнего не было, а хотелось бы ещё! Да, было тяжеловато: по 6-7 пар было, но все окупилось сторицей! Я вот смотрю на спикок выше и ничего лишнего не вижу. Наоборот есть довольно специализированные предметы, на которых проще уловить связь с реальностью и вещественным.
Операторов станков с ЧПУ как раз ПТУ и выпускалии.
Купные корпорации как раз уже давно соорентировались: вся эта толпа индусов, что у них работает, не имеет высшего, а зачастую и среднеспециального образования. На местах уже приходится их учить.
А библиотеки в СССР некоторые были, действительно, специализированные. Да, и сейчас такие существуют и по всему миру так устроено. И повелось это со времен первых книг и причины сокрытия или охраны разные. Но ищущий всегда найдет!
Поддерживаю! Именно нормальная командная строка, история команд, просмотра, редактирования, отсутствие необходимости использования мыши, хороший вьювер с нормальным подчитыванием а-ля тейл, хороший редактор. Именно, для людей, кто хочет быстро работать.
К сожалению, не стирается никогда, т.к. нет наработанного навыка доводить начатое дело до конца и это вылазит потом в работе постоянно. Конечно, я не сравниваю с теми, кто просто просиживал штаны в вузе, а с теми, кто знает зачем пришел учиться. Без крепкой инженерной базы и прикладных наук все, кто ушел, остаются на том же уровне мышления тупого копи-пасты, зарабатывания денег и нытья, а не создания новых продуктов, направлений и областей. Да, бывают исключения, кто потом наверстывает упущенное (сам знаю пару таких), но их подавляющее меньшинство.
Правильно замечено: "кодовая база без реального владения со временем деградирует". Сколько людей, столько мнений. И даже, если все профессионалы высокого класса, нужен координатор, чтобы привести к единому соглашению и следить, чтобы все придерживались единой линии.
Сейчас стараюсь четко определить владельца кода или сам станавлюсь им. Тогда можно говорить о каком-то порядке или возможности придерживаться плана и поставки в срок.
Camunda - его разработчик.
Camunda Modeler и Activiti используют его под капотом.
Вот не думал, что это еще кому-то интересно! Последний раз фотографировал экран лет 25 назад. Тогда еще на пленку, но выдержку и диафрагму, конечно, так же подбирал.
Еще раньше в универе на курсовую по моделированию процессов фотографировал код программы с экрана телевизора и напечатал большие фотографии, т.к. дома принтера не было. Так на защите преподаватель больше распрашивал как я фотографировал с экрана, что все четко, чисто, без искажений получилось и сетки не видно. Секрет-то "прост" - профессиональный фотограф во втором поколении :)
И билдер у ломбока, как раз, имеет ограничения. Если захотелось сделать хоть какую-то иерархию, то сгенерированый билдер перестает работать и никак раширить, как ту же ToString невозможно
Если используется два разных физических соединения к базам, то использование разных менеджеров транзакций очевидно. Ну, и про многопоточность и конкурентную работу тоже было указано. Так что школьные задачки, с дурно пахнущим кодом, можно было не приводить. А то, ненароком, кто-то ещё использует ;)
Конечно, все было сделано. Но, именно, ввиду корявости кода в том месте в некоторых случаях возникали ошибки.
В одном месте кода был комментарий: "Если вы сюда попали, то делаете что-то уникальное. Я не смог найти решение. Поделитесь, пожалуйста"
В другом (в Spring Cloud): "Если это вам нужно, то сделайте, пожалуйста, сами".
"Не боги горшки обжигают"(с)
На нескольких уже последних проектах в первую очередь создаю страницу соглашений по проекту. Потом при ревью, помимо конкретного замечания, вставляется ссылка на пункт где развернутое описание "почему", чтоб не писать каждый раз что значит.
Например, переименовать тестовый класс согласно пункта 5 сглашения 'ссылка'. Где прописано, что тестовые классы именуются так-то, т.к. применяется маска и т.п. (Такую проверку, конечно, можно настроить в статическом анализаторе. Просто не во всех проектах возможно под себя перенастроить правила анализатора).
Это сильно сокращает время ревью и дает возможность посмотреть развернутое описание. Конечно, соглашение возможно пересматривать, дополнять, вносить исключения, но только аргументировано.
Sonar вполне справляется с оценкой коплексности кода, например, вложенность if-else, for, количестао строк и т.п.
В 12м Обучение. Важная составляющая процесса обучения, как одной и сложных и важных систем, есть обратная связь. Не просто подискутировать, а убедиться, что все участники системы-команды поняли и приняли правила и найти оптимальное решение для улучшения процесса. Чаще всего, как раз, на процессе обсуждения все и заканчивается. Иногда, даже, пишут небходимые действия, но без контроля их выполнения это не работает.
Одно дело отключить, другое - удалить :)
Просто отсутствие базовых знаний приводит к такой каше в голове.
Есть у меня на одном проекте такой персонаж, который знает все эти функции и выверты с подвывертами... Но если эти знания не подкреплены логикой иои логика есть, но своя - альтернативная, то это путешествие по минному полю с завязанными глазами.
-- Почему в базе, вдруг, исчезли все внешние ключи?
-- Я их убрал, т.к. они мешали вставить данные: ошибки вылетали.
-- Так в том же и смысл, чтоб обеспечить целостность базы!
-- Я все могу обеспечить и так.
Или таблицы без ключей и индексов и с сотнями столбцов, чтоб все в одной таблице хранилось, а то скорость выборки низкая. Но зато рэнки, партишены и т.д. и т.п. от зубов отскакивают!
Просто при установке аннотации таймаут транзакции отрабатывает корректно.
В Spring реализация менеждера транзакций достаточно кривая. Несколько лет назад столкнулись с неприятнейшей ошибкой, с которой, скорей всего, мало кто столкнется, но пришлось залезть глубоко в реализацию.
Ошибка: используется два соединения к базе, например,из одной базы переливаем данные в другую, на больших скоростях и больших объемах транзакций данные из одной транзакции могут попадать в другую, т.к. транзакции некорректно привязываются к потокам и нет корректной изоляции.
Пришлось принудительно управлять второй транзакцией в собственном менеджере транзакций с привязкой через ThreadLocal.
Недавно посмотрел код - ничего не поменялось :(
Казалось бы есть принцип построения отзывчивого интерфейса: новая версия не должна сужать возможности пользователя. Но, как говорил один дизайнер: В дизайне нет стандартов!
Правильно: Долой пользователей! Пчелы против меда!
Довольно часто пользуюсь схлопыванием блоков кода, но не всех, а выборочно в ходе ревью. Сверху ты можешь схлопнуть, а снизу - теперь нет.
Минимализм элементов управления - не лучшее решение, т.к. у всех зрение разное и попадать в мелкие элементы проблематично, а масштабирование, оно и в 21м веке кривое, к сожалению.
Да, ко всему можно привыкнуть, но зачем привыкать к плохому?
Лучше бы добавили функционал, что был в jBuilder более 20ти лет назад.
После void метода ничего не может быть и можно поставить ';' автоматом.
После точки, если уже выражение есть, то не нужно вставлять тоже самое выражение.
Любой BPM фреймворк нацелен на то, чтобы ввести уровень абстракции для дальнейшего переиспользования больших блоков процесса и эффективного развития процессов. Даже если вы работаете на уровне небольших приложений есть выгода от использования BPM. Например, визарды, заполение форм можно сделать с помощью BPM или workflow.
В случае встроенного BPM отладка такая же как в обычном приложении. Если BPM серверный, то либо удаленная отладка, либо как в любом распределенном приложении. Опять же хороший тон - присать тесты на процесс перед заливкой и проблем будет значительно меньше.
Дай бог вам и дальше не сталкиваться с подобными "совами" и не утонуть в той "капле в море".
А с системами реального времени никто прослойки-адаптеры и "прокладки" не отменял и если не выполняются стандарты и условия, то ...
А в дорогом и медицинском оборудовании ПО не из АйТи?! К сожалению, из-за такого непонимания именно и проиходят аварии. Подумаешь, Винда зависла! Ага, при этом, например, расплав металла прожег оболочку и вылился в цех и покалечил реальных людей т.к. не сработала во время заслонка, которая контролировалась сервисом на той Винде. Зависла она, т.к. сервис решили написать на новомодном языке со своей библиотекой контроля времени, которую тестировала деффочка-лютик и прошлась только по саксесс сторис, работу принял манагер, который не в тех.процессе завода ни в разработке не смыслит, т.к. лингвист и у него "язык подвешен". И в довешении всего "Одмин-DevOps" решил, что "и одной винды хватит на это г#$но, зависнет перегружу или вообще переставлю".
У меня в дипломе по Электронному машиностроению тоже, казалось, много лишнего. Но по прошествию уже десятилетий можно сказать, что ничего лишнего не было, а хотелось бы ещё! Да, было тяжеловато: по 6-7 пар было, но все окупилось сторицей! Я вот смотрю на спикок выше и ничего лишнего не вижу. Наоборот есть довольно специализированные предметы, на которых проще уловить связь с реальностью и вещественным.
Операторов станков с ЧПУ как раз ПТУ и выпускалии.
Купные корпорации как раз уже давно соорентировались: вся эта толпа индусов, что у них работает, не имеет высшего, а зачастую и среднеспециального образования. На местах уже приходится их учить.
А библиотеки в СССР некоторые были, действительно, специализированные. Да, и сейчас такие существуют и по всему миру так устроено. И повелось это со времен первых книг и причины сокрытия или охраны разные. Но ищущий всегда найдет!
Поддерживаю! Именно нормальная командная строка, история команд, просмотра, редактирования, отсутствие необходимости использования мыши, хороший вьювер с нормальным подчитыванием а-ля тейл, хороший редактор. Именно, для людей, кто хочет быстро работать.