Как стать автором
Обновить
1
0
Александр Жиличев @9thlevel

Руководитель команды разработчиков

Отправить сообщение
Карьерный рост — это конечно очень хорошо. Но пример из личного опыта. Жила-была и процветала очень крупная торговая компания. Грянула первая часть кризиса, затянули пояса, но продолжали успешно работать. Громыхнула вторая часть кризиса, вырос курс доллара, компания начала сокращать персонал, потом загнулась и сдохла. В чистом остатке касаемо меня — плюс огромный опыт, минус 5 лет из жизни. При том, что компания была очень крупным игроком, о ней много говорили, собиралась на IPO. Так что о тылах нужно тоже не забывать, чтобы однажды не оказаться на обочине, особенно если вам уже за 40.
Пробовали вести переписку по разработке. Очень быстро поняли, что лучше голосовой коммуникации для решения стратегических вопросов нет ничего. Во время голосового общения как-то лучше улавливается то, о чем говорит собеседник.

Автор поднял отличную тему. Замечаю сам по новичкам, что надеются на память. Вспоминаю себя таким же, но после пары проколов стал фиксировать.
На самом деле тут двояко: он может как стать клиентом, так и не стать, в зависимости от заинтересованности товаром (может для себя покупает, а может просто разово в качестве подарка). Но есть одно большое НО. Которым, например, часто пренебрегают в компании, где я работаю: магазин должен не только выручку делать, но и клиентскую базу нарабатывать. Даже «одноразового» покупателя можно сделать регулярным. Мир меняется, исчезают и появляются цивилизации, но правило «довольного клиента» вечно :)
А что плохого в том, чтобы дать карту друзьям?
Высказаться можно, хаять не нужно :)
Автор, беги! Все, кому не понравился пост, не просто промолчать, а начнут изрыгать потоки хаотичных мыслей, стараясь заплевать тебя этим, начнут придираться. Потому что это не нравится именно ИМ! А кому понравился, просто улыбнуться. +5 за пост :)
А я не разбрасываюсь. Я именно подчеркиваю, что естественный отбор. Вы думаете, что если человек, то все, капец, венец природы? Да ничего подобного. Инстинкты правят внутри вас. Вот и получается, что за жизнь держится тот, кому она действительно нужна. Остальные сами выбирают свою путь. Помочь при возможность? Да, лично я помогу. Если человек «ушел», жалко? Нет, он сам сделал свой выбор. И минусуйте сколько влезет. Я думал, что мы тут дискуссию ведем, а не стараемся друг другу подгадить минусами. А за девушку я рад, что жизнь у нее продолжается.
Тем, кому хочется жить, ставим плюсы, кому не хочется, минусы :D
Не статистика, а естественный отбор. Слабые (духом, телом, разумом, нужное подчеркнуть) гибнут.
Многие иронизируют, сравнивают, умничают, а для кого-то это единственный шанс выжить. Жить ведь всем хочется, правда?
Я бы предложил навести порядок с разработкой, тестированием и накатыванием обновлений. Поскольку когда 5 разработчиков могут независимо друг от друга вносить изменения в одну и ту же форму и каждый может внести такое обновление, которое всё порушит это как-то ненормально.

Согласен, это ненормально. Вы знаете, я пытался. Но поскольку не являюсь руководителем, мои предложения уходят в космос. Есть еще куча нюансов, но они внутрикорпоративные. Это мое маленькое пояснение. Без дальнейшего развития и продолжения обсуждения :)
Возможно, я просто тупой и не понимаю чего-то в вашей статье. В таком случае, держите еще одно извинение, но поясните тогда мне, в чем состоит инженерная новизна (красота, если угодно) предлагаемого вами решения?

Почему вы ищите инженерной новизны? И полезность, насколько я понял, рассматриваете по отношению к себе. На текущий момент пост добавили к себе в избранное 19 человек. Им он оказался полезен. Помните такое выражение «И если из трех тысяч, меня один услышит, Поймет масштабы, значит вся идея дышит». Так вот, я не стремился показать, «как я крут». Я просто поделился наработкой. А где это разместил, это мое дело. Нет, не стыдно. Если вам не интересно и банально, проходите мимо. Серьезно.
Это очень распространенный workflow в сфере допиливания 1С. Заверни в «попытку», чтобы не было сообщений. Пользователю знать это не надо, ему надо чтобы не падало. Практика порочная, но в уравнении время-деньги-качество играет немаленькую роль.
Приходится много сил тратить, чтобы убедить разработчиков так не делать. Видимая ошибка лучше спрятанной.

Я понимаю, что существует «свое мнение и мнение остальных». Но данная моя статья не претендует на «идеальный код» и «идеальный пост». Опубликована она была с целью помочь кому-либо, бескорыстно. Может кому-то она подскажет решение, может кому-то окажется полезной. Кому-то окажется бесполезной, это тоже возможно. Но! Я с уважением отношусь к хабрасообществу, но частенько попадаются комментарии людей которые все могут и все умеют. Критикуете? Предлагайте.
Уважаемый, я вынужден вас попросить извиниться за непроверенное обвинение. Если вы внимательно посмотрите имя автора поста, который вы привели (http://infostart.ru/public/262631/), и имя, которое скрывается под моим ником 9thlevel, то убедитесь, что это один и тот же человек. То есть я. И эту же свою статью я опубликовал в своем блоге вот тут: http://zhilichev.blogspot.com. Прошу перейти и убедиться. Жду извинений.
В управлении доступностью и видимостью

Чтобы лучше понимать, что происходит, когда происходит и с чем происходит. Да-да, какой вопрос, такой ответ :)

Думаю, что код вида… негативно влияет на тестирование, а попытка нужна для того, чтобы в случае ошибки (причем только по независящим от программиста причинам, например отсутствие доступа к внешнему ресурсу) что-то с ней сделать (например попробовать еще раз с другим ресурсом или собрать информацию об ошибке и преобразовать её к виду, нужному для техподдержки и остановить выполнение)

Не буду вас отговаривать от вашего мнения. Только когда в команде 5 и более разработчиков, и время от времени каждый хоть один раз, но что-то изменяет на форме (особенно «новобранцы»), бывает это спасает.
Так зачем там этот уровень абстракции?

Там — это где?

Так вы не тестируете, прежде чем накатывать обновление на рабочую базу?

А вы сами как думаете?

А то, что там куча исключений, о которых вы без падений и не узнаете, а пользователи будут молчать о том, что галочка «Наличная продажа» не влияет на видимость галочки «Пробивать чек», ведь ни не знают о том, что так должно быть?

Пользователи должны работать, а не ошибки искать.
Adnako, думал об этом :) Несколько идей и наработок есть, в тестовом режиме использую у себя их. Но это мой первый пост на Хабре. Если не «распнут», напишу вторую часть.
Если же необходимость в этом уровне есть, то почему не объединены все списки в одну таблицу?

Лично я руководствуюсь принципом «все сваливать в кучу не стоит». Что можно разделить, то нужно разделить. Сугубо мое мнение.

Зачем там «Попытка» (которую я в свой код скопировал, пытаясь указать на лишний цикл)? Почему при неправильном коде (например при удалении элемента управления или опечатки) программа не должна падать?

Потому что бизнес-процесс (особенно процесс торговли) не должен прерываться ошибками. Оперативно устранить не всегда бывает возможно. А чтобы не падали программы, их нужно тестировать. Хотя бы по-минимуму.
Критикуете? Предложите свой вариант управления элементами. С удовольствием изучу Ваш опыт.
2

Информация

В рейтинге
Не участвует
Откуда
Россия
Зарегистрирован
Активность