Когда написал код, не читая документацию, но оно работает
Еще на тему
у мидлов, которые документацию читали и смотрят на это, наступает состояние ахуя и возникает нехватка слов для аргументации.
Та работает же
и можно еще резать немного, если понадобится. доп фича.
Это зажим, он не режет.
Режет, режет, мы уже попробовали *показывает разрезанную БД*
А так он ещё и зажимает? Так это уже третья фича !
А так он ещё и зажимает? Так это уже третья фича !
Нафига вы его заточили?!
Чтоб резал это же очевидно
это другие зажимы не режут. а этот – режет!
За такую аргументацию мне людей в реальной жизни хотелось пиздить. Работает или не работает - вообще не аргумент. Хорошо написанный код, в котором есть ошибки, можно исправить. Плохо написанный код, который работает, пизданет в самый неподходящий момент. Его невозможно доработать и исправить, это мина замедленного действия.
На сколько заплачено на столько и сделано просто не трогай этот модуль и все будет ок
Ваще ничего нэ трогай
Лучше даже не использовать
Какие еще отмазки у говноделов будут? "Не мы такие - жизнь такая", "Что ты - лучше других"?
Ну это не отмазка, а факт. Просто кто-то сразу скажет "За эти деньги можно сделать только говно, и я делать этого не буду.", а кто-то согласится. Потому что обычно товарищу программисту нужны деньги.
Ты даже не видишь разницы между пилотом, ограниченным/нереализованным функционалом и откровенными говном. Это не зависит от денег, это зависит только от отношения к работе. И если в России программисту сейчас нечего кушать, то вероятно, это очень плохой программист. Потому что конъюнктура рынка сейчас такая, что программистов сейчас жуткий дефицит, и платят им очень неплохо, по крайней мере, по сравнению с врачами и учителями, а порог вхождения относительно низкий.
А если в текущем спринте по другому не успеть. Да и в конце концов если задача написать софт, и сдать его, то и так сойдет.
Значит, заваливать спринт. Это миф, что делать нормально дороже, чем делать говняно. Делать нормально суммарно дешевле, чем делать плохо. И именно это является критерием того, хорошо, это или плохо. Я не говорю о выдрачивании каждой строчки кода, чтобы она блестела, не о 100% покрытии юнит-тестами и даже не о 100% выполнении функционала. Я говорю о тех случаях, когда делают криво просто потому, что лень было включить мозг, и подумать о том, как можно было сделать лучше.
"Если задача написать софт и сдать его" - по этой причине мне рассказывали о крайне негативном опыте принятия фрилансеров на постоянку. Потому что они по привычке делают на отъебись без мыслей о том, как и кто это будет поддерживать.
"Если задача написать софт и сдать его" - по этой причине мне рассказывали о крайне негативном опыте принятия фрилансеров на постоянку. Потому что они по привычке делают на отъебись без мыслей о том, как и кто это будет поддерживать.
It just works.
Главное - не трогать...
Бизнес:
- Не ну этот - норм мужик, по быстрому сделал, работает и пох. А тот мидлила все ноет что так нельзя, надо по нормальному, да еще и с тестами, ну его нах!
- Не ну этот - норм мужик, по быстрому сделал, работает и пох. А тот мидлила все ноет что так нельзя, надо по нормальному, да еще и с тестами, ну его нах!
И правильно. Если кодер пропал заказчик просто больше доплатит за копание палочкой в чужом коде причем хорошо доплатит.
а потом бизнесмен идет к другому исполнителю, просит расширить функционал и слегка удивляется почему так долго и дорого, "всего-то ведь просто кнопочку добавить!"
Потом он проходит по 3-4 и и возвращается ибо у остальных глаза лезут.
не удивлюсь, если он все таки найдет исполнителя, который подпишется сделать что нужно за ту сумму и за те сроки. Но тут есть вероятность, что всрут проект, а если сделают, то код качественнее не станет.
Еще лучше если всрут со скандалом отберет бабло придет и по отчаянным мольбам поймешь сколько еще накинуть.
Как это найти?
Присоединяюсь к вопросу.
Баффи - истребительница вампиров, 4й сезон 10й эпизод
Из-за отличной гифки смотреть три сезона и девять серий Баффи? Не, спасибо
Ну почему нет?
попробуй включить сразу 10ю серию из 4го сезона. обычно такое работает
В детстве срал кирпичами от этой серии
единственная годная серия, только ее и смотри, особо сюжет не надо
Теперь вопрос послежнее - как найти порно с таким вот? Друг спрашивает
Замок на сейфе с наркотическими препаратами?
уже без все ушли на создание запорного механизма
Знаки препинания у тебя, видимо, тоже на что-то ушли.
У меня плохо с русским
Выпей
Замок ОТ сейфа с наркотой, что стоит рядом. Когда закрывали, по непонятной причине промазали.
Скорее скачал чужую либу, понял что немного не то что надо и захардкодил свой функционал
я тут даже отрефакторить предлагаю
Не, ну может постановка такая была - выданным замком закрыть обозначенную дверь. Какое тз, такое и решение
Как раз читаю Макконелла. Документацию следует писать до написания кода.
Читать тоже лучше сначала.
Что-то нынче письма не доходят...
Ты про книгу или про документацию в коде?
Ты про книгу или про документацию в коде?
Про документацию к коду.
Не представляю как можно не читать документацию к методу перед использованием. Как минимум параметры нужно знать.
Спорный момент. В процессе реализации зачастую всплывает множество нюансов заставляющих несколько раз пересмотреть архитектуру и подход к решению задачи.
Поэтому документацию и следует писать до написания кода. Гораздо проще исправить спецификацию и описание, чем код, который привязан к языку программирования и возможно оптимизирован. Это всё в "Совершенном коде" описано. Перечитываю второй раз, до сих пор не могу придраться к чему-либо.
Не совсем понимаю мысль которую ты пытаешься донести. Код всегда тем или иным образом будет завязан на язык, особенно при его оптимизации поскольку у каждого языка есть какая-то фишка делающая код местами специфичным и от этого не уйдёшь. Задача состоит в том, чтобы написать вменяемое API для которого код будет чёрным ящиком и задокументировать его после чего сможешь с оглядкой на спецификацию имплементировать/переписывать под другие языки и платформы как тебе вздумается. Ясное дело, что в процессе проектирования чего-то большого нужен примерный роадмап и представление об интерфейсах, но поддерживание в актуальном состоянии спецификацию в процессе активной фазы написания кода геморрой с нулевым профитом.
Значит ты не читал упомянутое произведение. Прочитай, хоть в пиратской версии. Иначе взглянешь.
Читал, водянистный сборник выводов капитана очевидности. Вообще это очень офигенный аргумент когда кого-то впечатляет некая книга и люди не разделяющие восторг от произведения становятся носителями неправильного мнения. Где-то я это уже видел... Рассуждения о такой вещи как написание чистого кода и рассуждения о правилах проектирования вообще вещь довольна мутная поскольку нет правильного взгляда на вещи, но есть набор практик хорошо себя оправдывающий в некоторых ситуациях.
Напиши свою книгу по данной теме.
Я думал мы сейчас подискутируем о таких понятиях как применимость тех или иных идей, рассмотрим индустрию и выдвинем более детализированные аргументы за и против предложенного подхода чтобы каждый мог выразить свою точку зрения, но получил "сперва добейся". Ясно.
Если ты считаешь себя правее правого, что покажи это, а не ори, что правый не правый, а левый. Кто утверждает, тот и доказывает.
Верный тезис, а я здесь причем? Ты вдвинул возглас о том, что нужно писать писать документацию до написания кода без каких либо аргументов. Я же справедливо отметил спорность этого момента. Затем ты пытался что-то доказать фразой "Гораздо проще" не приводя для неё оснований, на что я привёл альтернативную точку зрения. Пока что я вижу только софистический выпад и попытку перевернуть стрелку бремя доказательства на мою сторону. Не надо так.
Я ссылаюсь на конкретную литературу. Хочешь что-то предъявить - предъявляй автору. Или напиши свой опус, который уничтожит ...
Короче, иди нахуй....
Короче, иди нахуй....
Ясно всё с тобой. Ссылка на книгу вместо доводов и упование на авторитет автора в надежде, что отсутствие критического мышления позволит проглотить мнение как заведомо верное. Я не говорил, что автор не прав, но с моей точки зрения этот опус представляет собой мнение, а не правило и меня интересует точка компромисса касательно описанных в ней вещей. Не стану опускаться до твоего уровня, всего плохого.
я вобщем-то просто хуй с горы, но скажу свои пять копеек про книгу. Как-то так вышло, что я ее прочитал уже имея некоторый свой опыт в аутсорсе, как написание проектов с нуля так и поддержка долгоиграющего говна... ну и читая книгу я просто кивал соглашаясь с автором. Еще понравилась позиция автора относительно спорных вопросов...
Я вот тоже просто кивал хотя и познакомился намного ранее. В таком формате её, честно говоря, весьма сложно читать потому, что из-за скуки сложно не пропустить что-то важное.
... и книга воспринимается как просто хранилище опыта. Много выводов сделано на статистических данных. Это и есть аргументация в пользу "правильности" книги.
В процессе реализации зачастую всплывает множество нюансов заставляющих несколько раз пересмотреть архитектуру и подход к решению задачи.
Значит проектирования было недостаточным, неполным, проводилось не очень квалифицированным персоналом. На моей практике было такое, что на этапе написания дотошной документации я нашел ошибку в дизайне, что позволило внести правки заранее, еще ни строчки кода не было написано. Если бы такое случилось во время имплементации, это стоило бы больше времени.
В процессе реализации зачастую всплывает множество нюансов заставляющих несколько раз пересмотреть архитектуру и подход к решению задачи.
Значит проектирования было недостаточным, неполным, проводилось не очень квалифицированным персоналом. На моей практике было такое, что на этапе написания дотошной документации я нашел ошибку в дизайне, что позволило внести правки заранее, еще ни строчки кода не было написано. Если бы такое случилось во время имплементации, это стоило бы больше времени.
Вот здесь не соглашусь. Спланировать заранее всё невозможно, а также в процессе реализации уже на половине решения задачи бизнес может повернуть в другую сторону или могут образоваться новые факторы которые раньше не были учтены в виду отсутствия и приходится решать этот момент. Твой опыт радикально заявляет, что причина подобного из-за недостатка проектирования, мой нет. К тому же надо понимать, что далеко не всегда есть время и возможность правильного проектирования системы по целому множества причин от необходимости решить задачу ещё вчера, до нехватки численности программистов, недостатка той самой квалификации и банального отсутствия спецов из доменной области, которые могут грамотно рассказать о целях и задачах которые вообще должна решать программа. Возвращаясь к первоначальному камню преткновения, преждевременное написание документации заместо простого роадмапа с описанием API без чрезмерной детализации внутренностей кажется альтернативой позволяющей достичь некоторого компромисса вежду возможностью и реальностью. Статистика вещь жестокая и моя субъективная говорит о том, что порой лучше встретиться с проблемой во время имплементации и быстро решить её нежели пытаться спроектировать идеальную систему. Это, в свою очередь, накладывает определенные обязанности на архитектуру и ты её выстраиваешь с прицелом на то, что в какой-то момент может потребоваться внести радикальные изменения. Я наверное выражу имхо, но когда речь заходит о математической библиотеке или написании программы промышленного робота вероятность предвосхитить множество возможных проблем куда выше нежели у быстро растущего/изменяющегося бизнеса, работа с котором похожа на постройку самолёта на лету когда посреди процесса может оказаться, что бизнесу вообще нужен танк или газонокосилка.
Подводя выше сказанное, объективная действительность имеет слишком много ограничивающих факторов иначе бы люди всегда решали задачи правильным образом и без косяков и приходится идти на компромиссы. В таком случае заявление о том, что нужно писать документацию заранее звучит чрезмерно категорично, где-то это применимо и оправдано где-то нет.
Подводя выше сказанное, объективная действительность имеет слишком много ограничивающих факторов иначе бы люди всегда решали задачи правильным образом и без косяков и приходится идти на компромиссы. В таком случае заявление о том, что нужно писать документацию заранее звучит чрезмерно категорично, где-то это применимо и оправдано где-то нет.
И да, следует разделять понятия проектирования и документирования. Из отсутствия готовой документации не следует отсутствие плана структуры приложения.
нуда, одно дело писать софт под банковские карты, другое - хуярить наколенные стартапы.
Я бы всё-таки попросил не делить индустрию на крайности между данными категориями находится бесконечное множество градаций. Да и банковское ПО судя по рассказам коллег плохой пример являющийся кладезем legacy и неразберихи.
Так, местный гений индустрии разработки ПО. Небольшой тест. Если понимаешь о чем речь, что плюсуй единицу. Если что-то слышал, то 0,5. Всего 6 терминов.
1. Цепочка начисления
2. Массив
3. Удлинённый список
4. Двойная точность
5. Куча
6. Ретроактивный синапс
Какова сумма?
1. Цепочка начисления
2. Массив
3. Удлинённый список
4. Двойная точность
5. Куча
6. Ретроактивный синапс
Какова сумма?
Ты адекватный? Каким образом 3 термина для первокурсника вкупе с одним ентерпрайзным и двумя остальными должны были оценить мой кругозор? Если честно про ретроактивный синапс в первый раз слышу хотя встречал эти слова по отдельности и имел дело с нейронками, возможно недостаток моего кругозора, но это специфическая область не особо связанная с предметом обсуждения. Также номер 3 заставляет меня считать, что ты меня просто на понт берёшь потому, что даже название звучит упорото из чего подозреваю, что и с синапсом тоже самое. Научись уже вести дискуссию предметно и смени тон я с тобой нормально общался.
Короче, результат - 0 баллов. И тест не на пустой основе создан. Обсирайся дальше.
Единственный кто обосрался здесь ты, поскольку мне всё-таки стало интересно, что же это за ретроактивный синапс такой и я его нагуглил в... совершенном коде в тесте на пиздоболов якобы знающих несуществующие термины перемешанные с обычными и по прямо таки удивиииительнейшему стечению обстоятельств идеально прошёл его. Дабы оценить чужой кругозор логично было спросить чем, например, различаются классы P и NP, ООП от функционального подхода и с какими шаблонами проектирования (не программирования) оппонент имел дело и т.д., но ты даже вопросов своих придумать не смог. Кажется в этом моменте становится ясно, что ты просто недотролль основная цель которого либо заставить людей не разбирающихся в вопросе думать, что ты где-то там прав либо просто заставлять писать оппонентов аргументированные опровержения на твои ничем не подкрепленный высказывания. В любом случае не вижу смысла дальнейшего диалога.
Второе правило троллинга: "обвини оппонента в троллинге до того как он показал, что ты тролль" Пряздрявляю. Держи мидальку
А первое правило троллинга отвечать не на аргументы, а на слова оброненные между ними, чем ты собственно и занимаешься в перерывах между вбросов не аргументированных высказываний. Софистика да и только, самый скучный вид диалога как по мне. Думал такой вид как ты уже давно вымер.
Страйк
Хоть это одна из моих любимых книг, но чтото не припомню, чтобы документацию советовали писать до кода.
Помню, про то, что документацию надо писать прямо в коде, в виде "///" xml-комментариев.
Помню, про то, что документацию надо писать прямо в коде, в виде "///" xml-комментариев.
Под "надо" - естественно имеется ввиду "зачастую", "как правило", "стоило бы".
А то некоторые любят придираться
А то некоторые любят придираться
Книга объёмная, подобна Библии. Всего не упомнишь. Читаю второй раз и удивляюсь.
А по теме: глава 9 и перекрёстные ссылки.
А по теме: глава 9 и перекрёстные ссылки.
Да не, бред какой-то.
Когда в документации про это не написано
Ну если замок не лезет, а закрыть надо.
Когда сделал свою работу "наотъебись", но прокатило и так
пишешь код, хотя ты нихуя не программист, долго и нервно куришь мануалы, код не работает. снова куришь мануалы, код опять не работает. копируешь кусок кода из мануалов, переписываешь под свои нужды, код не работает. долго и упорно гуглишь, находишь пост на забытом богом форуме где чувак столкнулся с той же проблемой и решил её через жопу написанным хитровыебанным способом при этом сам не понимает как это заработало. пытаешься читать его код нихуя не понимаешь, но копируешь кусок его кода и оптимизируешь под свой. о чудо заработало О_О
что самое забавное человек (сложно назвать его заказчиком т.к. код пишется на голом энтузиазме, скажем заинтересованное лицо) спрашивает о состоянии проекта, на что я отвечаю: весной мужик, весной
Нереалистично. На этом форуме тема была бы закрыта за ненадобностью, ибо вопрос давно решён, вот кстати ссылочка на это точно-не-удалённый тред.
Ответ на вопрос кинули в личку)
ну так и было
Отличный комментарий!