Pull to refresh

Comments 11

UFO just landed and posted this here
Статья сообщает о проблеме, но не предлагает решений. Никому не нравится нагромождение непонятного кода, а тема о чистоте и лаконичности, в общем понимании уже раскрыта. Как не писать код, если заказчик или рынок требует новый функционал? Отправить к конкурентам и оставить репозиторий в чистоте и красоте?
Как не писать код, если заказчик или рынок требует новый функционал? Отправить к конкурентам и оставить репозиторий в чистоте и красоте?

Да, примерно так и надо сделать :)
https://habr.com/ru/company/liteorder/blog/289498/
https://habr.com/ru/company/liteorder/blog/289976/

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

Я помню давнюю историю ещё из моей жизни Windows-программистом. Когда нас попросили добавить «кнопочку с чекбоксиком» в трей. Проблема в том, что иконка в трее рисовалась драйвером (чтобы без прав администратора её нельзя было убрать), драйвер ничего не знал о приложении и добавление вылилось в несколько тысяч строк кода и две недели того, что сегодня называется рефакторингами.

Когда, мы, гордые такие, это показали… заказчик на некоторое время потерял дар речи. Но не потому, что он «оценил» нашу «крутизну» — а от того, что он не оценил уровень идиотизма.

Если отфильтровать мат, то речь звучала примерно как: «а сказать, что кнопку в этот #%$$&**% трей сложно добавить? и вместо двух недель работы двух человек выставить счёт за пять минут работы по добавлению ещё одного пункта в главное меню приложения?».

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

Похоже, что автор открыл для себя unix-way.

Программирование — это искусство решения проблем.

разве что для совсем новичков — для которых проблема даже загуглить функцию по изучаемому языку.
Проблема нащупывается, формулируется и решается не программированием, а совсем другой мыслительной деятельностью. И только после того, как решение нащупано, выбрано, и сформулировано как задачи, начинается их программирование
Странный подход, автор статьи когда нибудь работал в больших проектах? Ощущение что он пишет утилиты, а не продукт в условиях спроса, конкуренции и непрерывного развития
Вот как раз в условиях «спроса, конкуренции и непрерывного развития» — его советы куда важнее.

Потому что если вы будете им следовать — у вас будут тысячи недовольных посетителей crbug.com, которая там будут оставлять гревные тирады.

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

При наличии на рынке конкурента с большим количеством функционала написать версию с сильно меньшим функционалом может быть более чем разумно. Особенно, если тот функционал, который вы всё-таки сделаете, будет сделан лучше.
Примеров не так мало. Jira и Trello. Photoshop и Sketch.

UFO just landed and posted this here
UFO just landed and posted this here
Sign up to leave a comment.