Невнимательный программист

Учусь в институте и параллельно вот уже год работаю... Вижу свой огромный минус — не очень хорошая память и невнимательность. Или же меня в этом убедили..
У многих ли бывало такое, что и хочешь, и учишь, а дела не складываются супер, все время ругают за баги?да и сам собой недоволен, складывается даже впечатление, что зря выбрал карьеру айтишника... Хотя в инсте на потоке один из лучших как программист. Или же это в принципе нормальная ситуация? Посоветуйте, что бы вы делали в такой ситуации?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

Закон Мэрфи: «Если что-то может пойти не так, оно обязательно пойдет не так». Все, абсолютно ВСЕ программисты делают баги. Твоя задача научится исправлять свои баги до того, как их заметят другие. Тут выбор за тобой: контрольная проверка, TDD, модульные тесты и накопление опыта, чтоб когда пишешь код была мысль: «ага здесь может вылезти потому, что...»

Работай над собой и все будет хорошо, идеальных программистов не бывает..

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
вопрос по ходу: вас одного «чмырят» за баги, или колегам тоже достается ?
--------------------

о багах: баги неотьемлемая часть софта. нет ни одной bug free софтины. исправление багов это часть производсва. даже гуру делают баги.

о ругают: мож это у них такой стиль менеджмента — нагнуть, опустить — чтоб люди пахали и еще думали что им переплачивают. а потому работали лучше (раз лучше не получается, значит БОЛЬШЕ).

создание прессинга с целью, чтоб люди пахали «усерднее» за те же бабки это часть работы менеджеров, так сказать повышают ROI :) - больше результатов на те же деньги.

что делать: Не принимайте близко к сердцу. Старайтесь работать стабильно. Если менеджер видит, что «втык» привел к вашей большей производительности — знайте, что следующий «втык» не за горами, вы его получите сразу, как только ваша производительность понизится ( или менеджеру так покажется). Часто у керивныков просто скотское отношение к подчиненным и все, это нужно увидеть и не мучить себя, этим занимаются они :)

Поработайте год, чтоб опыт был, если атмосфера не изменится — прекидайтесь на другую контору

статья для псхологической разгрузки:
news4geeks.net/...rself-to-death

:)

если система — ОК то и помнить все не нужно )

А так ... знавал котов без улыбок:
трогаешь ЮИ, а должен помнить какая погода на Марсе.

Вижу свой огромный минус — не очень хорошая память и невнимательность. Или же меня в этом убедили..

Убедитесь, что вы не окружены идиотами...(З. Фрейд.)

Вот если бы ты был авиадиспетчером, то да, была б проблема, а так...

Тебе нужно убедить всех, что а) ты невнимательный б) у тебя плохая память и это НОРМАЛЬНО.

Ну может больше внимания стоит уделять тестированию, в том числе автоматическому, тогда будет и совесть чище, и больше уверенность, в том, что ничего не накосячил. Единственный совет.

с) для выполнения а) и б) не забыть бы курс НЛП пройти :)

Здоровый пофигизм на людей, которые не поддаются внушению тоже подойдет. Но да, будет сложнее.

Тебе нужно убедить всех, что а) ты невнимательный б) у тебя плохая память и это НОРМАЛЬНО.

Это плохой совет. Люди привыкнут, и будут не воспринимать, и «гнобить» с поводом или без.

Это к делу не относится. Гнобят тех кого нет к себе уважения. Если ты нормально себя воспринимаешь и нормально себя подаешь, то гнобить никто не осмелится. А если осмелится — будет послан.

нормально себя подаешь

Вы так говорите, бдто есть универсальный рецепт «подания себя»... все зависит от субъективных мироощущений и социальных позиций авторитетов в команде.

то гнобить никто не осмелится. А если осмелится — будет послан

Непосредственно гнобить, может, никто не будет, но отношение будет «уже не то».

А где ты работаешь?

Вообще, уделяй больше внимания тестированию, не стесняйся дебажить свой код. Заяви больше времени на задачу, но сделай её качественней. Если же ставят жёсткие таймрейты, то лучше смени место работы.

Не парься. Твоя внимательность важна лишь замшелым преподам, которым ЧСВ велит заставить тебя выучить что там на 324й странице мелким текстом внизу страници написано в учебнике, который они тупо зачитывают изо дня в день.
Если ты тяп-ляп-сто-багфиксов-в-день, но никого из начатьства неимёт какая там у тебя внимательность. А если ты такой внимательный, что из фикса уголка в форме раздуваешь архитектурную проблему - но нафик ты такой внимательный не нужен.

Расслабься! :)

А если ты такой внимательный, что из фикса уголка в форме раздуваешь архитектурную проблему — но нафик ты такой внимательный не нужен.

Об архитектурных проблемах во всю спрашивают на собеседованиях, гоняют вдоль и поперёк, а на деле — просто хотят быстро, до показа клиенту, пусть хоть всё трещит по швам....

Об архитектурных проблемах во всю спрашивают на собеседованиях, гоняют вдоль и поперёк,
Вы из какой параллельной вселенной? ;)
НИ РАЗУ меня не спросили об архитектуре на собеседованиях, и, я так догадываюсь, это потому, что 90% процентов людей ничего не знает об архитектуре, а оставшиеся 10% знают что ОНА ГДЕТО ЕСТЬ! :)

Разнорабочие на стройке тоже ничего не знают об архитектуре :) И даже шаблоны проектирования барокко, рококо и прочие матюки тем более :)

Ну, во первых, почитать Э. Дейкстра "смиренный программист". Программирование - реально сложная штука, выше человеческих возможностей, потому все пишут баги - это нормально, надо просто принять и не беспокоиться по этому поводу.

Во-вторых, не стоит пытаться "притянуть" себя к какой-то задаче или работе. Лучше найдите ту работу (в программировании), которая у вас получается легко, и далее, постепенно, пробуйте, что можете добавить. Не все программируют одинаково. Более того, дискомфорт наступает не от того, что ВЫ не подходите а от того, что работа не подходит ВАМ. Я знавал программистов, которые заново рождались как специалисты просто уйдя с одной работы и поступив на другую.

И, в третьих, год работы - совсем не много. Программирование - сложная штука, см. выше. Всё придёт со временем.

P.S. Учиться и одновременно работать - адски трудно. Я бы посоветовал уделить всё время учёбе а потом - работе, если есть такая возможность.

Есть ещё такой вариант - вместо того, чтобы суетиться и пытаться соответствовать всему, что от вас хотят, просто начинайте "основательно тормозить". Пусть приспосабливаются к вам. Этому, однозначно, стоит поучиться. Химия - дорога в никуда, IMHO

Химия - дорога в никуда, IMHO

Однозначно в никуда - когда выписывается себе самостоятельно. Без врача, психотерапевта, квалификации которого можно доверять, и который вначале скурпулезно диагностировал проблему.

С антидепресантами и ноотропами примерно как с обезбаливающими. Можно так наснимать симптомы что до депрессии(клинической, а не "депрессухи" которая через три дня сама прошла) и нервного истощения докатишься.

совет простой: не втыкать на работе "вконтакте" и, как правильно советовали ранее, - завести записную книжку, куда руками вносить задачи и сроки.

только самодисциплина поможет свести невнимательность к минимуму, а "дела не складываются супер", - так это от нежелания работать, что-то видимо не нравится в окружающей обстановке....

Если внимательно и честно заглянуть в себя, не видишь ли ты в себе фоновое чувство тревожности?

Ну по своему опыту знаю, что если есть такая проблема, то копать нужно в первую очередь не в сторону улучшения памяти или внимательности (это тоже можно, но это медленный процесс), а в сторону применения техник, которые нейтрализуют эти "недостатки" (присущие, впрочем, большинству хомо сапиенсов). Т.е. как уже сказали ниже, Test-Driven Development при написании кода, и от себя добавлю - GTD для общей самоорганизации.

По поводу ноотропов (тут в каментах про них вспомнили) - их действие до конца не изучено, и на каждого человека они действуют по-разному (могут вообще не оказывать никакого эффекта, из-за чего есть точка зрения, что ноотропы - это такое плацебо). Но можете попробовать, при разумном подходе вреда не будет: у нас в аптеках можно найти пирацетам (он же - ноотропил) и прамистар. И точно вреда не будет от хорошего витаминного комплекса.

И да, не стоит путать ноотропы со психостимуляторами вроде фенотропила. У ноотропов действие медленное, нарастающее при регулярном употреблении в течение нескольких недель. Фенотропил же позволяет вам "взять взаймы" ресурсы организма и проработать сутки подряд, но за этим следует жуткий отходняк на пару суток. Резюме: если вам себя жалко - не покупайте эту каку.

За что я не люблю модульное тестирование - так это за то, что хоть и помогает улучшить существующий код, иногда избавляет от желания найти более красивые и надежные техники написания программы.

Э-э-э...
Я как раз люблю TDD именно за то, что оно _заставляет_ писать более прозрачный и надежный код. Например, применяющие TDD люди очень быстро отучиваются использовать синглтоны, больше внимания уделяют проектированию интерфейсов, сразу прорабатывают всевозможные юз-кейсы для тестируемого класса.

Хм. Я не против тестирования, просто как бы объяснить? Допустим я подозреваю в коде возможность невыхода из рекурсии, что лучше - написать тест, который отлавливает ошибку или подумать над самой организацией программы, накорябать в уме или на бумажке алгоритм, посмотреть примеры похожих кодов? Может быть даже рекурсия вообще плохо подходит для решения данной задачи, если подсознание сомневается в результате. Подсознание ведь не только об исключениях помнит и заставляет припомнить сознание. Оно еще и эстетично)

накорябать в уме или на бумажке алгоритм

Или в тесте:
1) Оно должно возвращать 1 если параметр меньше равно нуля

2) Оно должно возвращать произведение параметра на результат вычисления себя от параметр - 1

Например, применяющие TDD люди очень быстро отучиваются использовать синглтоны...

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

Она как бы у всех одна и та же - явный запрос синглтона.

Если его запрашивать через локатор, или у контейнера DI + получать по интерфейсу, то конечно без разницы, синглтон тебе дали, или новенький объект.

Другими словами, проблема та же, когда все значимые объекты в коде создаются с помощью оператора new.

Такой код потом сложно обкладывать тестами, потому что тест не может подменить для рабочего кода объекты своими заглушками. Из теста невозможно будет контролировать места создания объектов.

я правильно понял? от синглтонов отказываются исключительно потому, что не могут адекватно покрыть тестами код который, эти синглтоны использует? и это единственная причина?

я правильно понял? от синглтонов отказываются исключительно потому

Отказываются из-за высокой связанности. Усиления зависимости.
ru.wikipedia.org/wiki/GRASP

martinfowler.com/…/injection.html

и это единственная причина?

Это вообще не главная причина.
Просто контекст разговора был завязан на TDD.

А она, методика эта, тоже очень не любит высокую связанность.

Потому что и без нее - синглтон весьма дурно пахнущая вещь что по дизайну см GRASP выше, что по архитектуре - см Фаулера выше.

Не догматически конечно. Просто - синглтон это паттерн с душком. Или когда надо по бытенькому, да по мелочи.

P.S.

Синглтон, это замаскированная глобальная переменная.

Берни Козелл (из книги Питера Сейбела "Кодеры за работой"):
После этого на планерках они спорили со мной: "Почему вы жалуетесь, что я прописал глобальные переменные здесь, что я делаю то-то и то-то, что вам не нравится моя структура подпрограмм? Программа же работает?"

Их удивлению не было предела, когда я отвечал: "Конечно, программа работает. Вас взяли сюда именно потому, что вы умеете писать работающие программы. Написание программ - чисто ремесленный навык, и у вас он есть. А теперь вам нужно научиться программировать."

я правильно понял? от синглтонов отказываются исключительно потому

Отказываются из-за высокой связанности.

Каким это макаром синглтон усиливает связность?

Просто - синглтон это паттерн с душком.
...

Синглтон, это замаскированная глобальная переменная.

субъективно, у меня складывается впечатление, что вы "не любите кошек". имхо бенефиты в производительности, которые дает синглтон (в качестве хранилища долго инициализируемых данных для read only purposes, например, конфигурации), таки перевешивают вероятность синглтон траблов в результате применения его же программистом (с альтернативно растущими руками) в качестве глобальной переменной (для обмена данными).

субъективно, у меня складывается впечатление, что вы "не любите кошек".

Ну если всего лишь я, то не вижу смысла обсуждать :)

бенефиты в производительности ... в качестве глобальной переменной

от синглтона почему-то в большинстве проектов игнорируются. Но у меня складывается впечатление что вы не в теме ни проектирования программ, ни копеечности бенефитов от синглотона (исключения конечно бывают).

И вы не в курсе что "не любит кошек" передовая мировая ООП общественность, а не какой-то форумный писака на dou под ником Sergiy Skynin

P.S.

У синглтона есть еще вторая большая бяка - код инициализации, который "мертво" связан с его вызовом. То есть при написании теста на код использующий синглтон мы должны знать свойства этого кода инициализации. Что некрасиво, ибо тест должен знать только API которые использует тестируемый код.

Оправданным использованием синглтона является система логирования. Но как раз в силу 2ух особых к ней требований - ее реализация должна как можно меньше зависеть от любого кода программы (иначе повышается вероятность ее сбоя вместе с программой, а нам то нужна диагностика сбоя нашей программы), и с минимальным оверхедом (то есть тяжелые контейнеры объектов под запретом).

И то, если посмотреть как организована почти обязательная обертка SLF4J - то видно что ее API и сама работающая часть основательно разделены. В отличие от - синглтона, как он обычно описывается в учебниках.

Но у меня складывается впечатление что вы не в теме ни проектирования программ

не в теме. в основном приходится разгребать то, что спроектировали другие. типа ibm websphere commerce, то и дело загибающегося от случайного чиха не в ту сторону...

ни копеечности бенефитов от синглотона.

про "копеечность" я где-то слышал. разве не копеечность x количество вхождений в код x количество запросов = тот самый "рублевый" перфоманс?

"Велосипедист" самоучка наверное...

)) и не скрываю. удивляет, что такой мэтр, как вы, не в состоянии объяснить на пальцах такому нубу, как я, банальные (казалось бы) вещи. даже "трудно тестировать" в ваших словах звучит неубедительно.

не в теме. в основном приходится разгребать то, что спроектировали другие.

Тогда да. Критика синглтона достачно свежее явление. Я бы вообще ситуацию в ООП назвал не кризисом, как то любят говорить гуру от ФП, а переосмысленнием того что казалось банальным.

я где-то слышал. разве не копеечность x количество вхождений в код x количество запросов

Запросов каких?
Есть затасканный пример:

Сколько вы выиграли на оптимизации цикла, когда единственный лишний запрос к базе данных на порядки дольше?

что такой мэтр, как вы, не в состоянии объяснить на пальцах такому нубу

Я уже объяснил. Подробности находятся в книгах на сотни страниц. Или хотя бы на сайте Фаулера, у него помнится есть отдельная статья о синглтонах.

Нуб же нубу - рознь. Как и вопросы есть с вопросительным знаком в конце, а есть - с восклицательным.

То что я плохо объяснил - ваша проблема, а не моя. Мои знания не испортились, а вот вы - не приобрели новых. Спорить со мной нет смысла - потому что не я законодатель моды в мейнстриме, а в нем - все чаще ругают синглтон. Вы же да, можете пробовать писать против ветра. Пока на личном опыте не убедитесь в недостатках этого действия :)

А дальше начинается как в истории с публичной лекцией А. Попова о прокладке трансатлантического кабеля. Когда "в секции вопросов и ответов" одна дама встала и спросила:
- Спасибо за замечательную лекцию, но как вы все же объясните что телеграммы проходят по дну океана и остаются сухими?
Попов замэкал, забэкал, и дама победно оглянув зал села.

Так что да, с мэтрами бывает, не получается у них иногда объяснять на пальцах :)

Я начинал профессиональную карьеру программиста с С. И уже там было дурным тоном использовать глобальные переменные для обмена данными. Я уже просто забыл почему. Как по рукам били - помню, а объяснения уже как-то забылись.

Извините что не помог вам избавиться от предстоящего битья и по вашим рукам.

вы, уважаемый, все время куда-то ускользаете. я попытался прояснить для себя недостатки синглтона как паттерна, а вы мне про оптимизация в циклах vs оптимизация на запросах к бд, плюс про пагубность использования глобальных переменных для обмена данными... неконструктивное общение.

я попытался прояснить для себя недостатки синглтона как паттерна

Я о них упомянул.
Вы мне стали рассказывать о каких-то его преимуществах. В качестве перфоманса.

Конечно, если программа только тем и занята что дергает метод какого-то синглтона - перфоманс будет важен. Но реальные программы куда больше теряют на работе с внешними источниками и блокировках на общих данных, чем на вызове какого-то метода у объекта.

про пагубность использования глобальных переменных

Вы как не читали о "замаскированная глобальная переменная"

неконструктивное общение.

Потому что у меня нет вопросов о плюсах синглтона. Нет вопросов и о его недостатках. Поэтому я не получу никаких новых знаний, даже если они мне требуются. То есть - закрыт для диалога по этому вопросу.

У вас вопрос есть. Поэтому, утрировано - это вам положено "молчать и слушать". Получить максимум информации, обдумать, раскритиковать или согласиться, но вначале вытянуть побольше.

Или да, искать другого разъясняющего.

Перечитайте внимательно, я дал вам источники, и краткие ответы-наводки на самостоятельные размышления и поиски.

тест должен знать только API которые использует тестируемый код

Это говорит

передовая мировая ООП общественность

, или

какой-то форумный писака на dou под ником Sergiy Skynin

?

Уважаемая барышня, Вы хотите обсудить идею, или стиль написания постов неким Skynin'ым?

Для особо одаренных я повторю свой вопрос, а именно, хочу получить объяснение сумбура, цитирую: "тест должен знать только API которые использует тестируемый код"

тест должен знать только API которые использует тестируемый код

... и не только тест.

Почему - кроется в ответе на вопрос:
Какой код предпочтительней(чаще встречается) на Java и аналогичном языке:
public List<foo> getListFoo() ...
или

public ArrayList<foo> getListFoo() ...

Предпочтительнее вообще-то IList<ifoo> (кто-то этажом выше писал о DI контейнерах, и слабой связанности). А вы можете по существу ответить?
upd:

слово API в вашем случае следует рассматривать как максимальное абстрагирование от конкретной реализации?

Правильно.

Подходим к существу вопроса.

IList предпочтительней потому что уменьшает зависимость от реализации. То есть - уменьшает связанность кода.

Богдан ввел важный термин "изоляция тестов" в TDD (Везде, где требуется доступ к внешним ресурсам, должен быть объявлен интерфейс, через который этот доступ будет осуществляться. См. принцип инверсии зависимостей (dependency inversion) для обсуждения преимуществ этого подхода независимо от TDD. в
Википедии "Разработка через тестирование". А лучше прочесть эту книгу Кента Бека)

Так вот, ее тем проще делать, чем меньше связанность.

При этом - пропаганда в мире ООП за уменьшение связанности - массовая. Две ссылки на метров я привел.

Могу еще Буча процитировать. Или поискать картинку, чтобы без букв, из его книги, где тетенька жмет на красивую кнопку, а в ответ ей вываливаются все потроха-провода устройства.

P.S.

слово API в вашем случае следует рассматривать как

API определяет функциональность, которую предоставляет программа (модуль, библиотека), при этом API позволяет абстрагироваться от того, как именно эта функциональность реализована.

Если программу (модуль, библиотеку) рассматривать как чёрный ящик, то API — это множество «ручек», которые доступны пользователю данного ящика, которые он может вертеть и дёргать.

Программные компоненты взаимодействуют друг с другом посредством API.

Источник - ru.wikipedia.org/wiki/API

Да это никому не нужные заморочки, ИМХО. Я вот недавно дизайнил библиотеку с логикой домена, завязанную на EF, и у которой сущности описаны как POCO классы. Так чтобы сделать юнит-тесы, чтобы проверить валидность бизнес-процессов домена, мне лично пришлось использовать в юнит тестах конкретную реализацию контейнера этих POCO классов, и конкретно завязываться на EF (чтобы знать состояние ДО и ПОСЛЕ). За это разве нужно расстреливать? :)

Да это никому не нужные заморочки, ИМХО.

ИМХО, ИМХО не тождественно "никому"

слово API в вашем случае следует

Под API я понимаю:

API определяет функциональность, которую предоставляет программа (модуль, библиотека), при этом API позволяет абстрагироваться от того, как именно эта функциональность реализована.

Если программу (модуль, библиотеку) рассматривать как чёрный ящик, то API — это множество «ручек», которые доступны пользователю данного ящика, которые он может вертеть и дёргать.

Программные компоненты взаимодействуют друг с другом посредством API.

ru.wikipedia.org/wiki/API

Нет никакого моего случая.

мне лично пришлось использовать в юнит тестах конкретную реализацию контейнера

Если используется контейнер, то он используется и в тестах. Об этом reality_hacker уже написал.

За это разве нужно расстреливать? :)

Ну почему же, куча сайтов на php работают, хотя код их ужасен. Где ж набрать грамотных программистов, если их - дефицит? Поэтому пусть уж кодят неграмотные, с своими ИМХО и "личными" мнениями.

Под API я понимаю

на высшую форму абстракции интерфейс не следует говорить API :) это просто разрыв мозга

upd: лучше иметь личное мнение, чем просто зазубривать Фаулера и Бека, что в вас и наблюдается. Тем более, если бы вы хорошо Бэка читали, то те признаки, по которым нужно, скажем, делать рефакторинг - это не догма, это - чисто субъективное мнение, и на усмотрение разработчика, не так ли? А, ну да, я забыл: вы-не ремесленник, вы - философ :)

Погуглил.

"API класса" - вполне встречается. - "Помогают разработать API создаваемого класса. Вместо того, чтобы выдумывать интерфейс класса, вы вырабатываете его в процессе написания теста." из хлопской рекламы TDD (habrahabr.ru/post/114142/.

Или:

"Экспорт необщего типа посредством общего API-интерфейса"

Но если это принципиальный подход - ни в коем случае не называть интерфейс - термином API, то согласен, был неточен в терминах.

Суть сказанного мной такое уточнение изменило?

Суть сказанного мной такое уточнение изменило?

Вода - это водка, но только без спирта (примерно такая аналогия)

Из презентации TDD (www.cs.colorado.edu/…ures/21-tdd.pdf)

Writing tests first lets you work on specifying the API of the classes involved in the test

Не вижу где изменится суть, если вместо "API класса" использовать "интерфейс класса".

То что вы мелкий тролль, думаю и так понятно, без аналогий :)

Вы не видите, что буква А, и даже P буква лишняя, если мы рассматриваем просто тип???

p.s. Да хватит цитировать, говорите своими словами!

да, да, еще к запятым пристебайтесь! :D

Да хватит цитировать, говорите своими словами!

Я и сказал. Вам это взорвало мозг (надо же).
Поэтому начал цитировать, что такое отождествление API и интерфейса к классу вполне распространено, а не моя выдумка.

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

Чем больше середнячков думает, что интерфейс = API, тем лучше нормальным специалистам :) А как насчет маркерных интерфейсов, а??? :))) У них вообще нет методов, они не служад для связи с конкретной реализацией, и соотв. не могут служить как programming interface. вот облом, да?

Скажем,
msdn.microsoft.com/…nlysessionstate

msdn.microsoft.com/…ressessionstate

Это API??? :)

Я уже признал, что согласен, что строго говоря интерфейс в языке программирования и API - не тождественны. Если надумаю писать статью, или монографию, буду следить за корректностью.
Но как меняет суть сказанного в контексте разговора о TDD, синглтонах?

Мало того, в контексте разговоров о TDD такое отождествление не редкость.

Вы мелковато троллите. Пристебы к орфографии, стилю, запятым и неточностям - признак либо обиды "хотел потешить ЧСВ, и не вышло! Ну я хоть так укушу!"
Я уже вам писал - нет смысла тявкать, ни в мой адрес, ни в адрес других. Потому что уязвленное самолюбие так не лечится, а только раздрачивается.

"Ставлю в игнор".

Пристебы к орфографии, стилю, запятым

Не трынди, вопросы были по существу, а ты только абстрактно отгавкивался :)

Но как меняет суть сказанного в контексте разговора о TDD, синглтонах

Подумай, погугли как корректно использовать синглтоны в DI контейнере, и ты прозреешь

что за проблемы у вас синглтонами?

Да, да, в моем мире тоже все синглтоны не содержат состояния :)
Но в реальном мире: Тест1 меняет состояние синглтона, а Тест2 валится потому, что не ожидает то состояние (а в мире моков еще и поведение) которое установил Тест1 или чего хуже тест проходит потому, что Тест1 установил какое-то состояние.

Это вроде называетсо "изоляция тестов".

Есть еще вариант устанавливать/сбрасывать значения в сетАп/тирДаун, но это скорее костыль да и налажать можно на раз-два.

В юнит тестах синглтоны могут превращатся в не синглтоны с изоляцией тестов.

Например явно его создавая с помощью конструктора в тесте, а в программе инжектись с помощью твоего любимого DI framework и помечать как @singleton

Кстати все еще проще если делать синглтоны с помощью DI, в тестах каждый раз будут создаваться новые DI context, и все будет правильно работать, т.к. singleton будер per context.

так об том то и речь :)

Что если с помощью твоего любимого DI framework - то большая часть неудобств уходит. Даже проблему разделения состояния синглтона между разными тестам можно решить.

Я не понял о чем это о том и речь.

речь была о том - чем синглтон плох для TDD, и вообще.

У вас в постах тоже есть это слово - singleton

Да, да, в моем мире тоже все синглтоны не содержат состояния :)

:D
Причем, если нечто не содержит состояния, то зачем оно делается синглтоном? Ведь в синглтоне как раз и возникает потребность, когда нужен объект с состоянием, и состояние это важно настолько, что такой объект должен быть единственным все время работы программы.

Частным случаем является синглтон ради доступа к единственным данным. Скажем к некоему внешнему сетевому соединению. Но тут тоже, представим себе как тестировать код, который внутри вызывает такой синглтон.

всегда считал, что setup() и tearDown() и существуют именно для того, чтобы test1 никак не влиял на test2. неужели использование этих методов по назначению теперь считается костылем?

В данном случае кроме самих методов появляется проблемы с паралельным запуском тестов, что есть большая проблема если тестов много.

логично. но если параллельно запускаемые тесты валятся, ибо так зависимы от некоего состояния некоего глобально видимого объекта, разве не ожидаемо аналогичное поведение в многопоточном live приложении? ведь, если приложение спроектировано как однопоточное, то и тестироваться оно должно соответственно. в противном случае налицо проблемы с некорректным использованием mutable объекта.

разве не ожидаемо аналогичное поведение в многопоточном live приложении?

Это уже третий недостаток синглтона. Адепты ФП возводят этот недостаток в глобальный для всего ООП - "сохраняемого состояния не должно быть!"

А как, эти ваши адепты ни дб ни файловой системой не пользуются?

Очень правильный вопрос :)

Процитирую по памяти из выступления А. Степанова, одного из авторов STL для С++, в офисе Яндекса (в инете есть видео, получил массу удовольствия. Особенно когда он сказал что древнегреческих философов стоит знать и почему)

Ему был вопрос о крутизне ФП, и он сказал

Да, в конце 70ых я был ярым приверженцем. Но... вы пробовали на чистом ФП работать с базой данных? Попробуйте. Меня попустило.

применяющие TDD люди очень быстро отучиваются использовать синглтоны

Почему?

Я всегда все стараюсь записывать (буквально пометка, несколько ключевых слов, но делать это нужно тут же не откладывая).

Замечать свои слабые стороны - плюс. Но только если подходить к этому конструктивно.

Я всегда говорю себе: "ничего, могло быть и хуже". Хорошо помогает -- очень скоро становится намного хуже. :))))

Так є ж спеціальні там книжки і вправи і ігри всякі. Наприклад "Гімнастика для розуму" Кротов І. С. чи Меженко Ю. С. "Быстрое и еффективное развитие памяти, внимания и умственных способностей". Це те, що я дістав зі своєї книжкової полиці. Я думаю знайти щось подібне в Мережі не важко.
Із ігор, наприклад gbrainy en.wikipedia.org/wiki/Gbrainy .
Чому б не скористатися якимись медикаментами? І попить полівітамінок, прокунсультуваться у лікаря?
Чому ви думаєте, що у вас не все гаразд із цими параметрами? Мабуть інують якісь тести для визначення того наскільки ваша пам’ять, увага "нормальні".

PS Є така цікава і пізнавальна книжка за авторством Даніель Лапп "Искусство помнить и забывать".

Только я удивлена, что никто не упомянул о ноотропах? :)

Дык ноотропы могут привести к ноотрупам

Вот видите — вы сами признаете, что вегетарианство безопаснее)

Косвенно. Вегетарианцы живы и пишут на ДОУ, а из употребляющих ноотропы никто не написал, потому что вы правы - они ноотрупы. ДОУ не даст соврать)

То есть, по-вашему, кто не вегетарианец - тот ноотруп?

ну, если вы сделали такой логический вывод, то я очень сочувствую :) давайте не застревать на этом)

Ну я вот принимал курсами пирацетам и прамистар. Вам легче стало? :)

Привет, ноотруп!:)

Сюда должны набежать вегатерианцы, и сказать, что растительная диете крайне способствует развитию умственных способностей.

З.Ы. извените за троллинг, если че ;-)

Лучше бы сюда набежали те, кто несёт ответственность за свои советы, ведь им могут последовать.

Это можно применить ко весему форуму ДОУ...

Пишите строго в TDD и будет вам счастье.

Если ошибки действительно от невнимательности, а не логики, то первое время помогут лишь постоянные перепроверки - вот не хочется, но нужно. Меня учили - ошибаться не стыдно, но ты обязан(а) сам(а) перепроверить результат. Если ошибки логики, из за стресса там, или неопытности - ну что сказать... подумай, действительно ли любишь эту работу, если да, то старайся больше. Особенно поможет изучение чужого хорошего кода. И еще нужно развивать умение сосредотачиваться на цели, сохраняя мотивацию, хладнокровие, не путаясь и не спеша... Неважно наверно, что вы в институте лучший как программист. Главное, что бы был внутренний мотив сделать свою работу идеально.

Waylander,
Во-первых, ты должен правильно расставить приоритеты. Если тебе больше нравится кодить, то сделай так, чтобы на работу у тебя оставалось больше времени и энергии.
Если тебя ругают за баги, то спроси себя сам, насколько ты часто допускаешь ошибки и из-за а чего. Да, есть невнимательность, когда ты забыл превалировать значение из формочки или делаешь запрос в базу, не открыв соединения. А может быть тебе не хватает требований, ты делаешь свою работу, а потом оказывается что ты сделал все классно, но не то что нужно?
Это разные вещи. С невнимательностью нужно бороться, отводя больше времени на отдых и анализ ошибок. Второй случай – это не только твоя личная проблема.

Так вот, если тебе нравится программировать – сделай все достаточное чтобы лишь получить диплом: покупай оценки, лабы, договаривайся, ползай на коленях перед препадом и делай жалостливое лицо котика из Шрека. Но, сделай так чтобы на учебу оставалось меньше времени, а на работу больше.

Если тебе нравится учится – то учись себе спокойно. На работе можешь перевестись на проект менее требовательный к внимательности, или уволься до окончания института.

Один мой знакомый работал и учился. При этом и техникум и институт (заочно) он закончил с красным дипломом. На работе его считали классным программистом. И он еще лабы и контрольные своим одногрупникам делал. Он действительно умен и всегда находил енергию чтобы успеть все и качественно. Я понимаю, что я не настолько умен, поэтому мне пришлось выбрать 30% учебы /70 % в пользу работы.

У меня были хреновые оценки, но зато по карьерной лестницы и скилам мне удалось добиться результатов, которые сейчас меня вполне устраивают.

Вас спасет TDD :)

Главное чтобы не ADD (Asshole driven development)

С использованием экскремального программирования :)

нормальная ситуация. Будет больше опыта - будет больше уверенности в себе.

не очень хорошая память и невнимательность. Или же меня в этом убедили..

Хотя в инсте на потоке один из лучших как программист. Или же это в принципе нормальная ситуация?

да, ситуация стандартна как грабли.
приём называется =педалирование чувством вины=

его активно применяют жадноватые и не очень внимательные работодатели.

Вот и я долго считал, что у меня хреновая память, невнимательность и рассеяность. А на деле же у меня отличная память, внимательность и нерассеяность ровно там, где мне интересно.

Мне в свое время помогла соционика взглянуть на свою жизнь под правильным углом. Все мое поведение отлично ложится в описание психотипа «Дон Кихот». Посмотрите, возможно это и ваш случай. Например тут: www.sociotype.ru/donkihot.php

Ну ничего, связал как-то свою жизнь со своими интересами, даже чего-то достиг.

Еще гороскоп предложи посмотреть

Предложу расширять кругозор, а не рефлексировать на психологические темы. Соционику вывел математик. Брат-программист может лишь TDD вывести, как я погляжу.

как на счет того если язык программирования введет балерина? я открою новость, соционика не признанное направление наравне с парапсихологией. и это я говорю не как прогер, который увлекся тестом, а как человек имеющий психологическое образование и пятилетний стаж практики в консультировании и терапии. никто из психологов с терапевтической практикой (а не шантропы ездящей по ушам на тренингах) не занимается соционикой. что называется — сделайте правильные выводы.

Ну все равно, в этом что-то есть. Просто донкхиты, санчопансы, бальзаки, наполеоны и т.д. - ИМХО это собирательный образ, который основан на результатах твоих ответов на тесты, не так ли?

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

Ну а современные психотерапевты не отрицают типы темпераментов?

типы темпераментов это больше дань истории (гиппократ, павлов) в психологии, чем практическое значение. ни один из выдающихся психотерапевтов, психотерапевтов-теоретиков не упоминает типы темпераметров в своих трудах ( Фрейда, Райха, Хорни, Перлаза, Ялома и т.д.).

Никто не прогоняет клиента по тесту скорости протекания психологических реакций, а потом проводит с ним работу, хотя, может для себя отметить, в работе — «ага, он флегмат — нужно с ним по-медленней». Но ставить это во главу угла... — нет и нет. тем более соционику.

Вот! Я так и знал! Вы попираете все догмы! Вы - еретик! :)

да какие там, нафиг, догмы... есть рабочие вещи, а есть все остальное.

А вообще забавно, только, мужики, без обид, иногда складывается впечатление, что программеры самые умные люди на свете, и после сеньора у них включается саморегенирация и они даже раком не болеют. Вы это... режим бога иногда выключайте :)

От рака я знаю только Гуртяк умер (создатель KeyRus), остальные умерли своей смертью (Ритчи, Постел)

Со страхом смерти я тоже работаю.
p.s. каждый доживет до своего рака, если не умрет от чего то другого.

И оставим эту тему, мне то все равно, но многим она не приятна.

Ох ты ж господи, понабежало дипломированных психологов с экспертным мнением. Далее мой пример.

От знания самого себя мне нифига хорошо не становилось, ибо было чувство своей ущербности из-за хреновой памяти, рассеяности, определенной асоциальности. Я пил всякую дрянь "улучшающую память", на деле же со мной все нормально, мне нужно было знать что я нормальный, соционика мне выдала мою картину, я понял что все мои особенности отлично ложатся на определенную карту. Я тупо забил на рассеяность, короткую память и занимаюсь проработкой своих сильных сторон чего и автору топика желаю.

Вам же желаю перестать мыслить дискретно, осознать что мир состоит из множества красок, а не исключительно из той херни что вас в институте заставили на память учить.

Науки-шмауки, уж вы-то должны знать, что хоть ходуном ходи, лишь бы результат был.

Александр, 100% правда. не специалист в миллион раз лучше понимает ситуацию чем специалист. куда уж нам... понабежавшим...

Я не психолог, но сразу видно, что автор темы с собой не в ладах на подсознательном уровне. Чем больше он будет волноваться и царапать больное место, тем хуже будет дело. Неважно, правильная штука соционика или нет, как и неважно, скажем натуральная я блондинка, или крашенная. Главное, что такие вещи помогают заглянуть в себя и с собой примириться, смотреть на себя позитивнее, какой то план составить... Известно же, что мышечную массу быстрее можно нарастить, если сосредоточиться на ощущениях при упражнениях, а не бездумно размахивать отростками...) Точно так же и с психикой...

Любят люди диагнозы (Дон Кихот, «не в ладах с подсознательным»). Я предлагаю автору топика ответить самому себе на: 1) невнимательность является постоянный атрибутом в жизни или распространяется только на сферу программирования?; 2) невнимательность появилась относительно недавно или была постоянно?
И уже исходя из ответом пляшем дальше.

Либо это личностная особенность. либо это результат каких либо стрессов или фрустраций. либо есть какая то психологическая проблема (и в этом ничего страшного нет).

А Вы постарайтесь поменьше видеть минусов и побольше плюсов. В институте учитесь более-менее честно? Если да то все OK, набьете руку, обрастете шаблонами(в хорошем смысле слова) и большая часть багов уйдет.

Баги бывают у всех. И это — нормальная ситуация (за исключением, конечно, провтыкать проверку на null :) Кто не работает — тот ест не ошибается. Если сильно будут ругать — поинтересуйся, а что ругающая сторона может конкретно предложить, чтобы было то, что ругающая сторона хочет. Если ты выполняешь все конкретные условия, с тебя и взятки гладки. Если ничего конкретного (типа, просто дрессируют), или говорят, мол, сделай то, не знаю что — делай выводы, или иди туда, не знамо куда :)

Причиной может быть стресс. Например от перфекционизма.

Гуглите — как бороться с стрессом.

внимательность и память поддаются тренировке

отчасти это вопрос опыта

или наоборот деградации, если бухать.

Указанные проблемы часто возникают из-за неудачного личного графика жизни.
в 7 встать, пойти на пары, потом 6 часов отработать, потом с друзьями «отдохнуть» и в 3 утра лечь спать — это плохой график )
Подстраивайте события, что бы и 8 часов сна было, и время нормально поесть было, и поработать/поучиться..

На любые допинги подсаживаться не рекомендую

Поддерживаю. Здоровый сон — один из основных залогов продуктивной умственной деятельности. Загонять себя, как лошадь на скачках — далеко не вариант. Алкоголь и курение тоже не способствуют хорошему тонусу. Если оные присутствуют в Вашей жизни, то советую сократить «дозы» и выработать график употребления (напр., курить не чаще раза в два/три часа; пиво/вино пить не чаще двух раз в неделю, один из которых — святая пятница :). От крепких напитков (водка, коньяк и т.д.) советую отказаться вообще. Хотя это нужно смотреть по своему организму — кому-то может быть легче 50-100 грамм водки чем литр-два пива). По поводу доппингов, тоже согласен. Но если уж совсем никак без оных, то лучше крепкий натуральный кофе, желательно с сахаром и сливками. В отпуск/каникулы на море или на природу с палатками съездить — самое оно. Главное, там «овощевать», а не работать ;)

А нормально отдохнуть 2-3 дня или хотя б неделю не пробовали ??? Лично я наблюдал такое у себя : посидел над книгой, порешал задачки скажем так хотел на силу по больше в себя затолкнуть информации и оно мне боков вылезло ... ходил целую неделю, не понимал что со мной твориться, думать нормально не мог, прочитал строку и забыл сразу или не понимал сути ... через неделю отдыха попустило... уж больно думал крыша поехала ...

Закон Мэрфи: «Если что-то может пойти не так, оно обязательно пойдет не так». Все, абсолютно ВСЕ программисты делают баги. Твоя задача научится исправлять свои баги до того, как их заметят другие. Тут выбор за тобой: контрольная проверка, TDD, модульные тесты и накопление опыта, чтоб когда пишешь код была мысль: «ага здесь может вылезти потому, что...»

Работай над собой и все будет хорошо, идеальных программистов не бывает..

не очень хорошая память

Записывайте. Ручкой на листочек. Не стоит держать в памяти то что надо сделать сейчас, что сделать через 2 часа и вечером.

Ватсон, поймите: человеческий мозг — это пустой чердак, куда можно набить всё, что угодно. Дурак так и делает: тащит туда нужное и ненужное. И наконец наступает момент, когда самую необходимую вещь туда уже не запихнёшь. Или она запрятана так далеко, что ее не достанешь. Я же делаю всё по-другому. В моём чердаке только необходимые мне инструменты. Их много, но они в идеальном порядке и всегда под рукой. А лишнего хлама мне не нужно. ©

невнимательность

Банально до ужаса.

1.Выясняем какой внешний фактор отвлекает внимание от основной задачи
2. Стараемся изолировать этот фактор.
3. ***

4. Профит.

все время ругают за баги?

Что-то мне подсказывает, что вы работаете на проекте, в котором нету тестеров :)

Даже если есть на проекте тестеры, я лучше покрою код своими тестами, пусть тестер тоже отрабатывает свою зарплату и находит неочевидные баги, а не те, что появляются по невнимательности.

Фраза была о том, что

все время ругают за баги
в конторах где на тестеров денег «жалка-жалка». Хотят сразу сферический код в вакууме. Ваш КЭП :)

Я начинал работать в маленькой фирме, в которой тестеров не было потому, что тупо не было денег, а задачи нужно было решать. И мы использовали такую вещь как перекрестное тестирование, когда часть времени другой программист проверял код товарища на баги и другую ерунду, покрывали сложный код тестами, практически каждые 2 дня. В продакшн у нас уходил очень качественный код.

Только потом, в большой фирме я узнал, что это называется code review по-правильному и проводится не чаще, чем раз в 1 месяц. Программист должен писать код, тестировщики тестить, программист снова исправлять и по кругу. В большой фирме, в продакшн у нас уходило куча багов, потому что тестеры делали свой план по найденным багам, аля забыл отступ от края 10пикселей для элемента формы и проверку на ввод бессмысленных символов, и спокойно пили себе кофеек остальное время. А потом пришел нормальный ПМ....))

Итак мой use case из опыта, то что программист работает без отдела тестирования не большая трагедия, главное находить способ ее решить, а не говорить, что так работать «не правильно» + большой опыт в написании действительно качественного кода ибо жизнь заставила.

P.S: и да меня ругали вначале старшие друзья-товарищи за баги, но при этом по-человечески объясняли почему такое произошло. Главная польза все относились к критике очень позитивно. В большой фирме, я столкнулся с «что ж ты оскорбляешь людей»...))

Видимо у нас разное восприятие слова ругают. Для меня оно носит чисто негативный характер. Из моего опыта меня именно ругали за баги, когда работал в одной маленькой конторе далеко не высокого полёта.

Перейдя в контору с уровнем повыше, я познакомился с конструктивной критикой, построенной по формуле: «Здесь плохо, потому что...». Такую критику всегда рад выслушать :)

Подписаться на комментарии