29.11.2016, 09:14
Главное правило программиста - не трогай то, что работает.
Кроме программистов, которых нужно вертеть на хую, есть еще амбициозные джуниоры, которые имеют хуй да не хуя опыта и примерно столько же знаний о предметной области и о проекте. И лехкий пиздец начинается когда такие начинают принимать решения - как минимум возвращаются все ошибки который этот "бесполезный" кусок решал. Причем его даже не хватает на то, чтобы верифицировать измененное поведение полностью, и эти ошибки обнаруживаются уже в стомиллионном продакшене...
Так что тема довольно тонкая. И категоричность может быть преждевременной. Ну понятно что за некоторые вещи можно (нужно) уебать без раздумий, например, за public: bool m_Flag; как за нарушение инкапсуляции...
Так что тема довольно тонкая. И категоричность может быть преждевременной. Ну понятно что за некоторые вещи можно (нужно) уебать без раздумий, например, за public: bool m_Flag; как за нарушение инкапсуляции...
Я сам не знаю, мне друг рассказывал. Насколько я понял с его рассказов, такое бывает, когда на проекте приоритеты с разработки ПО парадоксально "съезжают" на что-то другое, и когда с такого проекта "валят" синьор девелоперы и остаются джуны... Так что формально код ревьювнут и апрувнут. Тоже джунами.
А ты чего хотел? Название конторы/проекта, линку на гугл плей и координаты участников?)
Это как статистика. Такое наблюдалось и это факт. Конкретика не важна. Я сам в ахуе... ой, то есть мой знакомый... от полученного опыта.
Это как статистика. Такое наблюдалось и это факт. Конкретика не важна. Я сам в ахуе... ой, то есть мой знакомый... от полученного опыта.
> на третьем курсе лабы по С превращали в тормозящее говно
Сцук, это ж надо суметь.
>обработку в цикл инициализации
Ты меня убить хочешь, ирод?
Сцук, это ж надо суметь.
>обработку в цикл инициализации
Ты меня убить хочешь, ирод?
Если тормозит - значит нихуя нормально не работает.
Это главное правило того кому лень разбираться по всех нюансах алгоритма
Применимо ровно до того момента, пока не начинаешь вносить изменения в этот участок или юзать выше. Особый трепет у меня сейчас вызывает, когда вижу старый метод, в который постоянно добавляли различные флаги/критерии в параметры, вместо дублицирования/перегрузки.... и в итоге когда нужно добавить еще один кртерий выборки, естимейт уходит в бесконечность.
К сожалению в любом правиле есть свои исключения... Я например зарабатывают на жизнь оптимизацией приложений на android, но главная проблема не в том что существуют лишние строки кода, а в том как они расположены. Представляю вам несколько случаев.
1. Случай: Некоторые программисты оставляют комментарии и частицы кода, на случай если что-то пойдёт не так, и можно будет быстро бекапнуться и вернуться к начальному варианту ,или же наоборот пишется новый код для того чтобы им заменить старый ,но в итоге он оказывается нестабилен и соответственно неиспользуеться. Однако либо кодер забывает это вырезать ,либо к нему ползет дедлайн, либо он ленивая задница. В любом случае он забывает вырезать этот мусор, что в конце концов приводит к увеличению количества занимаемой памяти, а в особо лютых случаях к использованию лишнего ОЗУ (что очень важно на мобильных устройствах)
ДЛЯ САМЫХ МАЛЕНЬКИХ: Представьте у вас есть лего, вы наконец построили красивый дом, но в процессе постройки вы оставили за собой каркас такого же дома ,чтобы в случае землетрясения вам не приходилось начинать строить новый дом заново. А также оставили за собой кучу понятных только вам пирамид, шестиугольников, треугольников из которых можно "развить идею" и создать дом круче своего ну или же которые могут просто пригодиться.
2. Случай: Этот случай даже проще. Типичные дерьмокодеры часто делают все так-как им удобно. К примеру вместо того чтобы запилить array будут запиливать каждую переменную по отдельности ,или что ещё хуже вместо типа integer будут везде ставить real, ведь real круче integer потому что в нем больше чисел, и он везде пригодиться. Только вот незадача! Некоторые числа делятся с бесконечным результатом! Из за чего приходиться их округлять, потом снова округлять, и снова ,что в конечном итоге приводит к тому, что 10:3+1=4, а потом ещё куча таких хе вычислений с числом 4 и в итоге больше ошибок в коде и соответсвенно вылетов.
ДЛЯ САМЫХ МАЛЕНЬКИХ: Представьте вы построили домик из лего. Но дом получился некрасивый потому что вы не использовали маленьких блоков т.к с ними трудно возиться и долго мучаться их тонкой расстановкой. И использовали ненужные большие неровные блоки которые удобно лежали в руке и удобно скреплялись между собой.
3 Случай самый простой: Строчки кода которые можно сократить без потери функциональности.
ДЛЯ САМЫХ МАЛЕНЬКИХ: Вы строили дом из лего ,но в куче конструктора вам было лень искать двойные блоки для постройки дома т.к их было мало плюс их засыпали кучей одинарных блоков из которых тоже можно построить дом. В итоге вы построили дои использовав 100 одинарных блоков хотя можно было использовать 50 двойных, и дом у вас получился хрупким сложным непонятным. И если упадёт хотябы один одинырный блок то сломаться весь дом, Но двойные блоки сидели бы крепче и шанс того что они отдаляться соответственно меньше.
1. Случай: Некоторые программисты оставляют комментарии и частицы кода, на случай если что-то пойдёт не так, и можно будет быстро бекапнуться и вернуться к начальному варианту ,или же наоборот пишется новый код для того чтобы им заменить старый ,но в итоге он оказывается нестабилен и соответственно неиспользуеться. Однако либо кодер забывает это вырезать ,либо к нему ползет дедлайн, либо он ленивая задница. В любом случае он забывает вырезать этот мусор, что в конце концов приводит к увеличению количества занимаемой памяти, а в особо лютых случаях к использованию лишнего ОЗУ (что очень важно на мобильных устройствах)
ДЛЯ САМЫХ МАЛЕНЬКИХ: Представьте у вас есть лего, вы наконец построили красивый дом, но в процессе постройки вы оставили за собой каркас такого же дома ,чтобы в случае землетрясения вам не приходилось начинать строить новый дом заново. А также оставили за собой кучу понятных только вам пирамид, шестиугольников, треугольников из которых можно "развить идею" и создать дом круче своего ну или же которые могут просто пригодиться.
2. Случай: Этот случай даже проще. Типичные дерьмокодеры часто делают все так-как им удобно. К примеру вместо того чтобы запилить array будут запиливать каждую переменную по отдельности ,или что ещё хуже вместо типа integer будут везде ставить real, ведь real круче integer потому что в нем больше чисел, и он везде пригодиться. Только вот незадача! Некоторые числа делятся с бесконечным результатом! Из за чего приходиться их округлять, потом снова округлять, и снова ,что в конечном итоге приводит к тому, что 10:3+1=4, а потом ещё куча таких хе вычислений с числом 4 и в итоге больше ошибок в коде и соответсвенно вылетов.
ДЛЯ САМЫХ МАЛЕНЬКИХ: Представьте вы построили домик из лего. Но дом получился некрасивый потому что вы не использовали маленьких блоков т.к с ними трудно возиться и долго мучаться их тонкой расстановкой. И использовали ненужные большие неровные блоки которые удобно лежали в руке и удобно скреплялись между собой.
3 Случай самый простой: Строчки кода которые можно сократить без потери функциональности.
ДЛЯ САМЫХ МАЛЕНЬКИХ: Вы строили дом из лего ,но в куче конструктора вам было лень искать двойные блоки для постройки дома т.к их было мало плюс их засыпали кучей одинарных блоков из которых тоже можно построить дом. В итоге вы построили дои использовав 100 одинарных блоков хотя можно было использовать 50 двойных, и дом у вас получился хрупким сложным непонятным. И если упадёт хотябы один одинырный блок то сломаться весь дом, Но двойные блоки сидели бы крепче и шанс того что они отдаляться соответственно меньше.
Или пытается разобраться с чужим кодом.
И так каждый раз когда срутся прогеры, хотя читаешь все это дело и как то даже интересно
Чувствуешь себя как Воловитц...
Я чувствую себя как тот, кто зашел не в тот район второй год подряд.
Бл"ть что я сейчас прочитал!!!??????
Чтобы написать коммент, необходимо залогиниться
