Когда написал код, не читая документацию, но оно работает
у мидлов, которые документацию читали и смотрят на это, наступает состояние ахуя и возникает нехватка слов для аргументации.
и можно еще резать немного, если понадобится. доп фича.
Это зажим, он не режет.
это другие зажимы не режут. а этот – режет!
За такую аргументацию мне людей в реальной жизни хотелось пиздить. Работает или не работает - вообще не аргумент. Хорошо написанный код, в котором есть ошибки, можно исправить. Плохо написанный код, который работает, пизданет в самый неподходящий момент. Его невозможно доработать и исправить, это мина замедленного действия.
Ты даже не видишь разницы между пилотом, ограниченным/нереализованным функционалом и откровенными говном. Это не зависит от денег, это зависит только от отношения к работе. И если в России программисту сейчас нечего кушать, то вероятно, это очень плохой программист. Потому что конъюнктура рынка сейчас такая, что программистов сейчас жуткий дефицит, и платят им очень неплохо, по крайней мере, по сравнению с врачами и учителями, а порог вхождения относительно низкий.
Значит, заваливать спринт. Это миф, что делать нормально дороже, чем делать говняно. Делать нормально суммарно дешевле, чем делать плохо. И именно это является критерием того, хорошо, это или плохо. Я не говорю о выдрачивании каждой строчки кода, чтобы она блестела, не о 100% покрытии юнит-тестами и даже не о 100% выполнении функционала. Я говорю о тех случаях, когда делают криво просто потому, что лень было включить мозг, и подумать о том, как можно было сделать лучше.
"Если задача написать софт и сдать его" - по этой причине мне рассказывали о крайне негативном опыте принятия фрилансеров на постоянку. Потому что они по привычке делают на отъебись без мыслей о том, как и кто это будет поддерживать.
"Если задача написать софт и сдать его" - по этой причине мне рассказывали о крайне негативном опыте принятия фрилансеров на постоянку. Потому что они по привычке делают на отъебись без мыслей о том, как и кто это будет поддерживать.
It just works.
И правильно. Если кодер пропал заказчик просто больше доплатит за копание палочкой в чужом коде причем хорошо доплатит.
а потом бизнесмен идет к другому исполнителю, просит расширить функционал и слегка удивляется почему так долго и дорого, "всего-то ведь просто кнопочку добавить!"
не удивлюсь, если он все таки найдет исполнителя, который подпишется сделать что нужно за ту сумму и за те сроки. Но тут есть вероятность, что всрут проект, а если сделают, то код качественнее не станет.
Присоединяюсь к вопросу.
я тут даже отрефакторить предлагаю
Не, ну может постановка такая была - выданным замком закрыть обозначенную дверь. Какое тз, такое и решение
Читать тоже лучше сначала.
Про документацию к коду.
Поэтому документацию и следует писать до написания кода. Гораздо проще исправить спецификацию и описание, чем код, который привязан к языку программирования и возможно оптимизирован. Это всё в "Совершенном коде" описано. Перечитываю второй раз, до сих пор не могу придраться к чему-либо.
Не совсем понимаю мысль которую ты пытаешься донести. Код всегда тем или иным образом будет завязан на язык, особенно при его оптимизации поскольку у каждого языка есть какая-то фишка делающая код местами специфичным и от этого не уйдёшь. Задача состоит в том, чтобы написать вменяемое API для которого код будет чёрным ящиком и задокументировать его после чего сможешь с оглядкой на спецификацию имплементировать/переписывать под другие языки и платформы как тебе вздумается. Ясное дело, что в процессе проектирования чего-то большого нужен примерный роадмап и представление об интерфейсах, но поддерживание в актуальном состоянии спецификацию в процессе активной фазы написания кода геморрой с нулевым профитом.
Читал, водянистный сборник выводов капитана очевидности. Вообще это очень офигенный аргумент когда кого-то впечатляет некая книга и люди не разделяющие восторг от произведения становятся носителями неправильного мнения. Где-то я это уже видел... Рассуждения о такой вещи как написание чистого кода и рассуждения о правилах проектирования вообще вещь довольна мутная поскольку нет правильного взгляда на вещи, но есть набор практик хорошо себя оправдывающий в некоторых ситуациях.
Под "надо" - естественно имеется ввиду "зачастую", "как правило", "стоило бы".
А то некоторые любят придираться
А то некоторые любят придираться
Да не, бред какой-то.
Когда в документации про это не написано
Когда сделал свою работу "наотъебись", но прокатило и так
пишешь код, хотя ты нихуя не программист, долго и нервно куришь мануалы, код не работает. снова куришь мануалы, код опять не работает. копируешь кусок кода из мануалов, переписываешь под свои нужды, код не работает. долго и упорно гуглишь, находишь пост на забытом богом форуме где чувак столкнулся с той же проблемой и решил её через жопу написанным хитровыебанным способом при этом сам не понимает как это заработало. пытаешься читать его код нихуя не понимаешь, но копируешь кусок его кода и оптимизируешь под свой. о чудо заработало О_О
что самое забавное человек (сложно назвать его заказчиком т.к. код пишется на голом энтузиазме, скажем заинтересованное лицо) спрашивает о состоянии проекта, на что я отвечаю: весной мужик, весной
Нереалистично. На этом форуме тема была бы закрыта за ненадобностью, ибо вопрос давно решён, вот кстати ссылочка на это точно-не-удалённый тред.
Отличный комментарий!