Да.

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

Нравится, но только не то, что я уже писал.

>>675559
та же фигня. поэтому я пишу код так, чтобы документация была не нужна по возможности

>>675552 (OP)
P.S.
Мне кажется это зависит от того как мы проектируем. Я в голове все долго соединяю сначала, а уже потом перевожу на монитор. А этот чувак походу черновик набрасывает и как художник начинает детали вырисовывать и резинкой стирать.

ОП

>кодит со скоростью автомата калашникова

Предполагаю это он так вылизывает свой код. Написал, посмотрел, не то, взял, общие части вынес, поисправлял везде, смотрит снова.

>>675887
>Написал, посмотрел, не то, взял, общие части вынес, поисправлял везде, смотрит снова.
Вот вот. Комментирование - это основной его рабочий инструмент.

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

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

>>675910
Школьник плиз.

>>675910
Документация позволяет в сотни раз быстрее разобраться в цепи защелкнутых нейронов программистов в момент сатори.

>>675910
Читают голый код по скорости сравнимо с кодингом оного.

>>675941
*читать

Ненавижу. Просто теряюсь и забываю все нахер

>>675960
https://ru.wikipedia.org/wiki/Поток_(психология)
Там надо находиться. Но меня лично высасывает до дна такое состояние.

ОП

>>675552 (OP)

Я люблю спроектировать основные моменты на бумаге.

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

Коммент пытаюсь держать в районе одной строки, в рамках вопроса зачем

Если переменных дохуя(например мы можем скармливать хешь или название нихуя не понятные) или то я описываю переменные, и выходящие переменные.

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

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

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

Я очень люблю документацию уровня,

"что нужно, кратко"->"пример рабочего кода кратко"->"пример результата".

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

Считаю документацию которая идет к Питону самой годной. Так даже сторонние модули имеют годные доки.

Пытаюсь вписываться во временные сроки, оптимизацию не очень люблю так как считаю,
читаемость кода > говномоча > оптимизация > PHP > GOTO.

>>675552 (OP)
После определенного опыта использования очередного веб-фреймворка или ORM ты уже знаешь, как будешь решать ту или иную задачу, поэтому хуячишь даже не как калаш, а как шестиствольный пулемет. Ничего нового, ты просто пишешь очередной CRUD, сериализатор JSON, мок-тест или API-middleware к Auth. А все архитектурные задачи за тебя решает фреймворк. Думать надо только если ты рвущий шаблоны react-nodejs-noschema хипстер (попутно роняя в вечный 404 боевые проекты).

веб-макака

>>675552 (OP)
> У меня рядом прост сидит чувак, который кодит со скоростью автомата калашникова (уши закладывает от звуков клавы), исправляет и тестирует сутки напролет. Вот видимо он любит писать код. Еще улыбается целый день. Курит наверное.
https://ru.wikipedia.org/wiki/Аутизм
Пожалей больного человека.

> А любишь ли писать код ты, анон?
Смотря какой. Крудопарашу не люблю а приходится

>>675552 (OP)
Люблю писать код и ненавижу отладку.

>>678509
Пиши тесты

>>675552 (OP)
Я очень медленно все делаю, очень .

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

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

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

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

>>678539
На чем пишешь?

>>675552 (OP)
>А любишь ли писать код ты, анон?
Да, люблю.

>>675841
>А этот чувак походу черновик набрасывает и как художник начинает детали вырисовывать и резинкой стирать.
Я такой чувак: к моменту первого пуша в гитлаб в моих репозиториях уже десятки коммитов.

>>678539
Наш тимлид за такой оверинжиниринг в щщи прописывает.

>>675552 (OP)
>Я код писать ненавижу
Охуеть, а нахуй тогда пишешь?

>>679355
Жить на что-то надо, а больше ничего делать не умеешь, куда еще пойти?

>>679365
Ну да, хз.

>>679365
В технические переводчики, в науку. Я вот наоборот, ненавижу писать документацию к очевидным вещам, и ещё схемы к ним рисовать. Это ведь всё равно что писать тот же самый код второй раз, но на русском (или английском) языке.

>>675910
Ну например если код - нетипизированная дрисня на каком-нибудь джяваскрипте, то без документации можешь его сразу выбрасывать

>>679809
Документация протухает
Лучший способ реально документировать свой код - это писать спецификации/тесты

>>676598
>грязные тесты в юнит тесты
что такое тут "грязные тесты"?

>>680137
о, да
теперь вместо трех строчек кода нужно будет добавить еще двадцать на спецу и тесты

>>680459
Чистые тесты это когда ты пихаешь корректные данные, и ожидаешь что тебе на выхлопе придут корректные данные.

Грязные это противоположность чистых как говорит оно >>680481

Ты пихаешь не корректные данные, и ловишь конкретные ошибки.

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

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

>>680628
Отсебятину гонишь какую-то. Чистые-грязные, хуё-моё, есть же нормальные понятия code coverage: покрытие условий, операторов, путей - все за вас придумали, бери и пользуйся. Не могут уделить час изучению предметки, ну охуеть теперь.

>>680628
>побольше грязных тестов
Побольше это сколько? Можно и тысячу тестов написать, но они все могут принадлежать одному классу эквивалентности и хули с них толку в этом случае?

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

>>680137
Тесты можно использовать как документацию, но они протухают примерно с такой же скоростью как и документация. Единственное отличие, то что их как-то обновляют при изменениях. Хотя Говнокодеры могут чужие тесты просто взять и выпилить, точно так же как и забить хуй на документацию.

В общем от говнокодеров ничего не спасает, ни доки, ни тесты, ни целый отдел QA.

>>680137
>>680542
Цель у тестов, это отлов первичных багов, да и просто быть уверенным что все в модуле работает так как надо и правильно спроектировано (поэтому многие ратуют за TDD).
Если учесть в 3-5 годичном проекте используются много связанных модулей, что вполне возможно что метод будет состоять из вызовов 2-5 модулей, и еще обвязки старых костылей(например глобальные данные), и единственные возможности проверить код с учетом всего нахуеверченого говна, это написать юнит-тест сперва.

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


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

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

https://habrahabr.ru/company/sqalab/blog/217743/

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

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

Не корректных данных, всегда больше чем корректных.

>>680649

Покрытие, не равно корректные тесты. У тебя некоторые модули могут быть жопой написаны и всегда проходить тесты, и при этом покрытие кода будет близка к 100%

>>680673
>В книгах рекомендуют делать в 5 раз больше грязных, чем чистых тестах.
Ебать-копать это что за советы в стили вуду? Накидай говна в котел - авось супчик выйдет. Ты эту макулатуру сожги нахуй и разберись с матчастью. Хотя бы с классами эквивалентности.
>всегда проходить тесты, и при этом покрытие кода будет близка к 100%
Я тебе и намекал на это дурашка. Покрытие разным бывает. Вот ты знаешь что конкретно значит циферка с процентиком в твоем coverage tool?